www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D is #1 in the Shootout

reply Benji Smith <dlanguage xxagg.com> writes:
I just checked the great computer language shootout, and D is currently 


http://shootout.alioth.debian.org/great/benchmark.php?test=all&lang=all&sort=fullcpu

D is in first place (by a significant margin) in terms of both CPU time 
and memory use (using the default benchmark weighting), and it's in 
fourth place in terms of lines-of-code.

Very cool.

--BenjiSmith
Apr 21 2005
next sibling parent reply John Reimer <John_member pathlink.com> writes:
In article <d49568$rg4$1 digitaldaemon.com>, Benji Smith says...

I just checked the great computer language shootout, and D is currently 


http://shootout.alioth.debian.org/great/benchmark.php?test=all&lang=all&sort=fullcpu

D is in first place (by a significant margin) in terms of both CPU time 
and memory use (using the default benchmark weighting), and it's in 
fourth place in terms of lines-of-code.

Very cool.

--BenjiSmith


Yes, well, this is great.  But, once again, D is the only one without a missing
benchmark.  The compiler/languages most likely able to compete with D - the C
and C++ compilers - are still missing an influencial number of benchmarks.

Let's not give D more credit than it's due. ;-)

I'll bet, though, that the D code is much prettier than the equivalent C/C++
code.  That's enough for me.

-JJR
Apr 21 2005
next sibling parent jicman <jicman_member pathlink.com> writes:
Let's look at it this way: it would take me, 1 week in c, probably 3 days, in
c++, to do what I did in 6 hours with d.  And I was in a very bad situation.
This is why I started using D.

So, the benchmarks will come.  For now, D is the best language ever! :-)


John Reimer says...

In article <d49568$rg4$1 digitaldaemon.com>, Benji Smith says...

I just checked the great computer language shootout, and D is currently 


http://shootout.alioth.debian.org/great/benchmark.php?test=all&lang=all&sort=fullcpu

D is in first place (by a significant margin) in terms of both CPU time 
and memory use (using the default benchmark weighting), and it's in 
fourth place in terms of lines-of-code.

Very cool.

--BenjiSmith


Yes, well, this is great.  But, once again, D is the only one without a missing
benchmark.  The compiler/languages most likely able to compete with D - the C
and C++ compilers - are still missing an influencial number of benchmarks.

Let's not give D more credit than it's due. ;-)

I'll bet, though, that the D code is much prettier than the equivalent C/C++
code.  That's enough for me.

-JJR
Apr 21 2005
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
John Reimer wrote:

 In article <d49568$rg4$1 digitaldaemon.com>, Benji Smith says...
 

 I just checked the great computer language shootout, and D is

 
 http://shootout.alioth.debian.org/great/benchmark.php?test=all&lang=all&sort=fullcpu
 
 D is in first place (by a significant margin) in terms of both CPU
 time and memory use (using the default benchmark weighting), and
 it's in fourth place in terms of lines-of-code.


 
 Yes, well, this is great.  But, once again, D is the only one without
 a missing benchmark.  The compiler/languages most likely able to
 compete with D - the C and C++ compilers - are still missing an
 influencial number of benchmarks.
 
 Let's not give D more credit than it's due. ;-)


Actually, the fact that D has got them all, and C++ (etc) haven't, 
_could_ be construed as telling something about the language itself!

Think about it. The number of C++ users is multiple to those using D. 
And the number of 5+ years' veteran Gurus outnumbers what D has with a 
margin I can't even imagine. (Do you know any D gurus with 5+ years?)

So, what is left, is that D makes it (presumably a lot) easier to write 
some of the more unusual benchmarks. Right?
Apr 21 2005
next sibling parent reply John Reimer <John_member pathlink.com> writes:
In article <426835C9.7080909 nospam.org>, Georg Wrede says...


Actually, the fact that D has got them all, and C++ (etc) haven't, 
_could_ be construed as telling something about the language itself!

Think about it. The number of C++ users is multiple to those using D. 
And the number of 5+ years' veteran Gurus outnumbers what D has with a 
margin I can't even imagine. (Do you know any D gurus with 5+ years?)

So, what is left, is that D makes it (presumably a lot) easier to write 
some of the more unusual benchmarks. Right?


Georg, you put it so well... yes, could be true. :-)

Or maybe the C/C++ programmers just aren't as interested in proving a point in
this little project.

But, it's probably just too much work for them. ;-)

- John
Apr 21 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
It's interesting to not that, none of the 26 languages listed in "The Usual"
Computer Language Shootout have all 27 benchmarks listed there implemented...
http://shootout.alioth.debian.org/benchmark.php?test=all

...and that, none of the 65 languages listed in The Computer Language Shootout
Sandbox have all 30 benchmarks listed there implemented...
http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all

...and that, of the 56 languages listed in The Great Computer Language
Shootout, only the Digital Mars D compiler has all 27 of the benchmarks listed
there implemented...
http://shootout.alioth.debian.org/great/benchmark.php?test=all

