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).
Sure, on larger programs the difference is likely to slightly flatten
since memory overheads depends more on algorithm then on compiler.
>> * FPC has limited CPU sup****t, and sup****ts Lazarus, their graphical
>> 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. 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.
> (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.
If you ask if I am willing to install FreeBSD in order to test GPC,
then the answer is no.
>> Stay with original Pascal. Stay with the standard.
>
> My short response:
> - examine your codebase, determine if it matters at all, based on FAQ
material,
> and if the modifications are actually large (or located somewhere).
> While I think FPC is the best choice, there are certainly cases where
ISO
> is the better way. Source inspection, testing and *****ment is the
only
> reasonable way.
> - For new development, go with the industry. Take the Delphi dialect,
> 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.
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. So, I would expect that Delphi is a minority for
server applications.
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).
--
Waldek Hebisch
hebisch@[EMAIL PROTECTED]
|
