On 2005-06-15, Waldek Hebisch <hebisch@[EMAIL PROTECTED]
> wrote:
> Marco van de Voort <marcov@[EMAIL PROTECTED]
> wrote:
>> On 2005-06-13, Scott Moore <samiamsansspam@[EMAIL PROTECTED]
> wrote:
>>> * FPC is almost HALF the performance of GPC, by a benchmark I have
>>> posted here earlier.
>>
>> By a totally specific, probably carefully selected typical tighest
>> loop benchmark.
>
> OK, heapsort 40000 single precision floats:
> Compiler options time
> fpc-1.9.4 -Mobjfpc -O3 -Op3 0.016s
> gpc-2.1/gcc-2.95.3 -O2 -march=i686 0.011s
> gpc-20050331/gcc-3.4.4 -O2 -march=i686 0.011s
> gpc-20050331/gcc-3.2.3 -O2 -march=i686 0.010s
>
> All on Athlon-XP 2000 (sorry, have no Mac). I had just code handy.
> You can try dismiss a single data point, but the difference is quite
> significant, and in the past other codes gave me similar result (this
> one is actually the best for fpc IIRC).
I don't deny GPC being better in code that only exists in tighest loops.
However declaring that FPC is 4 times slower than GPC based on such
benchmarks
is ridiculous. Moreover, use 2.0 and -OG3p3r Without -Or no data is
retained
in registers.
> Sure, on larger programs the difference is likely to slightly flatten
> since memory overheads depends more on algorithm then on compiler.
Which is more or less what I meant. One can't extrapolate benchmark
performance to real world apps. Exception is e.g. numeric calculation,
if you check the thread, I already mentioned this several times as a
kind of app for which I would choose GPC (and I already do this for
years)
>>> tool kit that is going to be ready "any day now".
>> The limited CPU sup****t encloses all commonly used, still developed
>> CPUs except Itanium. It is two thirds of GPC's lists to my knowledge,
>> and if you only count OS-CPU targets re****ted working, and sup****ted
>> by the main developers, FPC outcl***** GPC.
>>
>
> Hmm, GPC is regularly tested on Mac OSX, DJGPP, Mingw32 and all Debian
> platforms.
All? Including Debian/FreeBSD? I must admit that I never tried to run
on FPC on that one.
(just kidding, I assume you mean mainstream Debian/Linux platforms)
> We have recent re****ts about AIX, Irix and Sparc Solaris
> (there we problems on Solaris, fixed at least on my machine). Also
> about NetBSD and MirOS BSD. i386 Darwin just have build and is running
> tests.
This is not that different from FPC btw. Except Irix and Aix. But then
there is DragonFly BSD, MorphOS, 3 different do***tenders.
>> (doubters, check GPC sup****t for a relatively mainstream x86 platform
as
>> FreeBSD, which afaik is the OS that comes as close to both Mac OS X and
>> Linux as it gets)
>>
> Could you elaborate. We know that BSD make can not be used to build
> GPC (unless you are willing to hack Makefile,
> what MirOS BSD and
> probably NetBSD folks did), but with Gnu make it should build out
> of the box -- we know that people tried to build GPC, but did not
> get any info about succes/failure.
Yes you did, from me :-) However that went via private mail with Frank,
since I'm not subscribed to the maillist anymore due to the tiring
discussions.
I tried to compile GPC on FreeBSD several times a year over the last few
years. (and I'm still willing to do that) A fat year ago for the last
time,
and that was also the first time I succeeded, and I submitted test results
However I'm an unix hack, doing BSD since 4.4BSD times, and I still needed
help from Frank to figure everything out. That's the sup****ted part.
Yes, a guru can usually get GPC to work outside of the core platforms, but
if you are an ordinary user, you are out of luck.
E.g. can you even confirm that GPC was succesfully built on a 5.x
platform?
5.x being out there for about 3-4 years now?
> If you ask if I am willing to install FreeBSD in order to test GPC,
> then the answer is no.
Don't worry. If you want to have it retested, drop me a msg. Actually,
it might be time to test this again, since afaik it hasn't been done
on a recent 5.x system yet. However that will have to wait a few weeks
till I have inet access again. ( I recently moved)
>> no matter what a few very vocal advocatist say.
>> - Standards are good in principle. However the yields can be higher
than the
>> costs. Historical reasons around the Pascal standards somehow
failed
>> to forge a strong unified standards based community and
codebase,
>> The reasons why don't matter for the result. What counts is how
>> the Pascal standards are conductive to your development. Which
is
>> very little.
>
> Marco, there is strong selection effect here. People on GPC mailing list
> apparently still care about compatibility with non-Borland compiler and
> have large code bases. On the other hand there was small demand for
> Delphi features. Simply, people who need Delphi compatibility choose
> FPC, people who need non-Borland compatibility prefer GPC.
True. But this thread was about advise towards new users migrating from
Mac
being persuaded with one dimensional standarization advocacy. It was not
directed against people choosing GPC for a reason.
> And, while Delphi is quite popular do not underestimate other dialects.
> Before NT Borland was outside enterprise use. Today NT is something like
> 1/3 of servers.
One half.
> So, I would expect that Delphi is a minority for
> server applications.
Compared to ISO pascal? I strongly doubt that.
> BTW the largest open souce Pascal program that I know, SapDB (more than
> 0.5 million lines of Pascal) uses its own compiler (via C).
Lazarus alone tops that. FPC-Lazarus is well over 1.5M (but that is rough
lines not standarised LOC, just file linecounts, so that can be skewed.
Also
while Lazarus doesn't contain much header files, FPC does, and at least
.5M
of that are semi-autoconverted OS headers, and it is not fair to compare
that to carefully crafted battlehardened code)
If you have a good sloc or script program for some Pascal and derivatives,
I'd be happy to run it.
|