I wonder how many of the benchmarks listed in the old Doug Bagley computer
language shootout have been implemented in D so far.  About 13 percent of the
languages in that list have all 25 benchmarks from that list implemented...
http://shootout.alioth.debian.org/old/benchmark.php?test=all

Here's the ones that are in the Doug Bagley list but not in the Great Computer
Shootout list, in case anyone wants to look into that...
ary, echo, except, fibo, hash, hash2, lists, matrix, moments, nestedloop,
prodcons, reversefile, sieve, strcat, sumcol

It's also interesting to look through each list one language at a time, and
note how many languages had errors or time-outs on one or more benchmark.

TZ
Apr 23 2005
prev sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Georg Wrede schrieb:

 Actually, the fact that D has got them all, and C++ (etc) haven't, 
 _could_ be construed as telling something about the language itself!
 
 Think about it. The number of C++ users is multiple to those using D. 
 And the number of 5+ years' veteran Gurus outnumbers what D has with a 
 margin I can't even imagine. (Do you know any D gurus with 5+ years?)
 
 So, what is left, is that D makes it (presumably a lot) easier to write 
 some of the more unusual benchmarks. Right?


Don't forget: there may be relatively few D users, but many of them 
*want* to prove that D is better. C++ users don't have any incentive to 
prove anything. Very few of the gurus even believe that their language 
is superior. They simply stick with what has proven to be good enough 
for them.

The best way to test D's superiority would therefore be, if experienced 
D programmers try write high quality code in C++, putting in the same 
effort as in the D code. Only if this is done honestly, the outcome of 
the shootout has some real meaning.

(Comparing with other languages than C++ probably has little meaning, 
since they either are too different or (like C) too similar to a subset 
to D.)
Apr 22 2005
next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <d4b2p4$2k7k$1 digitaldaemon.com>, Norbert Nemec says...

Georg Wrede schrieb:

 Actually, the fact that D has got them all, and C++ (etc) haven't, 
 _could_ be construed as telling something about the language itself!
 
 Think about it. The number of C++ users is multiple to those using D. 
 And the number of 5+ years' veteran Gurus outnumbers what D has with a 
 margin I can't even imagine. (Do you know any D gurus with 5+ years?)
 
 So, what is left, is that D makes it (presumably a lot) easier to write 
 some of the more unusual benchmarks. Right?


Don't forget: there may be relatively few D users, but many of them 
*want* to prove that D is better. C++ users don't have any incentive to 
prove anything. Very few of the gurus even believe that their language 
is superior. They simply stick with what has proven to be good enough 
for them.

The best way to test D's superiority would therefore be, if experienced 
D programmers try write high quality code in C++, putting in the same 
effort as in the D code. Only if this is done honestly, the outcome of 
the shootout has some real meaning.

(Comparing with other languages than C++ probably has little meaning, 
since they either are too different or (like C) too similar to a subset 
to D.)


Some of the submitted code was actually marginally slower in order to
differentiate D from C and C++. Otherwise, I figured, what's the point?

By way of example, the use of foreach instead of array indexing in just about
every applicable case. Also, IIRC, the use of classes instead of structs in a
few places, and I don't think explicit pointers are used in any of it except for
one case with 'in' and an AA (afterall, that is the 'D way'). Attributes like
static, const and final were not used unless it made sense in the context of the
algorithm. The one exception is the 'package' attribute in the method-call test,
but again, part of the reason that was left in was to show a language feature
different than C++ (and that test makes no difference for the current default
results anyhow).

Also, the D arrays and the GC were used throughout even though in a few places
pointers & malloc/free may have performed a bit better. Plus there was no use of
allocators and such even though that probably could have made a large difference
in a few cases.

No doubt the primary goal was to be competitive in performance. But, a fair
amount of time was spent analyzing different semantics for the same algorithms
out of curiosity and a desire to pass along information that may be useful. In
the end when it came down to submitting either 'D' code vs. 'C' code for a few
percent difference in performance, the 'D' code was submitted.

foreach vs. array indexing, pointers, etc. does not seem to make much of a
difference either way for most things. And I'm guessing that cases where 'C
style' code does perform a bit better will be stamped out by subsequent compiler
and GC releases.

The things I took away from this are:

- D code is fast
- OOP-style code is fast w/o needing to pepper the code with attributes solely
for performance reasons.
- The compiler and library implementers have done a great job for a language in
this stage of development.
- Dropping to C code is not needed to get good performance, but the option is
there.

Specific things I would apply to 'real-world' code:

- Array slicing performs very well
- The 'first generation' GC works pretty well as long as you're not counting on
it to allocate a lot of small objects in a tight loop (slice instead <g>).
- The Buffered I/O objects perform very well.
- The built-in AA's are competitive.
- D arrays are just as fast as C arrays.
- foreach is, for the most part, as efficient as index iteration.
- There is _generally_ not a performance penalty between using OOP and
procedural code when allocation and initialization is not an issue.

