Re: [fpc-devel] Benchmark for FreePascal

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

Re: [fpc-devel] Benchmark for FreePascal

Ales Katona wrote: > Marco van de Voort wrote: > >> (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 th

Re: [fpc-devel] Benchmark for FreePascal

Marco van de Voort wrote: (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

Re: [fpc-devel] Benchmark for FreePascal

Marco van de Voort wrote: > (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 (bi

Re: [fpc-devel] Benchmark for FreePascal

(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) )

[fpc-devel] Benchmark for FreePascal - test

I've done some test there are 5 version of revcom test 1. original 2. done bigger buffer 3 use tTextSrteam 4+ 5 in place of readln i've pass const string 6 only one set string variable 7 no move- I've rem MOVE procedure I've repeat test in program, because time of test are vary (I don't know w

Re: [fpc-devel] Benchmark for FreePascal

On Wed, 14 Dec 2005, Jonas Maebe wrote: > > On 10 dec 2005, at 22:09, darekM wrote: > > > I've see that reverse-complement benchmark > 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 a

Re: [fpc-devel] Benchmark for FreePascal

Jonas Maebe wrote: On 14 dec 2005, at 18:33, Marc Weustink wrote: 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 i

Re: [fpc-devel] Benchmark for FreePascal

On 14 dec 2005, at 18:33, Marc Weustink wrote: 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 buffere

Re: [fpc-devel] Benchmark for FreePascal

Jonas Maebe wrote: On 10 dec 2005, at 22:09, darekM wrote: I've see that reverse-complement benchmark 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

Re: [fpc-devel] Benchmark for FreePascal

On 10 dec 2005, at 22:09, darekM wrote: I've see that reverse-complement benchmark 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 progr

Re: [fpc-devel] Benchmark for FreePascal

> > Marco van de Voort napisa?(a): > > > >> 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). >

Re: [fpc-devel] Benchmark for FreePascal

darekM wrote: Marco van de Voort napisał(a): 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). Its not true.

Re: [fpc-devel] Benchmark for FreePascal

Marco van de Voort napisał(a): 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). Its not true. Realloc is invo

Re: [fpc-devel] Benchmark for FreePascal

L505 napisał(a): 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? There was attached yours modified project1 and textstream: unit with implementation tTextStream (w/o assembler) Darek __

Re: [fpc-devel] Benchmark for FreePascal

> 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 t

Re: [fpc-devel] Benchmark for FreePascal

> > But why do you read char by Char? Why not > > > > read(f, line); > > result := result + line; > In my next post I will send you some links to the archives which discussed > some of > this if I can find them. http://www.mail-archive.com/[email protected]/msg04686.html After

Re: [fpc-devel] Benchmark for FreePascal

> 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 Yes tried that, and on my computer readln with string concatenation actually locks up the c

Re: [fpc-devel] Benchmark for FreePascal

> > 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 re

Re: [fpc-devel] Benchmark for FreePascal

> 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. ___ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-d

Re: [fpc-devel] Benchmark for FreePascal

> 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 (readl

Re: [fpc-devel] Benchmark for FreePascal

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

Re: [fpc-devel] Benchmark for FreePascal

On Mon, 12 Dec 2005, Michalis Kamburelis wrote: 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 impleme

Re: [fpc-devel] Benchmark for FreePascal

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 a

Re: [fpc-devel] Benchmark for FreePascal

On Mon, 12 Dec 2005, darekM wrote: Marco van de Voort napisa(a): 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

Re: [fpc-devel] Benchmark for FreePascal

On Mon, 12 Dec 2005, darekM wrote: Michael Van Canneyt napisa(a): On Sun, 11 Dec 2005, darekM wrote: Michael Van Canneyt napisa(a): Why not descend. Why not exceed tFileStream, its natural. I want read text file in the same way like binary file. Because then you must also descend THa

Re: [fpc-devel] Benchmark for FreePascal

Marco van de Voort napisał(a): 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 transiti

Re: [fpc-devel] Benchmark for FreePascal

Michael Van Canneyt napisał(a): On Sun, 11 Dec 2005, darekM wrote: Michael Van Canneyt napisa(a): Why not descend. Why not exceed tFileStream, its natural. I want read text file in the same way like binary file. Because then you must also descend THandlestream, TPipeStream, TIOStream, TD

Re: [fpc-devel] Benchmark for FreePascal

> 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. > > If we want to

Re: [fpc-devel] Benchmark for FreePascal

On Sun, 11 Dec 2005, darekM wrote: Michael Van Canneyt napisa(a): On Sat, 10 Dec 2005, darekM wrote: Hi I've tested some of benchmark on http://shootout.alioth.debian.org/ I've see that reverse-complement benchmark

Re: [fpc-devel] Benchmark for FreePascal

> > Op Sat, 10 Dec 2005, schreef darekM: > > > > > Hi > > > I've tested some of benchmark on > > > http://shootout.alioth.debian.org/ > > > > > > I've see that reverse-complement benchmark > > > > > > for > > > FPC is very

Re: [fpc-devel] Benchmark for FreePascal

On 11 Dec 2005, at 17:28, L505 wrote: // TEST 5 function StrLoadFile_test5(const FileName: string): string; var F: text; c: char; str1, Line: string; Buf : Array[1..10] of byte; begin result:= ''; //safety str1:= ''; if FileExists(FileName) = false then exit; Assign(F, F

Re: [fpc-devel] Benchmark for FreePascal

Michael Van Canneyt napisał(a): On Sat, 10 Dec 2005, darekM wrote: Hi I've tested some of benchmark on http://shootout.alioth.debian.org/ I've see that reverse-complement benchmark for FPC is very slow. I discover, t

Re: [fpc-devel] Benchmark for FreePascal

> 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 ___ fpc-devel maillist - [email protected] http://l

Re: [fpc-devel] Benchmark for FreePascal

> > Concerning the shoutout test, simply adding a > > SetTextBuf(input,1); > > (or even higher) before the while loop should speed it up significantly. > I'm also going to try this with my CPU-WARS email I sent to the mailing list // TEST 5 function StrLoadFile_test5(const FileName: string):

Re: [fpc-devel] Benchmark for FreePascal

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

Re: [fpc-devel] Benchmark for FreePascal

Daniël Mantione napisał(a): Op Sat, 10 Dec 2005, schreef darekM: Hi I've tested some of benchmark on http://shootout.alioth.debian.org/ I've see that reverse-complement benchmark for FPC is very slow. I discover, tha

Re: [fpc-devel] Benchmark for FreePascal

> > Concerning the shoutout test, simply adding a > SetTextBuf(input,1); > (or even higher) before the while loop should speed it up significantly. > The default buffer is 255 chars, which is simply too small. I'm also going to try this with my CPU-WARS email I sent to the mailing list a wh

Re: [fpc-devel] Benchmark for FreePascal

On Sun, 11 Dec 2005, Daniël Mantione wrote: > > > Op Sat, 10 Dec 2005, schreef darekM: > > > Hi > > I've tested some of benchmark on > > http://shootout.alioth.debian.org/ > > > > I've see that reverse-complement benchmark > >

Re: [fpc-devel] Benchmark for FreePascal

On Sat, 10 Dec 2005, darekM wrote: > Hi > I've tested some of benchmark on > http://shootout.alioth.debian.org/ > > I've see that reverse-complement benchmark > for > FPC is very slow. I discover, that problem is with read

Re: [fpc-devel] Benchmark for FreePascal

Op Sat, 10 Dec 2005, schreef darekM: > Hi > I've tested some of benchmark on > http://shootout.alioth.debian.org/ > > I've see that reverse-complement benchmark > for > FPC is very slow. I discover, that problem is with re

[fpc-devel] Benchmark for FreePascal

Hi I've tested some of benchmark on http://shootout.alioth.debian.org/ I've see that reverse-complement benchmark for FPC is very slow. I discover, that problem is with readln, that function consume about 90% of time. B