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 
the #1 language implementation:

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 
the #1 language implementation:

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 
the #1 language implementation:

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
 currently the #1 language implementation:
 
 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 overall than for C/++, Java or C#: 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®exmatch=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:
D is #1 because it has ALL tests (source files). IMHO that sucks because it
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...
 D is #1 because it has ALL tests (source files). IMHO that sucks because

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

 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...
 D is #1 because it has ALL tests (source files). IMHO that sucks because it
 doesn't show us anything actually. I think Shootout guys should change this
 practice...

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

Actually, that's not why it's #1 in the great shootout. 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, and they are ranked #2, #4, #13, #16, #19, #21, and #23 within that list. (The #1 ranking language in that list has 2 benchmarks missing.) 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... Ackerman <-- #13 out of the 57 language implementations with this benchmark. Count-words <-- #5 out of the 57 language implementations with this benchmark. Fannkuch <-- #2 out of the 25 language implementations with this benchmark. Fasta <-- #4 out of the 25 language implementations with this benchmark. Harmonic <-- #12 out of the 38 language implementations with this benchmark. Heapsort <-- #1 out of the 57 language implementations with this benchmark. K-nucleotide <-- #1 out of the 15 language implementations with this benchmark. Mandelbrot <-- #6 out of the 31 language implementations with this benchmark. N-body <-- #7 out of the 25 language implementations with this benchmark. Nsieve <-- #1 out of the 34 language implementations with this benchmark. Nsieve-bits <-- #2 out of the 23 language implementations with this benchmark. Object <-- #24 out of the 50 language implementations with this benchmark. Object-methods <-- #2 out of the 49 language implementations with this benchmark. Pidigits <-- #1 out of the 22 language implementations with this benchmark. Random <-- #14 out of the 58 language implementations with this benchmark. Regex <-- #4 out of the 41 language implementations with this benchmark. Reverse-complement <-- #3 out of the 15 language implementations with this benchmark. Spellcheck <-- #1 out of the 48 language implementations with this benchmark. Startup <-- #12 out of the 57 language implementations with this benchmark. Sum-file <-- #1 out of the 56 language implementations with this benchmark. Takfp <-- #15 out of the 45 language implementations with this benchmark. Tcp-echo <-- #2 out of the 8 language implementations with this benchmark. Tcp-request-reply <-- #3 out of the 8 language implementations with this benchmark. Tcp-stream <-- #3 out of the 8 language implementations with this benchmark. Threads <-- #4 out of the 13 language implementations with this benchmark. Threads-flow <-- #10 out of the 15 language implementations with this benchmark. Word-frequency <-- #2 out of the 51 language implementations with this 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 
 the #1 language implementation:
 
 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