In other words, from my perspective, performance is not a reason to forgo any of
the major features of D and start writing C code.

I think the people submitting the C and C++ code did spend extra time to get the
best performance (for the most part). There are some cases where the C and C++
implementers seemed to have gone over-and-above what one would 'normally' write
in order to maximize performance:

http://shootout.alioth.debian.org/great/benchmark.php?test=wc&lang=gcc&id=0&sort=fullcpu
http://shootout.alioth.debian.org/great/benchmark.php?test=spellcheck&lang=gpp&id=0&sort=fullcpu

In any case, the D code generally came out a lot cleaner than most of the C/++
code for the less trivial cases, and the LOC avg. is quite a bit lower for D


http://shootout.alioth.debian.org/great/benchmark.php?test=all&lang=all&sort=fullcpu&xfullcpu=0&xmem=0&xloc=1&ackermann=1&wc=3&fannkuch=3&fasta=3&harmonic=1&heapsort=4&knucleotide=4&mandelbrot=4&nbody=3&nsieve=3&nsievebits=2&objinst=0&methcall=0&pidigits=2&random=3&regexmatch=4&revcomp=3&spellcheck=4&hello=0&sumcol=3&takfp=1&tcpecho=2&tcprequest=4&tcpstream=3&process=2&message=5&wordfreq=5

Anyway you slice this info., D performed well in the Shootout, IMHO. And I'm
guessing there is better to come from both Digital Mars and other compilers.

What is really good news to me is that D can certainly be considered competitive
now w/o having to jump through semantic hoops, and can get even faster.

- Dave
Apr 23 2005
parent reply Dejan Lekic <leka entropy.tmok.com> writes:

doesn't show us anything actually. I think Shootout guys should change this
practice...

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
Apr 23 2005
next sibling parent "Walter" <newshound digitalmars.com> writes:
"Dejan Lekic" <leka entropy.tmok.com> wrote in message
news:d4e15i$22hh$1 digitaldaemon.com...




it

 doesn't show us anything actually. I think Shootout guys should change


this

 practice...


I don't. It mitigates the problem of only submitting test cases for which a
language works well. If anyone feels that a language is unfairly penalized
because it didn't do many tests, that person is free to submit
implementations of those tests.
Apr 23 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Dejan Lekic" <leka entropy.tmok.com> wrote in message
news:d4e15i$22hh$1 digitaldaemon.com...


 doesn't show us anything actually. I think Shootout guys should change this
 practice...

 -- 
 ...........
 Dejan Lekic
   http://dejan.lekic.org



If you look in the old Doug Bagley shootout,
you will find that there are 7 listed there as having
implemented all of the benchmarks for that category,



In fact,
if you look at the number of missing benchmarks for each
language listed in The Great Computer Language Shootout,
you will see that although those with more missing benchmarks
tend to rank lower on the average,
they are not simply ranked according to
how many benchmarks are implemented.
In fact, the formula for calculating a languages score
is given on that page,
and it shows that a missing benchmark simply means
no score added for that benchmark...
which seems fair enough.

You can also check each benchmark individually.

Here's a quick rundown of Digital Mars D's rank within each benchmark test...














benchmark.




benchmark.






benchmark.




benchmark.

If anyone cares to re-count, please feel free to correct me if I made any
errors.
Clearly, the comparison is not biased.
It does show D's weak spots in terms of performance.
Particularly, initializing objects (which makes sense because they are "fully"
initialized) and...
sending messages between linked threads.

It would be nice though to see an option added to the benchmark comparisons
that would eliminate those benchmarks that any language implementation in the
list
were missing, but I don't suppose there would be many benchmarks left.

TZ
Apr 23 2005
prev sibling next sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Norbert Nemec" <Norbert Nemec-online.de> wrote in message
news:d4b2p4$2k7k$1 digitaldaemon.com...

 Georg Wrede schrieb:

 Actually, the fact that D has got them all, and C++ (etc) haven't,
 _could_ be construed as telling something about the language itself!

 Think about it. The number of C++ users is multiple to those using D.
 And the number of 5+ years' veteran Gurus outnumbers what D has with a
 margin I can't even imagine. (Do you know any D gurus with 5+ years?)

 So, what is left, is that D makes it (presumably a lot) easier to write
 some of the more unusual benchmarks. Right?


 Don't forget: there may be relatively few D users, but many of them
 *want* to prove that D is better. C++ users don't have any incentive to
 prove anything. Very few of the gurus even believe that their language
 is superior. They simply stick with what has proven to be good enough
 for them.

 The best way to test D's superiority would therefore be, if experienced
 D programmers try write high quality code in C++, putting in the same
 effort as in the D code. Only if this is done honestly, the outcome of
 the shootout has some real meaning.

 (Comparing with other languages than C++ probably has little meaning,
 since they either are too different or (like C) too similar to a subset
 to D.)


