Hi
I've tested some of benchmark on

http://shootout.alioth.debian.org/

I've see that reverse-complement benchmark <http://shootout.alioth.debian.org/benchmark.php?test=revcomp&lang=all> for FPC is very slow. I discover, that problem is with readln, that function consume about 90% of time. Because I use it in my program, I implemented new version of reading files. My propositions is add tTextStream to unit Classes

using is very similar

 while not eof do
    begin
      readln(s);
    end;
changed to
   tx:=tTextStream.create('name')  //or via handle
  while tx.readln(d)>=0 do
   tx.free;

My implementation cause than benchmark run 4 times faster. But I think, it need some improvements.

Is this enough to add it to Classes. If so, I'll work on it.

Darek

Op Sat, 10 Dec 2005, schreef darekM:

The Shootout benchmarks should preferably be implemented without unit classes to achieve the best memory usage results. Your code is welcome though to add to unit classes, allthough I currently can't because it uses assembler code withotu Pascal alternative, i.e. it would make the classes unit unavailable on the other processors FPC supports.

Can you do the same to improve readln?

Daniël

1. You must remove the assembler from your unit.
2. Your architecture is wrong. Don't descend from TFileStream. You should create a separate TStream descendent which takes another stream as an argument in it's constructor, like the compression streams or encoding streams.
3. There is already a buffered stream (TBufStream, unit bufstream), I suggest you enhance that.
4. From 3 it follows that your unit can possibly be added to the FCL, but will certainly not make it into Classes.

Concerning the shoutout test, simply adding a
SetTextBuf(input,10000);
(or even higher) before the while loop should speed it up significantly. The default buffer is 255 chars, which is simply too small.

Can you measure the difference, and let us know ?

Anyway, glad to see that people are looking at the benchmarks :-)

Michael.

Daniël Mantione napisał(a):

For me more important is speed, in real program we always use other units

I know, in code are three funcion: findendLine, findEndLine2, findEndLine3 - there are propositions, please help me to make propers compilers conditions.

Maybe strlBuf (rename to scanbuf ?) should be moved to system unit?

Can you do the same to improve readln?

readln is more complicated, is compiler function, is so small buffer (only 128 bytes) and reads char by char.
I havent any idea to do this.

Darek

Even then not. See my mail...

Can you do the same to improve readln?

The problem is not the readln implementation, but the buffer size.

Michael.

I'm also going to try this with my CPU-WARS email I sent to the mailing list a while ago, regarding StrLoadFile function comparison - thanks to Marco for suggesting this too.

Regards,
Lars

Op Sun, 11 Dec 2005, schreef darekM:

For me more important is speed, in real program we always use other units

The Shootout is about both speed, memory and lines of code. We're no. 3 in memory usage, and if the Shootout wouldn't measure some numbers incorrectly, we would be no.1. Let's not loose that position.

I agree that speed is in many situations more important than memory, but in a lot of software, you use, i.e. text editor, memory is more important.

It can be moved into the strings unit, if we have also a Pascal implementation for non-i386 processors.

The compiler converts read/readln calls to calls to procedures in the rtl. fpc_Read_Text_ShortStr is the procedure to optimize. It is in the file text.inc.

Daniël

// TEST 5
function StrLoadFile_test5(const FileName: string): string;
var
  F: text;
  c: char;
  str1, Line: string;
  Buf : Array[1..100000] of byte;
begin
  result:= ''; //safety
  str1:= '';
  if FileExists(FileName) = false then
    exit;
  Assign(F, FileName);   //open file
  Reset(F);
  SetTextBuf(F, Buf);
  while not Eof(F) do
  begin
    Read(F, C);
    result:= result + C;
  end;
  close(F); //close file
end;

--------------------------------------------------------- Welcome to the CPU war for StrLoadFile.. Please wait...

test 1 execution time: 9357464 <-- char by char
test 2 execution time: 257074 <-- my blockread
test 3 execution time: 265960 <-- my other blockread test 4 execution time: 2666055 <-- classes stringlist test 5 execution time: 9133218 <-- char w/buffer

Done.
Press <enter> to exit
--------------------------------------------------------

In this case, the 100,000 buffer helped a little, but not too significant.

I think stringlist.loadfile should use block reading rather than the overhead of using streams. We've got way too much overhead with stringlists using classes on top of classes on top of classes. Although the current stringlist.loadfile is much faster than char by char, block reading still beats it hands down.

Now as for Delphi's stringlist.loadfile and stringlist.text, I will have to do some tests and see.

I think stringlist.loadfile should use block reading rather than the overhead of using streams.

Of course stringlist is an array of strings so this may not work.. time will tell

But why do you read char by Char? Why not

read(f, line);
result := result + line;

You can add a line break in between as well if you want.

close(F); //close file end;

Jonas

Michael Van Canneyt napisał(a):

I know, that was only propositions, I make 3 procedures.

