Discussion:
c faster than pascal? was: Compiling GlScene ...
Bisma Jayadi
2006-06-12 11:09:42 UTC
Permalink
Actually, C isn't faster. That's a Myth (tm)
Is there any scientific proof of this and written by a really known good c or
pascal programmer? Any URLS? I just can't say it without a real acceptable
proof. Even the language-shoutout website still shows c (gcc) is faster than fpc. :(

Though I'm a big fan of object pascal but I found myself that c (gcc) IS faster
than fpc. Here's the simple comparison example:

#include <stdio.h>
int main()
{
int num, res;
char buf[4*1024];
do {
res = scanf("%d", &num);
if (res==EOF || num==0) break;
printf("%dn", num);
} while (1);
}

This c (gcc) program run on 0.303 second. The closest equal pascal version I
think is...

program Test;
var
I: Integer;
begin
repeat
Readln(I);
if I = 0 then Break;
Writeln(I);
until False;
end.

This fpc program run on 1.772 second (about 6 times slower than the c version). :(

A little optimization below still can't beat gcc ...

program Test;
uses
Dos;
const
MaksBuf = 4 * 1024;
var
I: Integer;
BufBaca, BufTulis: array[0..MaksBuf-1] of Char;
begin
SetTextBuf(Input, BufBaca, MaksBuf);
SetTextBuf(Output, BufTulis, MaksBuf);
with TextRec(Output) do
FlushFunc := nil;
repeat
Readln(I);
if I = 0 then Break;
Writeln(I);
until False;
Flush(Output);
end.

And the result run on 0.407 second, but with some additional optimization codes.
I can make a same output result using FPC that can be faster than GCC, but with
LOTS of more additional optimization codes (I need to "take over" the buffer
read and write operation). So, I don't think it's counted. :D

When the same second code above is compiled using Kylix (v.3), it run on 1.235
second. So, obviously FPC is a lot better than Kylix. :)

Tested using GCC 4.0 (with -O2 param) and FPC 2.0.0 (with -OG param) on Linux
(kernel v2.6.12 dan glibc v2.3.5) on P4 2.8 GHz with 2 GB ram, to read a text
file contains 500.000 lines of random numbers (integers). Utilizing "time"
command for time measurements (bash$ time ./test < input.txt > output.txt).

Any hints? :)