Never fool yourself into believing that there are a shortage of C or C++
enthusiasts.  True, most of the C enthusiasts only want to prove that C is
better than C++ and most of the C++ enthusiasts only want to prove that C++ is
better than C, but there are many of both... and have been, for a very long
time.

TZ
Apr 23 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Norbert Nemec" <Norbert Nemec-online.de> wrote in message
news:d4b2p4$2k7k$1 digitaldaemon.com...

 Georg Wrede schrieb:

 Actually, the fact that D has got them all, and C++ (etc) haven't,
 _could_ be construed as telling something about the language itself!

 Think about it. The number of C++ users is multiple to those using D.
 And the number of 5+ years' veteran Gurus outnumbers what D has with a
 margin I can't even imagine. (Do you know any D gurus with 5+ years?)

 So, what is left, is that D makes it (presumably a lot) easier to write
 some of the more unusual benchmarks. Right?


 Don't forget: there may be relatively few D users, but many of them
 *want* to prove that D is better. C++ users don't have any incentive to
 prove anything. Very few of the gurus even believe that their language
 is superior. They simply stick with what has proven to be good enough
 for them.

 The best way to test D's superiority would therefore be, if experienced
 D programmers try write high quality code in C++, putting in the same
 effort as in the D code. Only if this is done honestly, the outcome of
 the shootout has some real meaning.

 (Comparing with other languages than C++ probably has little meaning,
 since they either are too different or (like C) too similar to a subset
 to D.)


Never fool yourself into believing that there are a shortage of C or C++
enthusiasts.
True, most of the C enthusiasts only want to prove that C is better than C++
and most of the C++ enthusiasts only want to prove that C++ is better than C,
but there are many of both... and have been, for a very long time.

In fact, there are probably more enthusiasts for either one
of those languages than D even has "programmers" as of yet,
simply because both C and C++ have been popular and in
direct competition with each other for so long.
The D language is practically unheard of in comparison.

TZ
Apr 23 2005
prev sibling parent Daniel Siegmann <gandalf optonline.net> writes:
John Reimer wrote:

 Let's not give D more credit than it's due. ;-)


While I agree with this, more exposure for D is always a good thing. :)

--
Daniel Siegmann
Apr 21 2005
prev sibling next sibling parent reply "Bob W" <nospam aol.com> writes:
"Benji Smith" <dlanguage xxagg.com> wrote in message 
news:d49568$rg4$1 digitaldaemon.com...
.......

 D is in first place (by a significant margin) in terms of both CPU time


.......

 Very cool.

 --BenjiSmith


Just try to set the weight fields to zero where
other competitors have no programs available
(e.g. Intel C) and DmD is clearly trailing
Intel C, gcc gets a close third. But I would
regard this as being still a very good score
for D - maybe still a touch too good,
because one thing made me suspicious:

All D programs are implemented in the
benchmarks, while most others are not.
So I presumed that a genuine D enthusiast
was not only completing the programs, he
was also 'polishing' the D code.

One example is the ackermann function:
On a windows system the raw CPU time
almost doubles in D if the same code for
"int Ack()" is used as found in the C variant.
(This does not work vice versa, however.)

Furthermore I have not found any apps
yet where D 0.121 could beat gcc 3.43 on
a Windows system in terms of execution
speed (compile time is a different story).

In general I tend to agree to some other
posts stating the drastically reduced
development time in D being its greatest
virtue. D's package of development
time, compile time and execution speed
combined is probably good enough to beat
anything out there IMHO.
Apr 21 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Bob W" <nospam aol.com> wrote in message
news:d49fts$14rd$1 digitaldaemon.com...

 Just try to set the weight fields to zero where
 other competitors have no programs available
 (e.g. Intel C) and DmD is clearly trailing
 Intel C, gcc gets a close third. But I would
 regard this as being still a very good score
 for D - maybe still a touch too good,
 because one thing made me suspicious:

 All D programs are implemented in the
 benchmarks, while most others are not.
 So I presumed that a genuine D enthusiast
 was not only completing the programs, he
 was also 'polishing' the D code.


Of course that's true. davejf did the hard work implementing all the D
versions. He also made some suggestions for speeding up D, which were
incorporated. And there's nothing at all nefarious about that. There's
nothing dirty going on (like specially recognizing the benchmarks and
putting out hand-tuned assembler, as one compiler vendor did years ago).
Rather, it reflects the enthusiasm of Dave and our interest in making D
perform well.



 One example is the ackermann function:
 On a windows system the raw CPU time
 almost doubles in D if the same code for
 "int Ack()" is used as found in the C variant.
 (This does not work vice versa, however.)


If the D technique for making it faster doesn't work in C, isn't the problem
with C, rather than with D? It is true, however, that one can use D as a "C
compiler" and essentially write C. It'll perform about exactly like compiled
C would, especially since DMD and DMC share the optimizer and code
generator.


 Furthermore I have not found any apps
 yet where D 0.121 could beat gcc 3.43 on
 a Windows system in terms of execution
 speed (compile time is a different story).