Why not descend. Why not exceed tFileStream, its natural. I want read text file in the same way like binary file.
While complicated, when it only 2 procedure should be added. Form me tTextStream should be used to fast and simple read text file (or application input stream) and no others, no allocate nor reallocate buffer. only simple read (and write).

3. There is already a buffered stream (TBufStream, unit bufstream), I suggest you enhance that.

Sorry, i don;t know about it. Its simple to implemented it.

But why it is in separated unit, nobody know about it (or to few). F.e. Lazarus has own implementation of buffering.
If we want to make faster programs, object like my should be in core unit, then everybody use them, in other case every make own implementation.

Concerning the shoutout test, simply adding a SetTextBuf(input,10000);

I'll test it.

Darek

The said test has already been reviewed by Vincent aand me, however I still must dig it up and send it to shootout.

Iirc it is the speed of memory growth (the realloc) that is the problem, not the textbuffer. Exponential memgrowth.

Because then you must also descend THandlestream, TPipeStream, TIOStream, TDecompressionStream, TMemorystream, TDecodestream etc etc etc.

Streams are more than just for files.

While complicated, when it only 2 procedure should be added. Form me tTextStream should be used to fast and simple read text file (or application input stream) and no others, no allocate nor reallocate buffer. only simple read (and write).

It's not so simple.

Maybe, but then we should put all streams in Classes, and we're not going to do that.

Michael.

On Sun, 11 Dec 2005, darekM wrote: > But why it is in separated unit, nobody know about it (or to few). F.e. > Lazarus has own implementation of buffering.

Lazarus had to do a long time with FPC 1.0.x _and_ 2.0.x. Not all artefacts of that transition are already banned.

Rule of thumb: specialised versions not in generically meant units, indeed.

Michael Van Canneyt napisał(a):

Why must, for me my tTextStream is for readin text file, of course we may implemented readln in tBufStream

It is.I've implemented it. Of course if we want to make universal bufStream then take it more work.

But tBufStream is Owner of stream, for me is separated idea

Darek

Marco van de Voort napisał(a):

I know history, Its only example, but this is small proof that no all know and use buffering form FPC (even if they need), FPC should have fastest implementation (it can).

Readln is not specialized, is rather popular function, buffering version can be used in near all programs.

Darek

Pipes, Compressed Streams, IO, Decode and so on can also contain text. Your implementation requires that we re-implement your solution in all of these classes if we want to have the 'readln()' functionality available.

And that is what is needed.

That is optional behaviour, and disabled by default.

Michael.

You are correct that it can and will be used in all programs.

But you are missing our main point: It should ALSO be usable for ALL kinds of streams. Your implementation currently is limited to file streams. My proposed solution makes it work for ALL streams, just as the existing (de)compression/encoding/buffer/whatever streams can be used on all streams.

So my proposal to you is to make a TTextStream = Class(TBufStream), with no assembler code. Then, and only then, can it be included in the FCL.

Michael.