PS: I don't mean to start a flame here. Just to show you the simple fact. I just
want to show the world that the "c is faster than pascal" is REALLY a Myth(tm).
And remember that I'm a proud user of FPC/Lazarus, so I'm not the enemy. :)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com
Bisma Jayadi
2006-06-12 11:16:37 UTC
Permalink
Post by Bisma Jayadi
I'm a big fan of object pascal
Because pascal IS better than c/c++. But, unfortunately, better doesn't always
mean faster. :)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com
Michael Van Canneyt
2006-06-12 11:34:24 UTC
Permalink
Post by Bisma Jayadi
Actually, C isn't faster. That's a Myth (tm)
Is there any scientific proof of this and written by a really known good c or
pascal programmer? Any URLS? I just can't say it without a real acceptable
proof. Even the language-shoutout website still shows c (gcc) is faster than fpc. :(
Though I'm a big fan of object pascal but I found myself that c (gcc) IS
All you do is compare standard IO performance. You don't compare the
compiled code's speed.

By default FPC uses a 256 byte buffer for text IO; The C library uses a
4K buffer. Obviously, C's input/output will be faster by a large factor.

Secondly, you should do at least 10-20 testruns of your program. I did
the test, and the optimized, stripped FPC version runs as fast as the C
version on average.

Third, adding the DOS unit adds the overhead of loading /etc/timezone
stuff, further slowing down your program, because it is additional IO...

So your test should be refined to measure compiled code speed, not IO
speed.

Michael.
Bisma Jayadi
2006-06-13 03:49:35 UTC
Permalink
Post by Michael Van Canneyt
All you do is compare standard IO performance. You don't compare the
compiled code's speed.
I know. But I/O performance benchmarking is one of the basic language comparison
item. When you want to participate on ACM contest (http://acm.uva.es/problemset)
that would be one of biggest obstacle to get on top rank.
Post by Michael Van Canneyt
By default FPC uses a 256 byte buffer for text IO; The C library uses a
4K buffer. Obviously, C's input/output will be faster by a large factor.
This would raise a simple basic question... why FPC doesn't also use 4K buffer?
If it'd improve I/O performance a lot. Any specific technical reasons why FPC
decide to allocate 256 byte for I/O buffer?
Post by Michael Van Canneyt
Secondly, you should do at least 10-20 test runs of your program. I did
the test, and the optimized, stripped FPC version runs as fast as the C
version on average.
I did. All time result I said before was the average of 10 test runs. Sorry to
forget mentioning that. :)
Post by Michael Van Canneyt
Third, adding the DOS unit adds the overhead of loading /etc/timezone
stuff, further slowing down your program, because it is additional IO...
But I need some functions from the DOS unit. Or should I copy and paste required
functions from DOS unit to eliminate timezone loading overhead? I think that
wouldn't be an elegant solution. :)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com
Michael Van Canneyt
2006-06-13 07:06:28 UTC
Permalink
Post by Bisma Jayadi
Post by Michael Van Canneyt
All you do is compare standard IO performance. You don't compare the
compiled code's speed.
I know. But I/O performance benchmarking is one of the basic language
comparison item. When you want to participate on ACM contest
(http://acm.uva.es/problemset) that would be one of biggest obstacle to get on
top rank.
Maybe, but if performance is an issue, then we wouldn't be using simple write()
statements...
Post by Bisma Jayadi
Post by Michael Van Canneyt
By default FPC uses a 256 byte buffer for text IO; The C library uses a
4K buffer. Obviously, C's input/output will be faster by a large factor.
This would raise a simple basic question... why FPC doesn't also use 4K
buffer? If it'd improve I/O performance a lot. Any specific technical reasons
why FPC decide to allocate 256 byte for I/O buffer?
Yes. TP compatibility. The "Text" internal record contains the buffer.
Post by Bisma Jayadi
Post by Michael Van Canneyt
Secondly, you should do at least 10-20 test runs of your program. I did
the test, and the optimized, stripped FPC version runs as fast as the C
version on average.
I did. All time result I said before was the average of 10 test runs. Sorry to
forget mentioning that. :)
Post by Michael Van Canneyt
Third, adding the DOS unit adds the overhead of loading /etc/timezone
stuff, further slowing down your program, because it is additional IO...
But I need some functions from the DOS unit. Or should I copy and paste
required functions from DOS unit to eliminate timezone loading overhead? I
think that wouldn't be an elegant solution. :)
As far as I saw, none of the functions you used required use of the dos
unit. The FlushFunc:=Nil is totally not needed. Setting of the IO buffer
are standard system unit functions.

Michael.
Bisma Jayadi
2006-06-13 08:17:04 UTC
Permalink
Post by Michael Van Canneyt
Yes. TP compatibility. The "Text" internal record contains the buffer.
Can we have 255 byte buffer works only on TP mode? While on other modes
(DELPHI/OBJFPC) is using 4 KB buffer as the default.

-Bee-

has Bee.ography at:
http://beeography.wordpress.com
Michael Van Canneyt
2006-06-13 09:10:16 UTC
Permalink
Post by Bisma Jayadi
Post by Michael Van Canneyt
Yes. TP compatibility. The "Text" internal record contains the buffer.
Can we have 255 byte buffer works only on TP mode? While on other modes
(DELPHI/OBJFPC) is using 4 KB buffer as the default.
At the moment, I don't see how we could do this.

Michael.
Bisma Jayadi
2006-06-13 10:02:20 UTC
Permalink
Post by Michael Van Canneyt
At the moment, I don't see how we could do this.
I almost knew nothing about the compiler and the sources, but this problem
forces me to look at the FPC compiler source and I found TextRecBufSize constant
declaration within textrec.inc file on FPC's src/rtl/inc folder. Here is the
declaration...

-----
const
TextRecNameLength = 256;
TextRecBufSize = 256;
type
TLineEndStr = string [3];
TextBuf = array[0..TextRecBufSize-1] of char;
-----

So, is it possible to do such a thing?

-----
const
TextRecNameLength = 256;

{IFDEF FPC_TP}
TextRecBufSize = 256;
{ELSE}
TextRecBufSize = 4 * 1024;
{ENDIF}
-----

-Bee-

has Bee.ography at:
http://beeography.wordpress.com
George Birbilis
2006-06-14 06:36:08 UTC
Permalink
Post by Bisma Jayadi
Post by Bisma Jayadi
This would raise a simple basic question... why FPC doesn't
also use
Post by Bisma Jayadi
4K buffer? If it'd improve I/O performance a lot. Any specific
technical reasons why FPC decide to allocate 256 byte for
I/O buffer?
Yes. TP compatibility. The "Text" internal record contains the buffer.
Could have a compiler switch for the user to select that buffer size I
suppose (the switch would set some compiler constant and then the compiler
would see it and recompile/link the needed file[s])

----------------
George Birbilis (***@kagi.com)
Microsoft MVP J# for 2004-2006
Borland "Spirit of Delphi"
* QuickTime, QTVR, ActiveX, VCL, .NET
http://www.kagi.com/birbilis
* Robotics
http://www.mech.upatras.gr/~Robotics
http://www.mech.upatras.gr/~robgroup




_____

avast! Antivirus <http://www.avast.com> : Outbound message clean.


Virus Database (VPS): 0624-1, 13/06/2006
Tested on: 13/6/2006 6:38:13 ??
avast! - copyright (c) 1988-2006 ALWIL Software.
Michael Van Canneyt
2006-06-14 07:34:48 UTC
Permalink
Post by George Birbilis
Post by Bisma Jayadi
Post by Bisma Jayadi
This would raise a simple basic question... why FPC doesn't
also use
Post by Bisma Jayadi
4K buffer? If it'd improve I/O performance a lot. Any specific
technical reasons why FPC decide to allocate 256 byte for
I/O buffer?
Yes. TP compatibility. The "Text" internal record contains the buffer.
Could have a compiler switch for the user to select that buffer size I
suppose (the switch would set some compiler constant and then the compiler
would see it and recompile/link the needed file[s])
That's not how it works.
The records used to describe text files cannot be dynamically changed in size.

For optimized IO, use streams, or use SetTextBuf()

Michael.
Thierry Coq (Personnel)
2006-06-14 07:31:44 UTC
Permalink
Hello,

can't you increase the I/O size? I've tested large-scale I/O buffers
(80K and over) with pascal with 4x the speed of C or C++ code. Not on
the FPC compiler, though.

Hope this helps.

Thierry Coq
Post by Bisma Jayadi
Post by Michael Van Canneyt
All you do is compare standard IO performance. You don't compare the
compiled code's speed.
I know. But I/O performance benchmarking is one of the basic language
comparison item. When you want to participate on ACM contest
(http://acm.uva.es/problemset) that would be one of biggest obstacle
to get on top rank.
Post by Michael Van Canneyt
By default FPC uses a 256 byte buffer for text IO; The C library uses a
4K buffer. Obviously, C's input/output will be faster by a large factor.
This would raise a simple basic question... why FPC doesn't also use
4K buffer? If it'd improve I/O performance a lot. Any specific
technical reasons why FPC decide to allocate 256 byte for I/O buffer?
Post by Michael Van Canneyt
Secondly, you should do at least 10-20 test runs of your program. I did
the test, and the optimized, stripped FPC version runs as fast as the C
version on average.
I did. All time result I said before was the average of 10 test runs.
Sorry to forget mentioning that. :)
Post by Michael Van Canneyt
Third, adding the DOS unit adds the overhead of loading /etc/timezone
stuff, further slowing down your program, because it is additional IO...
But I need some functions from the DOS unit. Or should I copy and
paste required functions from DOS unit to eliminate timezone loading
overhead? I think that wouldn't be an elegant solution. :)
-Bee-
http://beeography.wordpress.com
_________________________________________________________________
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
Michael Van Canneyt
2006-06-14 07:44:14 UTC
Permalink
Post by Thierry Coq (Personnel)
Hello,
can't you increase the I/O size? I've tested large-scale I/O buffers (80K and
over) with pascal with 4x the speed of C or C++ code. Not on the FPC
compiler, though.
Use SetTextBuffer() from the system unit. You can set any size you want...

Michael.
Marco van de Voort
2006-06-12 12:10:50 UTC
Permalink
Post by Bisma Jayadi
Actually, C isn't faster. That's a Myth (tm)
Is there any scientific proof of this and written by a really known good c or
pascal programmer? Any URLS? I just can't say it without a real acceptable
proof. Even the language-shoutout website still shows c (gcc) is faster than fpc. :(
Those are compilers, not languages you are comparing. And keep in mind gcc
is a sponsored by three major worldwide corporations or so (Apple, IBM and
RedHat), with a bunch of fulltime programmers. FPC is done in spare time.

Taking this in account, to be honest, I think gcc should be ashamed for
those results.
Post by Bisma Jayadi
Though I'm a big fan of object pascal but I found myself that c (gcc) IS faster
You are measuring reading cooked input here, not language performance.

The rock bottom level of Pascal and C have a very similar common base.
The differences will be in the details. There are differences, but they are
so minute that it will be hard to actually benchmark them, since they
totally disappear in the noise of actually using two different compilers.

If you want to do this, you need to investigate comparable C and Pascal
code, and with grammar and pencil and paper in the hand try to make it
amenable that a compiler knows can optimize certain code more in C then the
comparable code in Pascal or the otherway around.

Of course the first time you publicise that, it will be attacked by a
barrage of "improved" benchmarks of the other side. (e.g. by going slightly
more lowlevel).

Btw can your implementation actually reliably read a textual "0" on stdin?
Post by Bisma Jayadi
Any hints? :)
Limit yourself to something that is actually bound by the language, and
don't benchmark a trivial textmode driver implementation.
Bisma Jayadi
2006-06-13 04:04:40 UTC
Permalink
Post by Marco van de Voort
Those are compilers, not languages you are comparing.
How would I do performance measurement of language without its compiler?
Post by Marco van de Voort
Taking this in account, to be honest, I think gcc should be ashamed for
those results.
Agree! Even Java 1.4.2 (according to benchmark result at
http://www.osnews.com/story.php?news_id=5602&page=3) is faster than gcc! Pity
them! :D
Post by Marco van de Voort
Limit yourself to something that is actually bound by the language, and
don't benchmark a trivial textmode driver implementation.
I just want to get FPC on the first rank on most of ACM contest. I/O performance
is one of the biggest problem there. We (my friends and I from Indonesian
Pascal developers community) always need to optimize FPC I/O code to get on top
rank.

FYI... ACM uses FPC to compile submitted pascal solutions
(http://online-judge.uva.es/board/viewtopic.php?t=7428). I think that'd be a
plus to the FPC/Lazarus project. :)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com
Graeme Geldenhuys
2006-06-13 06:52:01 UTC
Permalink
Post by Bisma Jayadi
Post by Marco van de Voort
Taking this in account, to be honest, I think gcc should be ashamed for
those results.
Agree! Even Java 1.4.2 (according to benchmark result at
http://www.osnews.com/story.php?news_id=5602&page=3) is faster than gcc! Pity
them! :D
A lot of people don't realize how fast Java is. By that I mean,
console, server backend or anything not using the GUI. The GUI
(Swing, AWT, etc) is what makes a Java application slow. We did a lot
of tests with different languages and GUI toolkits before we started
with our current project. In the end we decided on FPC and Lazarus
purely due to all our developers having a history in Delphi and Object
Pascal.

Regards,
- Graeme -
Bisma Jayadi
2006-06-13 08:22:15 UTC
Permalink
Post by Graeme Geldenhuys
A lot of people don't realize how fast Java is.
Agree... a lot of people don't realize how powerful pascal is as well. Most of
them now are talking that pascal is dying while they're actually talking about
Delphi. "Pascal=Delphi"(tm) paradigm is totally false. And the most being talked
alternatives are Java and .Net. :)

-Bee-

has Bee.ography at:
http://beeography.wordpress.com
Aleš Katona
2006-06-13 08:45:48 UTC
Permalink
Post by Graeme Geldenhuys
A lot of people don't realize how fast Java is. By that I mean,
console, server backend or anything not using the GUI. The GUI
(Swing, AWT, etc) is what makes a Java application slow. We did a lot
of tests with different languages and GUI toolkits before we started
with our current project. In the end we decided on FPC and Lazarus
purely due to all our developers having a history in Delphi and Object
Pascal.
Regards,
- Graeme -
Java is neither fast nor good. What you tested were specialized cases of
small toy use which the VM could easily optimize to an extent where GCC
can only drool. However if you take any bigger (and it doesn't have to
use GUI) java app it'll simply be bloated and slow. The reason is not VM
speed, but the fact that java has a GC and it makes people write shit.

It's that simple, people in java create instances of everything even for
1ms throwaway temporary stuff, and unless they work with primitives they
create instances for everything they need just some tmp. The GC doesn't
keep up(it can't keep up) and memory grows. This is a java syndrome, and
it's so bad in java even python or IO or other interpreted languages end
up with eating less memory (and thus CPU btw).

If you want LANGUAGE performance comparison (NOT or LIMITED compiler
comparison) you need to take big programs and see how does work. It's
ofcourse impossible to make same big apps for 1 on 1 testing, but if you
look into things like Lazarus of Pixel etc. you'll see extreme speed and
memory conservatism without conscious optimalizations.

Now take azreus(or how's it called) or eclipse etc. and compare. It's
the way how language and it's internals (not compiler specific, but if
everything is an object it simpy hurts performance) push programmers to
do stuff in SOME way. This is what I call implicit optimalization.

Ales

P.S: IMHO you guys should stop this discussion it's somewhat useless
P.S2: IMHO read/write buffers should be modernized :)
Graeme Geldenhuys
2006-06-13 09:18:31 UTC
Permalink
Post by Aleš Katona
Java is neither fast nor good. What you tested were specialized cases of
small toy use which the VM could easily optimize to an extent where GCC
can only drool. However if you take any bigger (and it doesn't have to
use GUI) java app it'll simply be bloated and slow. The reason is not VM
speed, but the fact that java has a GC and it makes people write shit.
I did not mention in my previous post that we used this benchmark app
discussed in this thread for our decision making. It is way to simple.
We wrote a lot of different tests related to things we will need in
our product and easy of distribution, etc.. I have no intention in
starting a language flame war either...

Regards,
- Graeme -
Lord ZealoN
2006-06-13 09:24:17 UTC
Permalink
war war war war war war :D
Post by Graeme Geldenhuys
Post by Aleš Katona
Java is neither fast nor good. What you tested were specialized cases of
small toy use which the VM could easily optimize to an extent where GCC
can only drool. However if you take any bigger (and it doesn't have to
use GUI) java app it'll simply be bloated and slow. The reason is not VM
speed, but the fact that java has a GC and it makes people write shit.
I did not mention in my previous post that we used this benchmark app
discussed in this thread for our decision making. It is way to simple.
We wrote a lot of different tests related to things we will need in
our product and easy of distribution, etc.. I have no intention in
starting a language flame war either...
Regards,
- Graeme -
_________________________________________________________________
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
--
::Mi blog::
http://blog.lordzealon.com
Graeme Geldenhuys
2006-06-13 11:08:02 UTC
Permalink
Post by Lord ZealoN
war war war war war war :D
:-)

Graeme.
Graeme Geldenhuys
2006-06-12 13:09:07 UTC
Permalink
Have a look at the following...

http://www.osnews.com/story.php?news_id=5602
Nine Language Performance Round-up: Benchmarking Math & File I/O

It compares C#, C, C++, VB, etc...
I ported the benchmark to Delphi (not tested under FPC but should be
interresting) a coulpe of months back. Unfortunatily, my findings are
not on this PC, but rather on my laptop at home.
If memory serves me correctly, C++ and Delphi was very close together,
but Delphi was slightly faster. The port was really easy and quick to
do. I attached the original code. I will try and find my Delphi code
and findings and post them as well.

The benchmark test could be extended to test more things as well, but
it was good enough for what I wanted to know. Memory usage would be a
interresting add-on to the benchmark results.

Regards,
- Graeme -
Michael Van Canneyt
2006-06-12 13:45:46 UTC
Permalink
Post by Graeme Geldenhuys
Have a look at the following...
http://www.osnews.com/story.php?news_id=5602
Nine Language Performance Round-up: Benchmarking Math & File I/O
It compares C#, C, C++, VB, etc...
I ported the benchmark to Delphi (not tested under FPC but should be
interresting) a coulpe of months back. Unfortunatily, my findings are
not on this PC, but rather on my laptop at home.
If memory serves me correctly, C++ and Delphi was very close together,
but Delphi was slightly faster. The port was really easy and quick to
do. I attached the original code. I will try and find my Delphi code
and findings and post them as well.
I would be interested in seeing this :-)