Here's one: www.digitalmars.com/d/cppstrings.html


 In general I tend to agree to some other
 posts stating the drastically reduced
 development time in D being its greatest
 virtue. D's package of development
 time, compile time and execution speed
 combined is probably good enough to beat
 anything out there IMHO.


I'm very pleased with the results of the D speed tests, especially
considering that the optimizer and code generator being used by DMD are
little changed in the last 10 years, and is tuned for C code, not D code.
There are a lot of optimization opportunities possible in D that are not
explored. To do so well compared to compilers that have been aggressively
developed as optimizing compilers by engineers thoroughly familiar with the
target CPU chips, is doing rather well.
Apr 21 2005
parent "Bob W" <nospam aol.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d49pck$1c5d$1 digitaldaemon.com...
......

 So I presumed that a genuine D enthusiast
 was not only completing the programs, he
 was also 'polishing' the D code.


 There's nothing dirty going on .......
 ...... reflects the enthusiasm of Dave and our interest in
 making D perform well.


There was no intention at all to smell dirty tricks.
It just seemed impossible to me at this stage that
D is beating Intel C that easily if Intel wasn't penalized
for missing benchmark programs. I am equally
interested to see D getting a boost, because I
am absolutely convinced that D is the answer to
most prayers of tortured programmers everywhere.




 ....... It'll perform about exactly like compiled
 C would, especially since DMD and DMC share the
 optimizer and code generator.


That is where I am expecting Intel to recognize
the new realities and contribute generously to
the D development. We all would throw away
our AMD cpu's to show our gratitude to
Chipzilla, wouldn't we?   ; )




 Furthermore I have not found any apps
 yet where D 0.121 could beat gcc 3.43 on
 a Windows system in terms of execution
 speed (compile time is a different story).


 Here's one: www.digitalmars.com/d/cppstrings.html


Yeah, right. But even Pascal could beat C on
this one in the good ol' days. It probably would
have been better for me to write "any of my apps"
instead of "any apps". Take this as a correction
to my previous post.




 ........ opportunities possible in D that are not explored.
 To do so well compared to compilers that have been aggressively
 developed as optimizing compilers by engineers thoroughly familiar
 with the target CPU chips, is doing rather well.


I started to get impressed already some time
ago when I have recognized that D can take on its
parent (dmc) and is aparently lacking 'alpha stage
performance deficiencies'. Good job (once again)!
Apr 22 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bob W wrote:


 Furthermore I have not found any apps
 yet where D 0.121 could beat gcc 3.43 on
 a Windows system in terms of execution
 speed (compile time is a different story).


This is confused. While DMD 0.121 is fast,
you can get D for GCC 3.4.3 if you like that
back-end better ? It would be more "fair" to
compare DMC with GCC (C), and DMD with GDC (D) ?
(to compare the output of the actual compilers)

However, I think GCC loses out to both the Intel
compiler for X86, and the IBM compiler for PPC ?
When it comes to speed, that is. I think the price
for GCC is right :-), and is definitely more open.


Or DMC with DMD and GCC with GDC, if you want to
compare the result from using different languages ?

The only main thing (speedwise) that I find lacking
in D (the language) right now is SIMD vectorization...

Otherwise I find D to be "fast", as far languages go.
(moral: use "DMD" for the reference D compiler name)

--anders

PS.
I like DMC / DMD too, but there is no Mac/PPC version ?
I like GCC because it is portable, and CodeWarrior too.
(it's hard to motivate the cost of CW after Xcode, though...
So nowadays I am using GCC and GDB, instead of CodeWarrior)
Apr 22 2005
parent reply "Bob W" <nospam aol.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d4abp4$2071$1 digitaldaemon.com...

 Bob W wrote:



 This is confused. While DMD 0.121 is fast,
 you can get D for GCC 3.4.3 if you like that
 back-end better ?


I don't, unless I need it in terms of code generation,
compatibility or GNU C extensions, C99, etc.,
because gcc compiler (-O3) and linker are dreadfully
slow. That might have changed with gcc 4.0 just a
little bit, but I have not tried the 4.0, since it was
released only 2 days ago. So one slow compiler/linker
system on my computer is enough. No GDC, sorry.




 It would be more "fair" to
 compare DMC with GCC (C), and DMD with GDC (D) ?
 (to compare the output of the actual compilers)


It would, but I will always use and compare to
whatever suits me best. Comparison will not be
scientific in nature (neither are the benchmarks
we're talking about). Running DMC on my machine
is no option for various reasons, and GDC is no option
because I strongly suspect that compile/link times
will be as frustratingly slow as these of my gcc.
So my comparison is between the best C compiler
for me (gcc) and the best language/compiler/linker
combination I have found over the past years (DMD).




 However, I think GCC loses out to both the Intel
 compiler for X86, and the IBM compiler for PPC ?
 When it comes to speed, that is. I think the price
 for GCC is right :-), and is definitely more open.


