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)
Interesting. I'm curious about what version of FPC you used to compile
the samples.
It is an SVN pull out from several months ago, of one of the FPC 2.1.1
releases..
Are you using an SVN pull out or a specific version?
I don't think the code is safe until we discuss this further though,
Hi
In revision 1944 in trunk (log is + Add PTCpas package), among many
changes to packages/extra/, fcl/Makefile.fpc was changed, line
dirs=xml image db shedit passrc net fpcunit
was changed to
dirs=xml image shedit passrc net fpcunit
Was there any reason to remove db dir from the build
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 - fpc-devel@lists.freepascal.org
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,
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 computer (only
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/fpc-pascal@lists.freepascal.org/msg04686.html
After trying
The reference count is part of the ansistring itself. An ansistring
is simply a pointer to a record containing a reference count, the
amount of memory currently allocated for the string (i.e., maximum
length -1) and the string itself (a 0-terminated string).
So when passing a string from a
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
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
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
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
Michalis Kamburelis wrote:
Hi
In revision 1944 in trunk (log is + Add PTCpas package), among many
changes to packages/extra/, fcl/Makefile.fpc was changed, line
dirs=xml image db shedit passrc net fpcunit
was changed to
dirs=xml image shedit passrc net fpcunit
Was there any reason to
Peter Vreman wrote:
In revision 1944 in trunk (log is + Add PTCpas package), among many
changes to packages/extra/, fcl/Makefile.fpc was changed, line
dirs=xml image db shedit passrc net fpcunit
was changed to
dirs=xml image shedit passrc net fpcunit
Was there any reason to remove db dir from
Jonas Maebe wrote:
On 10 dec 2005, at 22:09, darekM wrote:
I've see that reverse-complement benchmark http://
shootout.alioth.debian.org/benchmark.php?test=revcomplang=all for
FPC is very slow. I discover, that problem is with readln, that
function consume about 90% of time.
In my test
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
L505 wrote:
The reference count is part of the ansistring itself. An ansistring
is simply a pointer to a record containing a reference count, the
amount of memory currently allocated for the string (i.e., maximum
length -1) and the string itself (a 0-terminated string).
So when passing a string
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
On Wed, 14 Dec 2005, Jonas Maebe wrote:
On 10 dec 2005, at 22:09, darekM wrote:
I've see that reverse-complement benchmark http://
shootout.alioth.debian.org/benchmark.php?test=revcomplang=all for FPC
is very slow. I discover, that problem is with readln, that function
consume
Hi,
I've been thinking about adding a linked list implementation to either TList
or TFPList. The basic problem to that is of course
1) space overhead of linked list is quite large
2) Index[..] will be O(N)
For (1) I was thinking about making a linked list of an array of items, for
example 14
On Wed, 14 Dec 2005 21:33:34 +0100
Micha Nelissen [EMAIL PROTECTED] wrote:
Hi,
I've been thinking about adding a linked list implementation to either
TList or TFPList. The basic problem to that is of course
1) space overhead of linked list is quite large
2) Index[..] will be O(N)
For
On Wed, 14 Dec 2005 21:44:50 +0100 (CET)
Daniël Mantione [EMAIL PROTECTED] wrote:
Op Wed, 14 Dec 2005, schreef Micha Nelissen:
Sorry to disappoint, but this doesn't look a very good idea to me; it
would kill code that for example tries to sort a list. There will be also
a lot of code that
On Wed, 14 Dec 2005, Micha Nelissen wrote:
Hi,
I've been thinking about adding a linked list implementation to either TList
or TFPList. The basic problem to that is of course
1) space overhead of linked list is quite large
2) Index[..] will be O(N)
For (1) I was thinking about making
On Wed, 14 Dec 2005, Micha Nelissen wrote:
On Wed, 14 Dec 2005 21:44:50 +0100 (CET)
Daniël Mantione [EMAIL PROTECTED] wrote:
Op Wed, 14 Dec 2005, schreef Micha Nelissen:
Sorry to disappoint, but this doesn't look a very good idea to me; it
would kill code that for example tries to
Micha Nelissen wrote:
Hi,
I've been thinking about adding a linked list implementation to either TList
or TFPList. The basic problem to that is of course
1) space overhead of linked list is quite large
2) Index[..] will be O(N)
For (1) I was thinking about making a linked list of an array of
Op Wed, 14 Dec 2005, schreef Micha Nelissen:
On Wed, 14 Dec 2005 21:44:50 +0100 (CET)
Daniël Mantione [EMAIL PROTECTED] wrote:
Op Wed, 14 Dec 2005, schreef Micha Nelissen:
Sorry to disappoint, but this doesn't look a very good idea to me; it
would kill code that for example tries
Michael Van Canneyt wrote:
People that have large lists know this and take care of it.
What is more, I think that 1 large memory block (an array) is much more
efficient memory wise than many small blocks.
This is true in some cases; VMs and scripting engines (such as
SpiderMonkey)
On Wed, 14 Dec 2005 21:53:58 +0100
Mattias Gaertner [EMAIL PROTECTED] wrote:
Your trick will only give a constant factor on growing/shrinking the list
memory, gives an extra O(n) factor for sorting a TList, the caching costs
time, and the memory usage will also grow.
You may be
On Wed, 14 Dec 2005 22:40:40 +0100
Micha Nelissen [EMAIL PROTECTED] wrote:
increased by 8 items. So when adding 1000 (to take a number) items, the list
is copied at least 10, possibly 13 times, 12 - 28 - 44 - 60 - 76 - 92
- 108 - 124 - 140 - 206 - 325 - ~500 - ~780 - ~1000. For the linked
On Wed, 14 Dec 2005 21:33:34 +0100
Micha Nelissen [EMAIL PROTECTED] wrote:
For (1) I was thinking about making a linked list of an array of items, for
example 14 pointers (so that 8 bytes are left for next pointer and memory
manager needs on 32 bit platform).
Tiny addition: for 64bit OS you
On Wed, 14 Dec 2005 22:40:40 +0100
Micha Nelissen [EMAIL PROTECTED] wrote:
On Wed, 14 Dec 2005 21:53:58 +0100
Mattias Gaertner [EMAIL PROTECTED] wrote:
Your trick will only give a constant factor on growing/shrinking the
list memory, gives an extra O(n) factor for sorting a TList, the
Mattias Gaertner wrote:
Your trick will only give a constant factor on growing/shrinking the list
memory, gives an extra O(n) factor for sorting a TList, the caching costs
time, and the memory usage will also grow.
Just saw this last statement. The memory usage is very comparable to
note
that if the data you wan't to store in a tlist is the size of a pointer or less
you can store it directly in the tlist.
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of Sterling
BatesSent: 14 December 2005 22:04To: FPC developers'
On Wed, 14 Dec 2005 15:03:58 -0700
Sterling Bates [EMAIL PROTECTED] wrote:
Mattias Gaertner wrote:Your trick will only give a constant factor on
growing/shrinking the list memory, gives an extra O(n) factor for sorting
a TList, the caching costs time, and the memory usage will also grow.
Mattias Gaertner wrote:
Plus some bytes for the memory manager for each mem block. Typically 8.
Forgot about that, sorry. In any case, the math still works. I'll
explain.
In this case, 10,000 entries occupy 80,008 bytes
(80,000 + 4 for pointer to First + 4 for pointer to Last),
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
Mattias Gaertner wrote:
If the linked list item contains the whole data, then you are either not
talking of the generic list this thread is about, or you use templates. In
the later case a TList will also use templates and the 'payload' is the
same.
That's true of records, sure. Someone
On Wed, 14 Dec 2005 16:22:53 -0700
Sterling Bates [EMAIL PROTECTED] wrote:
Mattias Gaertner wrote:
If the linked list item contains the whole data, then you are either not
talking of the generic list this thread is about, or you use templates.
In the later case a TList will also use
Mattias Gaertner wrote:
Well, if you use objects, then you get even more mem overhead ... :)
I was thinking about that too. Then, IIRC, I read that object overhead
is a one-time allocation of class tables and such. Of course, you might
have some extra overhead inherited from TObject
In short (don't pin me on the names or on exact details in special cases):
Assume you have a ansistring and you assign something to it
S := 'SomeString';
the compiler generates something like
DecStringRef(S);
S - 'SomeString';
IncStringRef(S);
The DecStringRef() decrements
I'm having the same problem and submitted bug report #4605 about it
Vincent Snijders [EMAIL PROTECTED] wrote:
Any news about the win32 make cycle
problems?C:/lazarus/source/fpc/2.1/compiler/ppc1.exe -Ur -Xs -OG2p3 -n
-Fui386 -Fusystems
-FuC:/lazarus/source/fpc/2.1/rtl/units/i386-win32
41 matches
Mail list logo