Are we talking here about making a class that can read any TStream descendant line-by-line (i.e. by simple a'la Readln method) ?

Then I believe this was already discussed on fpc-pascal, I remember that I sent there my TTextReader class implementation that does just that. TTextReader class is also part of pasdoc code right now, you can see it here
[http://cvs.sourceforge.net/viewcvs.py/*checkout*/pasdoc/pasdoc/source/component/PasDoc_ProcessLineTalk.pas].

Is this the kind of thing that is wanted ?

Michalis

Yes, with the exception that TTextReader should be a TStream descendent.

Michael.

Hi
My CPU war
Welcome to the CPU war for StrLoadFile.. Please wait...

test 1 (char) execution time: 1862654
test 2 (blockread 1) execution time: 27080
test 3 (blockread fsize) execution time: 46633
test 7 (blockread tHandle) execution time: 18569
test 4 (tStringList) execution time: 364999
test 1 ln (tTextStream) execution time: 117256
test 2 ln (readln) execution time: 182298

Done.

Comment:
use Athlon 2.6G +Gentoo

test 7 : read file via tFileStream -- this is the fastest way to read file

test 2 ln : read file line by line used: readln and eof test 1 ln: read file line by line used tTextStream

Darek

Neat!
I'm testing on a Celeron 400 using Winblows 2000.. Do you have the source code for test 7 so we can run it through different CPU architectures?

Do you have the source code for test 7 so we can run it through different CPU architectures?

nevermind, my bad, I see the email attachment.

> Do you have the source code for test 7 so we can run it through different CPU > architectures? nevermind, my bad, I see the email attachment.

Since the maillists are a bit irregular, I want to repeat the point that the relative slowliness of the revcomp benchmark is the repeated realloc, not the reading of the textfile (though a small settextbuf might improve it a bit).

Yes tried that, and on my computer readln with string concatenation actually locks up the computer (only on big files.. not on small)! Something is wrong with the string concatenation... I'll dig up some old FPC-Pascal mailing archives to show you what I mean.

Actually on my computer reading char by char was faster than line by line! I am not sure what is wrong with the string concatenation.. but I commented out the concatenation and that was definitely the problem. As suggested by Vincent S. I tried putting it in brackets too... i.e.

result + (line + #13#10);

and it didn't help the speed of the concatenation by any significant amount.

In my next post I will send you some links to the archives which discussed some of this if I can find them.

Lars

After trying Vincent's suggestion I did not see noticeable improvement. On the large MB file I tried, my computer locks up doing string concentration. Actually, it doesn't lock up.. it just takes several hours to complete.

Lars

p.s. sorry DarekM if I'm stealing your post. But maybe some of this is related to the benchmarks if there is any concatenation in any of the benchmarks

Athlon 2.6G +Gentoo

Here are tests on a Celeron 400 Windows 2000 then

Welcome to the CPU war for StrLoadFile.. Please wait...

test 1 (char) execution time: 9287434
test 2 (blokread 1) execution time: 267230
test 3 (blockread fsize) execution time: 262710
test 7 (blokread tHandle) execution time: 265247
test 4 (tStringList) execution time: 2660387
test 1 ln (tTextStream) execution time: 624126
test 2 ln (readln) execution time: 831215

It appears the new Athlon processor takes extreme advantage of tHandle (test 7) while an old Celeron doesn't. Or, unless it is Linux versus Windows. I guess we can tell that test7, test3 and test2 are fastest so far.

L505 napisał(a):

There was attached

yours modified project1
and textstream: unit with implementation tTextStream (w/o assembler)

Darek

Marco van de Voort napisał(a):

Its not true. Realloc is invoked only few times. Most of times consume readln. You may try remove all lines from revcom except readln, and then see, that time of computation has near 80% of prev. From the second side, i remove only readln (pass only const string) and revcom speed has 4 times faster.

Darek
.

Did you test with files > 10 MB?

Vincent

.. and on *nix ? (since that is where the benchmarks run)

darekM wrote

I've see that reverse-complement benchmark <http:// shootout.alioth.debian.org/benchmark.php?test=revcomp&lang=all> for FPC is very slow. I discover, that problem is with readln, that function consume about 90% of time.

In my test (Mac OS X/PPC, rtl and program compiled with register variables, text buffer of 64kb) readln's overheid is negligible. The large cost comes from writeln. The reason the C version is so much faster is because its output is buffered as well. We automatically flush the output after each writeln (i.e. after each writeln of 60 characters), while in C this only happens at the very end of the program for 128kb of characters at a time.

Jonas

Another speed improvement will be disabling IO checks for write, {$I-}

I normally wouldn't recomend doing so, but for this test it either passes or fails.

Marc

That code only takes 0.5% of the time, not really relevant.

Jonas

PS: my "negligible" above was an overstatement, the readln code takes up 8.4% of the time. Still a far cry from 90% though.

OK, in some other benchmarks I got a (imo) serious ~10-20% speed improvement by doing so (and all pieces help:)

Marc

Normally, You can speed that up considerably by doing the following:

program testp;
uses dos; // Needed for TextRec...
Var
  F : Text;
  Buf : Array[1..100000] of char;
  I : Integer;
begin
  Assign(F,'');
  Rewrite(F);
  SetTextBuf(F,Buf); // Allocate HUGE buffer
  TextRec(F).FlushFunc:=Nil; // Disable flushing after each writeln().
  For I:=1 to 10000 do
    Writeln(F,'teststring');
  Close(F); // Will flush.
end.

If you strace that, you'll see that the whole buffer is written to screen in one big gulp, instead of 256 chars per write.

In fact, I think maybe we should do the

  TextRec(F).FlushFunc:=Nil; // Disable flushing after each writeln().

In SetTextBuf if the file is open for writing, as otherwise the settextbuf is meaningless. Or add a DisableFlushText() call to the system unit. (to avoid dragging the Dos unit in if you want this)

Michael.

(small post note in this discussion:

a customer complained that his app was a lot slower (till 3 times) with D2006/FastMM.

I'm still investigating, and it seems that somehow FastMM must more often copy when reallocating than the old MM for large blocks (big as in the 100kbs or even MB size)

)

I really wonder how FastMM made it in D2006. All memory managers are a mess because of its complexity but FastMM is hell with the assembler code. Borland should have better spent time in an improved compiler and use a good documented memory manager written in pascal.

Well, the old Delphi one was usually much slower than FPC's.

?

Ales Katona wrote

Did I get it right that the new FastMM in new delphi is 3 times slower than the old delphi one (which is on par with FPC AFAIK)?

No, only in a very specific case. FastMM is much faster than the old delphi memory manager. It has been said it made delphi 2006 bootup twice as fast.

Micha

Did I get it right that the new FastMM in new delphi is 3 times slower than the old delphi one (which is on par with FPC AFAIK)?