I agree. Furthermore gcc caught me a couple of
years ago with their features, so any other C compiler
won't do my programs any good. Should I ever
wish to rewrite them, I might opt to port them to D.
Apr 22 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bob W wrote:


 I don't, unless I need it in terms of code generation,
 compatibility or GNU C extensions, C99, etc.,
 because gcc compiler (-O3) and linker are dreadfully
 slow. That might have changed with gcc 4.0 just a
 little bit, but I have not tried the 4.0, since it was
 released only 2 days ago. So one slow compiler/linker
 system on my computer is enough. No GDC, sorry.


GCC 3 is a lot slower than GCC 2 was (better too, but)
I've heard GCC 4 sets it straight again, and then some.

I'm using ccache, which I've found to be a great help.
(and of course, it doesn't help much the first time)


 I agree. Furthermore gcc caught me a couple of
 years ago with their features, so any other C compiler
 won't do my programs any good. Should I ever
 wish to rewrite them, I might opt to port them to D.


I normally write portable programs... And mostly for legacy.
So I haven't been using any GCC-only features (just stuff
like inline, that are optional) Some Mac-only stuff, though.
Then again, I'm not using C++ very much. Just plain old C.

--andersr
Apr 22 2005
parent reply "Bob W" <nospam aol.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d4ard8$2cl8$1 digitaldaemon.com...

 Bob W wrote:


 I don't, unless I need it in terms of code generation,
 compatibility or GNU C extensions, C99, etc.,
 because gcc compiler (-O3) and linker are dreadfully
 slow. That might have changed with gcc 4.0 just a
 little bit, but I have not tried the 4.0, since it was
 released only 2 days ago. So one slow compiler/linker
 system on my computer is enough. No GDC, sorry.


 GCC 3 is a lot slower than GCC 2 was (better too, but)
 I've heard GCC 4 sets it straight again, and then some.


I hope you are right. I am still suspicious: a 20% compile
speed increase won't help much, GCC needs at least several
100% in order to compete with the fast guys (dmc, lcc, VC).
If it hadn't all the other advantages I would have probably
dumped it a long time ago.



 I'm using ccache, which I've found to be a great help.
 (and of course, it doesn't help much the first time)


Maybe I am wrong, but I guess ccache won't help me
because of my programming style:

Ever since I have stopped writing commercial programs
I have also stopped using make, modules, unnecessary
header files, etc. I'd rather #include my own library sources
to new code instead of using precompiled libraries.
Everytime I change my code or my compiler, my programs
get a compulsary clean buid. That is why I like the compilers,
CPUs and hard drives to be as fast as possible. I know it
does not always work this way but I'd curse myself if
I started to use conventional C programming techniques
again for casual applications.




 I normally write portable programs... And mostly for legacy.
 So I haven't been using any GCC-only features (just stuff
 like inline, that are optional) Some Mac-only stuff, though.
 Then again, I'm not using C++ very much. Just plain old C.


In my case: (almost) never portable, never legacy. GCC
gives me nested functions, so I gladly use them. Believe
me, this feature helps if someone like me is stupid enough
to pack up to several 100k of source code in one file.

But if D succeeds we can anyway happily throw away
all of our C sources - after having them ported to D
of course.  : )
Apr 22 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bob W wrote:


 Ever since I have stopped writing commercial programs
 I have also stopped using make, modules, unnecessary
 header files, etc. I'd rather #include my own library sources
 to new code instead of using precompiled libraries.


You write everything yourself ? No libraries ? Wow. Or "ouch"...
I guess that build helpers or packagers are totally "out" then ?


 Everytime I change my code or my compiler, my programs
 get a compulsary clean buid. That is why I like the compilers,
 CPUs and hard drives to be as fast as possible. I know it
 does not always work this way but I'd curse myself if
 I started to use conventional C programming techniques
 again for casual applications.


ccache is especially good for that "clean rebuild" scenario...

The idea with ccache is that you only have to run the preprocessor on
the code. If the hash result of that (and the compiler) hasn't changed, 
neither has the object code so it just hands you a copy from the cache.
It's at http://ccache.samba.org/

Make is otherwise good at keeping track of what needs compiling ?


 In my case: (almost) never portable, never legacy. GCC
 gives me nested functions, so I gladly use them. Believe
 me, this feature helps if someone like me is stupid enough
 to pack up to several 100k of source code in one file.


Pleasure to meet you sir, there's not too many Real Men left ? :-)

Let's just say that our programming methodology varies. A lot...

--anders
Apr 22 2005
parent reply "Bob W" <nospam aol.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d4b54n$2lru$2 digitaldaemon.com...


 You write everything yourself ? No libraries ? Wow. Or "ouch"...