Michael.
Lord ZealoN
2006-06-12 14:23:52 UTC
Permalink
Read the last line:

*Update:* Delphi version of the benchmark
here<http://www.dellapasqua.com/delphibench.txt>(
http://www.dellapasqua.com/delphibench.txt )
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
Have a look at the following...
http://www.osnews.com/story.php?news_id=5602
Nine Language Performance Round-up: Benchmarking Math & File I/O
It compares C#, C, C++, VB, etc...
I ported the benchmark to Delphi (not tested under FPC but should be
interresting) a coulpe of months back. Unfortunatily, my findings are
not on this PC, but rather on my laptop at home.
If memory serves me correctly, C++ and Delphi was very close together,
but Delphi was slightly faster. The port was really easy and quick to
do. I attached the original code. I will try and find my Delphi code
and findings and post them as well.
I would be interested in seeing this :-)
Michael.
_________________________________________________________________
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
--
::Mi blog::
http://blog.lordzealon.com
Alexandre Leclerc
2006-06-12 14:51:20 UTC
Permalink
Can you do the same test with lazarus? I did it (the same application
compiles without a change, but my results are not good on my pc. Maybe
the code must be optimized.

Start Lazarus silly benchmark
Int arithmetic elapsed time: 8437 ms with max of 1000000000
i: 1000000001
intResult: 1
Double arithmetic elapsed time: 12578 ms with min of 10000000000, max
of 11000000000
i: 11000000000
doubleResult: 10011632717,52295
Long arithmetic elapsed time: 16625 ms with min of 10000000000, max of
11000000000
i: 11000000000
longResult: -672337204
Trig elapsed time: 3250 ms with max of 10000000
i: 10000000
sine: 0,420547793190771
cosine: -0,907270386181745
tangent: -0,463530827850173
logarithm: 7
squareRoot: 3162,277660168379
IO elapsed time: 3891 ms with max of 1000000
i: 1000000
myLine: abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh
Total Lazarus benchmark time: 44781 ms
End Lazarus benchmark

You find in attachment my project file. I also have the exe (stripped
463K) but can't send it. Lazarus/FPC are home made on 2006june08 from
svn version available at compile time (in begining of afternoon).

Regards.
Update: Delphi version of the benchmark here (
http://www.dellapasqua.com/delphibench.txt )
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
Have a look at the following...
http://www.osnews.com/story.php?news_id=5602
Nine Language Performance Round-up: Benchmarking Math & File I/O
It compares C#, C, C++, VB, etc...
I ported the benchmark to Delphi (not tested under FPC but should be
interresting) a coulpe of months back. Unfortunatily, my findings are
not on this PC, but rather on my laptop at home.
If memory serves me correctly, C++ and Delphi was very close together,
but Delphi was slightly faster. The port was really easy and quick to
do. I attached the original code. I will try and find my Delphi code
and findings and post them as well.
I would be interested in seeing this :-)
Michael.
_________________________________________________________________
Post by Michael Van Canneyt
"unsubscribe" as the Subject
archives at
http://www.lazarus.freepascal.org/mailarchives
--
http://blog.lordzealon.com
--
Alexandre Leclerc
Graeme Geldenhuys
2006-06-12 15:07:27 UTC
Permalink
Post by Alexandre Leclerc
Can you do the same test with lazarus? I did it (the same application
compiles without a change, but my results are not good on my pc. Maybe
the code must be optimized.
To get a fair comparison, you need to run all the benchmarks for each
language on the same computer and repeat all of them a few time, to
get an average. But even so, your result is very slow. I haven't run
it under FPC yet, but will do so tonight, if I can find my other code.

Regards,
- Graeme -
Alexandre Leclerc
2006-06-12 15:16:19 UTC
Permalink
Post by Graeme Geldenhuys
Post by Alexandre Leclerc
Can you do the same test with lazarus? I did it (the same application
compiles without a change, but my results are not good on my pc. Maybe
the code must be optimized.
To get a fair comparison, you need to run all the benchmarks for each
language on the same computer and repeat all of them a few time, to
get an average. But even so, your result is very slow. I haven't run
it under FPC yet, but will do so tonight, if I can find my other code.
Indeed, this is why I asked "Lord Zealon" if he could perform a bench
on laz too.
--
Alexandre Leclerc
Lord ZealoN
2006-06-12 15:40:38 UTC
Permalink
Ok, here we go.

How i created the project? From Lazarus Menu- Project/Project from archive

Some changes? In Project/Compiler Options/Linking...

Only Win32GUIAPP and Strip activated.

FPC ver.: 2.0.3
Lazarus ver: 0.9.16 beta
Exe Size: 188.928

Physic Memory:
Total: 521712
Availible: 192400
System Cache: 215276

Laptop Acer Aspire 1600: PIV 2,4GHZ, 512 RAM, ATI RADEON MOBILE 9000

Start Lazarus silly benchmark
Int arithmetic elapsed time: 14125 ms with max of 1000000000
i: 1000000001
intResult: 1
Double arithmetic elapsed time: 14547 ms with min of 10000000000, max of
11000000000
i: 11000000000
doubleResult: 10011632717,52295
Long arithmetic elapsed time: 19546 ms with min of 10000000000, max of
11000000000
i: 11000000000
longResult: -672337204
Trig elapsed time: 3891 ms with max of 10000000
i: 10000000
sine: 0,420547793190771
cosine: -0,907270386181745
tangent: -0,463530827850173
logarithm: 7
squareRoot: 3162,277660168379
IO elapsed time: 10203 ms with max of 1000000
i: 1000000
myLine:
abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh
Total Lazarus benchmark time: 62312 ms
End Lazarus benchmark



Something are wrong..is much time.
Post by Alexandre Leclerc
Can you do the same test with lazarus? I did it (the same application
compiles without a change, but my results are not good on my pc. Maybe
the code must be optimized.
Start Lazarus silly benchmark
Int arithmetic elapsed time: 8437 ms with max of 1000000000
i: 1000000001
intResult: 1
Double arithmetic elapsed time: 12578 ms with min of 10000000000, max
of 11000000000
i: 11000000000
doubleResult: 10011632717,52295
Long arithmetic elapsed time: 16625 ms with min of 10000000000, max of
11000000000
i: 11000000000
longResult: -672337204
Trig elapsed time: 3250 ms with max of 10000000
i: 10000000
sine: 0,420547793190771
cosine: -0,907270386181745
tangent: -0,463530827850173
logarithm: 7
squareRoot: 3162,277660168379
IO elapsed time: 3891 ms with max of 1000000
i: 1000000
abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh
Total Lazarus benchmark time: 44781 ms
End Lazarus benchmark
You find in attachment my project file. I also have the exe (stripped
463K) but can't send it. Lazarus/FPC are home made on 2006june08 from
svn version available at compile time (in begining of afternoon).
Regards.
Update: Delphi version of the benchmark here (
http://www.dellapasqua.com/delphibench.txt )
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
Have a look at the following...
http://www.osnews.com/story.php?news_id=5602
Nine Language Performance Round-up: Benchmarking Math & File I/O
It compares C#, C, C++, VB, etc...
I ported the benchmark to Delphi (not tested under FPC but should be
interresting) a coulpe of months back. Unfortunatily, my findings
are
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
not on this PC, but rather on my laptop at home.
If memory serves me correctly, C++ and Delphi was very close
together,
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
but Delphi was slightly faster. The port was really easy and quick
to
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
do. I attached the original code. I will try and find my Delphi
code
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
and findings and post them as well.
I would be interested in seeing this :-)
Michael.
_________________________________________________________________
Post by Michael Van Canneyt
"unsubscribe" as the Subject
archives at
http://www.lazarus.freepascal.org/mailarchives
--
http://blog.lordzealon.com
--
Alexandre Leclerc
--
::Mi blog::
http://blog.lordzealon.com
Alexandre Leclerc
2006-06-12 15:56:40 UTC
Permalink
Do you want me to send you privately by email the EXE I build, so that
you would have the same FPC/Lazarus version? (I use the devel branch
of FPC 2.1.x on svn).

Indeed these results are worst... but I have a 3.0ghz Intel HT with
512 mem on WinXP.
Post by Lord ZealoN
Ok, here we go.
How i created the project? From Lazarus Menu- Project/Project from archive
Some changes? In Project/Compiler Options/Linking...
Only Win32GUIAPP and Strip activated.
FPC ver.: 2.0.3
Lazarus ver: 0.9.16 beta
Exe Size: 188.928
Total: 521712
Availible: 192400
System Cache: 215276
Laptop Acer Aspire 1600: PIV 2,4GHZ, 512 RAM, ATI RADEON MOBILE 9000
Start Lazarus silly benchmark
Int arithmetic elapsed time: 14125 ms with max of 1000000000
i: 1000000001
intResult: 1
Double arithmetic elapsed time: 14547 ms with min of 10000000000, max of
11000000000
i: 11000000000
doubleResult: 10011632717,52295
Long arithmetic elapsed time: 19546 ms with min of 10000000000, max of
11000000000
i: 11000000000
longResult: -672337204
Trig elapsed time: 3891 ms with max of 10000000
i: 10000000
sine: 0,420547793190771
cosine: -0,907270386181745
tangent: -0,463530827850173
logarithm: 7
squareRoot: 3162,277660168379
IO elapsed time: 10203 ms with max of 1000000
i: 1000000
abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh
Total Lazarus benchmark time: 62312 ms
End Lazarus benchmark
Something are wrong..is much time.
Post by Alexandre Leclerc
Can you do the same test with lazarus? I did it (the same application
compiles without a change, but my results are not good on my pc. Maybe
the code must be optimized.
Start Lazarus silly benchmark
Int arithmetic elapsed time: 8437 ms with max of 1000000000
i: 1000000001
intResult: 1
Double arithmetic elapsed time: 12578 ms with min of 10000000000, max
of 11000000000
i: 11000000000
doubleResult: 10011632717,52295
Long arithmetic elapsed time: 16625 ms with min of 10000000000, max of
11000000000
i: 11000000000
longResult: -672337204
Trig elapsed time: 3250 ms with max of 10000000
i: 10000000
sine: 0,420547793190771
cosine: -0,907270386181745
tangent: -0,463530827850173
logarithm: 7
squareRoot: 3162,277660168379
IO elapsed time: 3891 ms with max of 1000000
i: 1000000
abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh
Post by Alexandre Leclerc
Total Lazarus benchmark time: 44781 ms
End Lazarus benchmark
You find in attachment my project file. I also have the exe (stripped
463K) but can't send it. Lazarus/FPC are home made on 2006june08 from
svn version available at compile time (in begining of afternoon).
Regards.
Update: Delphi version of the benchmark here (
http://www.dellapasqua.com/delphibench.txt )
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
Have a look at the following...
http://www.osnews.com/story.php?news_id=5602
Nine Language Performance Round-up: Benchmarking Math & File I/O
It compares C#, C, C++, VB, etc...
I ported the benchmark to Delphi (not tested under FPC but should be
interresting) a coulpe of months back. Unfortunatily, my findings
are
Post by Alexandre Leclerc
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
not on this PC, but rather on my laptop at home.
If memory serves me correctly, C++ and Delphi was very close
together,
Post by Alexandre Leclerc
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
but Delphi was slightly faster. The port was really easy and quick
to
Post by Alexandre Leclerc
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
do. I attached the original code. I will try and find my Delphi
code
Post by Alexandre Leclerc
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
and findings and post them as well.
I would be interested in seeing this :-)
Michael.
_________________________________________________________________
Post by Alexandre Leclerc
Post by Michael Van Canneyt
"unsubscribe" as the Subject
archives at
http://www.lazarus.freepascal.org/mailarchives
--
http://blog.lordzealon.com
--
Alexandre Leclerc
--
http://blog.lordzealon.com
--
Alexandre Leclerc
Alexandre Leclerc
2006-06-12 16:54:14 UTC
Permalink
Here are the results I've got with the version of Lord ZealoN:
Total Lazarus benchmark time: 45188 ms
Total Lazarus benchmark time: 44236 ms
Total Lazarus benchmark time: 45749 ms

Here are those with my version:
Total Lazarus benchmark time: 44156 ms
Total Lazarus benchmark time: 44391 ms
Total Lazarus benchmark time: 44094 ms

So there is about 1sec amelioration with latest FPC svn.

Regards.
Post by Lord ZealoN
Ok, here we go.
How i created the project? From Lazarus Menu- Project/Project from archive
Some changes? In Project/Compiler Options/Linking...
Only Win32GUIAPP and Strip activated.
FPC ver.: 2.0.3
Lazarus ver: 0.9.16 beta
Exe Size: 188.928
Total: 521712
Availible: 192400
System Cache: 215276
Laptop Acer Aspire 1600: PIV 2,4GHZ, 512 RAM, ATI RADEON MOBILE 9000
Start Lazarus silly benchmark
Int arithmetic elapsed time: 14125 ms with max of 1000000000
i: 1000000001
intResult: 1
Double arithmetic elapsed time: 14547 ms with min of 10000000000, max of
11000000000
i: 11000000000
doubleResult: 10011632717,52295
Long arithmetic elapsed time: 19546 ms with min of 10000000000, max of
11000000000
i: 11000000000
longResult: -672337204
Trig elapsed time: 3891 ms with max of 10000000
i: 10000000
sine: 0,420547793190771
cosine: -0,907270386181745
tangent: -0,463530827850173
logarithm: 7
squareRoot: 3162,277660168379
IO elapsed time: 10203 ms with max of 1000000
i: 1000000
abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh
Total Lazarus benchmark time: 62312 ms
End Lazarus benchmark
Something are wrong..is much time.
Post by Alexandre Leclerc
Can you do the same test with lazarus? I did it (the same application
compiles without a change, but my results are not good on my pc. Maybe
the code must be optimized.
Start Lazarus silly benchmark
Int arithmetic elapsed time: 8437 ms with max of 1000000000
i: 1000000001
intResult: 1
Double arithmetic elapsed time: 12578 ms with min of 10000000000, max
of 11000000000
i: 11000000000
doubleResult: 10011632717,52295
Long arithmetic elapsed time: 16625 ms with min of 10000000000, max of
11000000000
i: 11000000000
longResult: -672337204
Trig elapsed time: 3250 ms with max of 10000000
i: 10000000
sine: 0,420547793190771
cosine: -0,907270386181745
tangent: -0,463530827850173
logarithm: 7
squareRoot: 3162,277660168379
IO elapsed time: 3891 ms with max of 1000000
i: 1000000
abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh
Post by Alexandre Leclerc
Total Lazarus benchmark time: 44781 ms
End Lazarus benchmark
You find in attachment my project file. I also have the exe (stripped
463K) but can't send it. Lazarus/FPC are home made on 2006june08 from
svn version available at compile time (in begining of afternoon).
Regards.
Update: Delphi version of the benchmark here (
http://www.dellapasqua.com/delphibench.txt )
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
Have a look at the following...
http://www.osnews.com/story.php?news_id=5602
Nine Language Performance Round-up: Benchmarking Math & File I/O
It compares C#, C, C++, VB, etc...
I ported the benchmark to Delphi (not tested under FPC but should be
interresting) a coulpe of months back. Unfortunatily, my findings
are
Post by Alexandre Leclerc
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
not on this PC, but rather on my laptop at home.
If memory serves me correctly, C++ and Delphi was very close
together,
Post by Alexandre Leclerc
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
but Delphi was slightly faster. The port was really easy and quick
to
Post by Alexandre Leclerc
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
do. I attached the original code. I will try and find my Delphi
code
Post by Alexandre Leclerc
Post by Michael Van Canneyt
Post by Graeme Geldenhuys
and findings and post them as well.
I would be interested in seeing this :-)
Michael.
_________________________________________________________________
Post by Alexandre Leclerc
Post by Michael Van Canneyt
"unsubscribe" as the Subject
archives at
http://www.lazarus.freepascal.org/mailarchives
--
http://blog.lordzealon.com
--
Alexandre Leclerc
--
http://blog.lordzealon.com
--
Alexandre Leclerc
Al Boldi
2006-06-12 21:05:07 UTC
Permalink
Post by Alexandre Leclerc
Total Lazarus benchmark time: 45188 ms
Total Lazarus benchmark time: 44236 ms
Total Lazarus benchmark time: 45749 ms
Total Lazarus benchmark time: 44156 ms
Total Lazarus benchmark time: 44391 ms
Total Lazarus benchmark time: 44094 ms
So there is about 1sec amelioration with latest FPC svn.
Can you post timings for linux?

Thanks!

--
Al
Alexandre Leclerc
2006-06-12 21:17:30 UTC
Permalink
Post by Al Boldi
Post by Alexandre Leclerc
Total Lazarus benchmark time: 45188 ms
Total Lazarus benchmark time: 44236 ms
Total Lazarus benchmark time: 45749 ms
Total Lazarus benchmark time: 44156 ms
Total Lazarus benchmark time: 44391 ms
Total Lazarus benchmark time: 44094 ms
So there is about 1sec amelioration with latest FPC svn.
Can you post timings for linux?
I would like to but I have no time for that right now. :( If I was
able to compile a version for linux under windows and then simply
execute under linux, I'd do it, but this is not the case.
--
Alexandre Leclerc
Lord ZealoN
2006-06-12 21:25:09 UTC
Permalink
The PC used in the link benchmark:

Type: Dell Latitude C640 Notebook
CPU: Pentium 4-M 2GHz
RAM: 768MB
Hard Disk: IBM Travelstar 20GB/4500RPM
Video: Radeon Mobility 7500/32MB
OS: Windows XP Pro SP 1
File System: NTFS

*
**int
math**long
math**
**double
math*
*
**trig*
*
**I/O*
*TOTAL*
*Visual C++*9.618.86.43.510.548.8
*Visual C#*9.723.917.74.19.965.3
*gcc C*9.828.89.514.910.073.0
*Visual Basic*9.823.717.74.130.785.9
*Visual J#*9.623.917.54.235.190.4
*Java 1.3.1*14.529.619.022.112.397.6
*Java 1.4.2*9.320.26.557.110.1103.1
*Python/Psyco*29.7615.4100.413.110.5769.1
*Python*322.4891.9405.747.111.91679.0

FPC in (well, not same PC but seemed) is like C#. Not possible. Something
are wrong. FreePascal gives native binaries and are so fast. This test don't
work correctly
Post by Alexandre Leclerc
Post by Al Boldi
Post by Alexandre Leclerc
Total Lazarus benchmark time: 45188 ms
Total Lazarus benchmark time: 44236 ms
Total Lazarus benchmark time: 45749 ms
Total Lazarus benchmark time: 44156 ms
Total Lazarus benchmark time: 44391 ms
Total Lazarus benchmark time: 44094 ms
So there is about 1sec amelioration with latest FPC svn.
Can you post timings for linux?
I would like to but I have no time for that right now. :( If I was
able to compile a version for linux under windows and then simply
execute under linux, I'd do it, but this is not the case.
--
Alexandre Leclerc
_________________________________________________________________
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
--
::Mi blog::
http://blog.lordzealon.com
Giuliano Colla
2006-06-12 20:37:34 UTC
Permalink
Post by Lord ZealoN
Ok, here we go.
How i created the project? From Lazarus Menu- Project/Project from archive
Some changes? In Project/Compiler Options/Linking...
Only Win32GUIAPP and Strip activated.
FPC ver.: 2.0.3
Lazarus ver: 0.9.16 beta
Exe Size: 188.928
Total: 521712
Availible: 192400
System Cache: 215276
Laptop Acer Aspire 1600: PIV 2,4GHZ, 512 RAM, ATI RADEON MOBILE 9000
Start Lazarus silly benchmark
Int arithmetic elapsed time: 14125 ms with max of 1000000000
i: 1000000001
intResult: 1
Double arithmetic elapsed time: 14547 ms with min of 10000000000, max
of 11000000000
i: 11000000000
doubleResult: 10011632717,52295
Long arithmetic elapsed time: 19546 ms with min of 10000000000, max of
11000000000
i: 11000000000
longResult: -672337204
Trig elapsed time: 3891 ms with max of 10000000
i: 10000000
sine: 0,420547793190771
cosine: -0,907270386181745
tangent: -0,463530827850173
logarithm: 7
squareRoot: 3162,277660168379
IO elapsed time: 10203 ms with max of 1000000
i: 1000000
abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh
Total Lazarus benchmark time: 62312 ms
End Lazarus benchmark
Something are wrong..is much time.
Maybe not. Those are my results, under Linux, both for Borland's Kylix 3
and for Lazarus (0.9.17). on an HP-compaq d530 with Pentium 4 3.00 GHz
Cpu, cache 1024 KB, Memory 512 MB. I had to modify the source because
GetTickCount isn't available under Linux (at least I didn't find it), so
I implemented it (both for Kylix and Lazarus) with :

function GetTickCount: Integer;
var
T1: TDateTime;
T2: TTimeStamp;
begin
T1 := GetTime;
T2 := DateTimeToTimeStamp(T1);
result := T2.Time;
end;

The rest of the code is unmodified.

Kylix 3:
Start Delphi silly benchmark
Int arithmetic elapsed time: 7139 ms with max of 1000000000
i: 1000000001
intResult: 1
Double arithmetic elapsed time: 12483 ms with min of 10000000000, max of
11000000000
i: 11000000000
doubleResult: 10011632717,523
Long arithmetic elapsed time: 16501 ms with min of 10000000000, max of
11000000000
i: 11000000000
longResult: -672337204
Trig elapsed time: 2672 ms with max of 10000000
i: 10000000
sine: 0,420547793190771
cosine: -0,907270386181745
tangent: -0,463530827850173
logarithm: 7
squareRoot: 3162,27766016838
IO elapsed time: 7743 ms with max of 1000000
i: 1000000
myLine:
abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh
Total Delphi benchmark time: 46538 ms
End Delphi benchmark

Here comes Lazarus:
Start Lazarus silly benchmark
Int arithmetic elapsed time: 8400 ms with max of 1000000000
i: 1000000001
intResult: 1
Double arithmetic elapsed time: 12486 ms with min of 10000000000, max of
11000000000
i: 11000000000
doubleResult: 10011632717.522955
Long arithmetic elapsed time: 16508 ms with min of 10000000000, max of
11000000000
i: 11000000000
longResult: -672337204
Trig elapsed time: 3155 ms with max of 10000000
i: 10000000
sine: 0.420547793190771
cosine: -0.907270386181745
tangent: -0.463530827850173
logarithm: 7
squareRoot: 3162.2776601683795
IO elapsed time: 6606 ms with max of 1000000
i: 1000000
myLine:
abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh
Total Lazarus benchmark time: 47155 ms
End Lazarus benchmark

Lazarus performs slightly better than Kylix on I/O, slightly worse on
trig and int arithmetics, pretty identical in long and double arithmetics.

Giuliano
Graeme Geldenhuys
2006-06-12 21:02:52 UTC
Permalink
Post by Giuliano Colla
Cpu, cache 1024 KB, Memory 512 MB. I had to modify the source because
GetTickCount isn't available under Linux (at least I didn't find it), so
Just for your info...
For Lazarus the GetTickCount is implemented in the LCLIntf unit, if I
remember correctly.

Regards,
- Graeme -
Giuliano Colla
2006-06-13 09:48:24 UTC
Permalink
Graeme Geldenhuys ha scritto:
[...]
Post by Graeme Geldenhuys
Just for your info...
For Lazarus the GetTickCount is implemented in the LCLIntf unit, if I
remember correctly.
Thanks,

Giuliano
Giuliano Colla
2006-06-13 10:08:00 UTC
Permalink
Post by Graeme Geldenhuys
Just for your info...
For Lazarus the GetTickCount is implemented in the LCLIntf unit, if I
remember correctly.
It stubbornly refuses to find LCLIntf unit. What should I set in a
console application to access LCL? I tried with -dLCL ad -dLCL -dLCLgtk,
adding Interfaces in the uses clause, with no chance. :'(
Giuliano
Vincent Snijders
2006-06-13 10:23:01 UTC
Permalink
Post by Giuliano Colla
Post by Graeme Geldenhuys
Just for your info...
For Lazarus the GetTickCount is implemented in the LCLIntf unit, if I
remember correctly.
It stubbornly refuses to find LCLIntf unit. What should I set in a
console application to access LCL? I tried with -dLCL ad -dLCL -dLCLgtk,
adding Interfaces in the uses clause, with no chance. :'(
Project inspector: Add LCL package as requirement.

Vincent
Giuliano Colla
2006-06-13 12:54:16 UTC
Permalink
Post by Vincent Snijders
Post by Giuliano Colla
Post by Graeme Geldenhuys
Just for your info...
For Lazarus the GetTickCount is implemented in the LCLIntf unit, if I
remember correctly.
It stubbornly refuses to find LCLIntf unit. What should I set in a
console application to access LCL? I tried with -dLCL ad -dLCL
-dLCLgtk, adding Interfaces in the uses clause, with no chance. :'(
Project inspector: Add LCL package as requirement.
Great! Now it doesn't complain any more. Thanks.

Giuliano
Graeme Geldenhuys
2006-06-13 11:19:02 UTC
Permalink
Below is the result on my computer. I couldn't find my original code or
result, so ran them again. I didn't have Mono installed so couldn't test
C#.

My computer specs:
Ubuntu Linux 5.10
Linux kernel: 2.6.12-10-386
CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz
Memory Total: 451852 kB
Windows Manager: Gnome
VMWare Player (latest) running Windows 2000.


----
int math
double math
long math
trig
IO
TOTAL
FPC 2.0.x
10.9
16.3
21.6
4.1
2.1
55.1
Delphi 7 (under VMWare Player)
9.5
16.8
22.3
3.6
18.2
70.5
Java 1.5.0-07
9.8
15.7
32.9
97.1
5.5
161.2
GCC 4
11.0
15.9
23.0
5.2
0.6
55.8

I am sure the reason for Delphi 7 being so slow in because it was run under
a VMWare session. I wasn't in the mood to reboot for one test. :-)


Benchmark application compiled as follows:

FPC: fpc -S2 FPCBenchV2.pp
GCC 4: gcc Benchmark.c -o Benchmark.c.bin -lm
Java: javac Benchmark.java
Delphi 7: loaded FPCBenchV2.pas in IDE and pressed Ctrl+F9


Regards,
- Graeme -
Graeme Geldenhuys
2006-06-13 14:57:42 UTC
Permalink
Wow, compiling the different apps as mentioned in the OSNews article
with optimization, made a huge difference..

GCC 4.x time went down to 37.6 seconds from 55.8
Java with server VM went down to 113.5 seconds from 161.2

Interestingly, no matter what I set for FPC, the time was constant at
55.1 seconds.
Or does that just mean that the default settings in Lazarus are pretty
much the best optimization settings to use.

I tried the following using FPC 2.0.3 (latest from svn)

-S2i -OG3p2 -TLinux -Pi386 -vewnhi -l -Fu. -oFPCBenchV2 FPCBenchV2.pp

and

-S2i -OG1up2 -vewnhi -l -Fu. -oFPCBenchV2 FPCBenchV2.pp

and the Lazarus default

-S2i -OG1 -vewnhi -l -Fu. -oFPCBenchV2 FPCBenchV2.pp

I then the tried the following, which did make a difference (Generate
Normal Code at Optimization Level 0). Time jumped to 114.3 seconds.

-S2i -vewnhi -l -Fu. -oFPCBenchV2 FPCBenchV2.pp


With optimization enabled, GCC (c source) clearly came out the winner.
Not sure why Java 5 runs so sloooooow on my computer though.
Previously I used Java 1.4 with much better performance. From this I
guess C is still faster to run, but definitely not for readability and
friendliness. ;-)

Regards,
- Graeme -
Aleš Katona
2006-06-13 15:06:54 UTC
Permalink
I think that FPC has very limited optimalization support. There's some
difference between -O2 and none but that's about it as far as my tests
(most at the shootout) went.

FPK even mentioned that most optimalizations are useless for real world
apps.

Ales
George Birbilis
2006-06-14 06:36:09 UTC
Permalink
Post by Aleš Katona
I think that FPC has very limited optimalization support.
There's some difference between -O2 and none but that's about
it as far as my tests (most at the shootout) went.
FPK even mentioned that most optimalizations are useless for
real world apps.
Doesn't it even support detection of loop invariants etc.?

Else you could use a static source code analyzer that works on the source
code and gives you hints for improvements

----------------
George Birbilis (***@kagi.com)
Microsoft MVP J# for 2004-2006
Borland "Spirit of Delphi"
* QuickTime, QTVR, ActiveX, VCL, .NET
http://www.kagi.com/birbilis
* Robotics
http://www.mech.upatras.gr/~Robotics
http://www.mech.upatras.gr/~robgroup




_____

avast! Antivirus <http://www.avast.com> : Outbound message clean.


Virus Database (VPS): 0624-1, 13/06/2006
Tested on: 13/6/2006 6:34:56 ??
avast! - copyright (c) 1988-2006 ALWIL Software.
l***@star-dev.com
2006-06-14 13:13:05 UTC
Permalink
Post by Graeme Geldenhuys
guess C is still faster to run, but definitely not for readability and
friendliness. ;-)
"C is still faster to run", or faster to compiler ?

Depends on the compiler and generated code ;-)


Cheers.

-----
Marco Aurelio Ramirez Carrillo
lazarus dot mramirez at star-dev dot com [dot mx]

Loading...