"Ouch" is correct. But as long as it is fun and nobody
asks me whether I'll be able to meet the deadline, its ok.
It is no challenge to use qsort() if it is not completely
rewritten for inlining before it is used, don't you think so?
And it would be just a touch too easy to use memcpy,
my own version is faster. This might have saved me
a couple of millisecs per week on average.




 I guess that build helpers or packagers are totally "out" then ?


How did you know this? You can add debuggers to the
"out" group as well. I have used one a couple of years
back though. Conclusions: What for? No fun!




 ccache is especially good for that "clean rebuild" scenario...

 The idea with ccache is that you only have to run the preprocessor on
 the code. If the hash result of that (and the compiler) hasn't changed, 
 neither has the object code so it just hands you a copy from the cache.
 It's at http://ccache.samba.org/


What copy? Under normal circumstances I'll get one
big object file and this changes every time I recompile.
While I can imagine that ccache is useful for the standard
way of doing C, I am still doubting that it can do me any
good if I insist of having one file for each of my projects.
But I'll have a closer look sooner or later. Thanks for the
hint anyway.




 Make is otherwise good at keeping track of what needs compiling ?


Same thing: one single source (with several source code
includes) gets usually compiled. Therefore I stopped using
'make' some time ago, because it just doesn't make sense
for my environment.




 In my case: (almost) never portable, never legacy. GCC
 gives me nested functions, so I gladly use them. Believe
 me, this feature helps if someone like me is stupid enough
 to pack up to several 100k of source code in one file.


 Pleasure to meet you sir, there's not too many Real Men left ? :-)


It is actually getting better nowadays. I started (reluctantly) to
add sufficient comments to my code. This keeps me from dumping
my old programs and rewriting them for simplicity reasons, if
I ever need to change them.
Apr 22 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
The First OT: anybody ever wonder why my posts look decent in comparson 
with some others?

Two things:

1) I use a decent newsreader.

2) I care about how pople reading and responding to my post (and even 
more, people responding) would feel.

Bob W wrote:

 "Anders F Björklund" <afb algonet.se> wrote in message 
 news:d4b54n$2lru$2 digitaldaemon.com...
 

 You write everything yourself ? No libraries ? Wow. Or "ouch"...


 
 "Ouch" is correct. But as long as it is fun and nobody asks me
 whether I'll be able to meet the deadline, its ok. It is no challenge
 to use qsort() if it is not completely rewritten for inlining before
 it is used, don't you think so? And it would be just a touch too easy
 to use memcpy, my own version is faster. This might have saved me a
 couple of millisecs per week on average.
 

 I guess that build helpers or packagers are totally "out" then ?


 
 How did you know this? You can add debuggers to the "out" group as
 well. I have used one a couple of years back though. Conclusions:
 What for? No fun!
 

 ccache is especially good for that "clean rebuild" scenario...
 
 The idea with ccache is that you only have to run the preprocessor
 on the code. If the hash result of that (and the compiler) hasn't
 changed, neither has the object code so it just hands you a copy
 from the cache. It's at http://ccache.samba.org/


 
 What copy? Under normal circumstances I'll get one big object file
 and this changes every time I recompile. While I can imagine that
 ccache is useful for the standard way of doing C, I am still doubting
 that it can do me any good if I insist of having one file for each of
 my projects. But I'll have a closer look sooner or later. Thanks for
 the hint anyway.
 

 Make is otherwise good at keeping track of what needs compiling ?


 
 Same thing: one single source (with several source code includes)
 gets usually compiled. Therefore I stopped using 'make' some time
 ago, because it just doesn't make sense for my environment.
 

 In my case: (almost) never portable, never legacy. GCC gives me
 nested functions, so I gladly use them. Believe me, this feature
 helps if someone like me is stupid enough to pack up to several
 100k of source code in one file.


 
 Pleasure to meet you sir, there's not too many Real Men left ? :-)


 
 It is actually getting better nowadays. I started (reluctantly) to 
 add sufficient comments to my code. This keeps me from dumping my old
 programs and rewriting them for simplicity reasons, if I ever need to
 change them.


Hmm, seems to me that some of the Religiously Touted Rights are actually 
worth something. For the rest, there just might be a few other Religious 
Rights there to catch.

(I remember the time when I had no respect for Dynamic Data Structures. 
And this lack of respect was only due to me not respecting the professor 
of that time.)
Apr 22 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 23 Apr 2005 03:17:16 +0300, Georg Wrede wrote:


 The First OT: anybody ever wonder why my posts look decent in comparson 
 with some others?
 
 Two things:
 
 1) I use a decent newsreader.


You do!? I thought you used "Mozilla Thunderbird 1.0" ;-)


 2) I care about how pople reading and responding to my post (and even 
 more, people responding) would feel.


I assume you mean "people" instead of "pople" ;-)

Just kidding - Aussies in general love pulling the rug from under people
who appear a bit 'haughty' and/or 'righteous'.

-- 
Derek Parnell
Melbourne, Australia
23/04/2005 10:50:43 AM
Apr 22 2005
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Funny, I haven't seemed to have that much trouble with them...?

-[Unknown]



 Just kidding - Aussies in general love pulling the rug from under people
 who appear a bit 'haughty' and/or 'righteous'.
Apr 23 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 22 Apr 2005 23:54:12 +0200, Bob W wrote:


 "Anders F Björklund" <afb algonet.se> wrote in message 
 news:d4b54n$2lru$2 digitaldaemon.com...
 

 You write everything yourself ? No libraries ? Wow. Or "ouch"...


 
 "Ouch" is correct. But as long as it is fun and nobody
 asks me whether I'll be able to meet the deadline, its ok.


Oh, I get it. "Programming as Recreation". You sir, are truly a sick
individual ;-) (Actually, I can't wait til retirement so I can work on
stuff just for fun)

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
23/04/2005 10:43:33 AM
Apr 22 2005
parent reply "Bob W" <nospam aol.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1txm059grodvd.w2mb3y1hiw1l.dlg 40tude.net...

 On Fri, 22 Apr 2005 23:54:12 +0200, Bob W wrote:


 "Ouch" is correct. But as long as it is fun and nobody
 asks me whether I'll be able to meet the deadline, its ok.


 Oh, I get it. "Programming as Recreation". You sir, are truly a sick
 individual ;-)



After being attacked by Australian fierce creatures ...

{
-  A cockatoo bit me in my finger when I ran
    out of sunflower seeds in the Dandenongs.

-  A group of 'sheilas' teamed up with my girlfriend
   and forced me to acknowledge on the spot that
   people who are owning the heavier suitcases are
   not necessarily obliged to carry them.
}

... I am getting addressed as a sick individual now.
And this after leaving the Aussies all my precious
tourist money and overheating their booming
economy.

They have punished me even further by arranging
the coldest Australian summer imaginable. I bet
you were getting some nice warm days immediately
after my departure!

Actually -- we both loved every minute of our stay.
Melbourne must be one of the best places on earth
(Sydney probably won't agree).





 (Actually, I can't wait til retirement so I can work on
 stuff just for fun)


After happily programming & hardware designing I
formed a company, got bored, sold it after a couple
of years and now I am trying hard to waste my time
and spend all the money left, thus forcing my way
back to normal work (including makefiles and
proper documentation), unless a miracle saves
me from that.


What does that all have to do with D? I don't
know. I am probably just misusing this forum.

Sorry 'bout that.
Apr 23 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Bob W" <nospam aol.com> wrote in message
news:d4dcvc$1i00$1 digitaldaemon.com...

 "Derek Parnell" <derek psych.ward> wrote in message
 news:1txm059grodvd.w2mb3y1hiw1l.dlg 40tude.net...

 On Fri, 22 Apr 2005 23:54:12 +0200, Bob W wrote:


 "Ouch" is correct. But as long as it is fun and nobody
 asks me whether I'll be able to meet the deadline, its ok.


 Oh, I get it. "Programming as Recreation". You sir, are truly a sick
 individual ;-)



 After being attacked by Australian fierce creatures ...

 {
 -  A cockatoo bit me in my finger when I ran
     out of sunflower seeds in the Dandenongs.

 -  A group of 'sheilas' teamed up with my girlfriend
    and forced me to acknowledge on the spot that
    people who are owning the heavier suitcases are
    not necessarily obliged to carry them.
 }

 ... I am getting addressed as a sick individual now.
 And this after leaving the Aussies all my precious
 tourist money and overheating their booming
 economy.

 They have punished me even further by arranging
 the coldest Australian summer imaginable. I bet
 you were getting some nice warm days immediately
 after my departure!

 Actually -- we both loved every minute of our stay.
 Melbourne must be one of the best places on earth
 (Sydney probably won't agree).





 (Actually, I can't wait til retirement so I can work on
 stuff just for fun)


 After happily programming & hardware designing I
 formed a company, got bored, sold it after a couple
 of years and now I am trying hard to waste my time
 and spend all the money left, thus forcing my way
 back to normal work (including makefiles and
 proper documentation), unless a miracle saves
 me from that.


 What does that all have to do with D? I don't
 know. I am probably just misusing this forum.

 Sorry 'bout that.


Hey... programming is supposed to be fun.
Those who don't enjoy it should find an occupation that they do enjoy.  :)
Too many people see programming as drudgery that they have to put up with.
Good to see people here enjoying the experience.

TZ
Apr 23 2005
prev sibling parent clayasaurus <clayasaurus gmail.com> writes:
Impressive, now I can show off to everyone how cool D is :-)

Benji Smith wrote:

 I just checked the great computer language shootout, and D is currently 

 
 http://shootout.alioth.debian.org/great/benchmark.php?test=all&l
ng=all&sort=fullcpu 
 
 
 D is in first place (by a significant margin) in terms of both CPU time 
 and memory use (using the default benchmark weighting), and it's in 
 fourth place in terms of lines-of-code.
 
 Very cool.
 
 --BenjiSmith
Apr 21 2005