www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - No D in Great Computer Language Shootout?

reply S <<S S.com>> writes:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=threadring&lang=all

2.3Go6g8g#3 20.6120.613,2723470%100%0%0%

Interestingly, the CPU load is kind of comical for something spawning 
so many threads.

Anyone good at optimized D feel like commiting a version of this?
Dec 11 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, Dec 11, 2009 at 12:53 PM, S < <S s.com> wrote:
 http://shootout.alioth.debian.org/u64q/benchmark.php?test=3Dthreadring&la=

 2.3Go=A06g=A08g=A0#3 20.6120.613,272347=A0=A00%=A0100%=A00%=A00%

 Interestingly, the CPU load is kind of comical for something spawning so
 many threads.

 Anyone good at optimized D feel like commiting a version of this?

D used to be there, but the folks running the shootout de-listed it for some reason. Maybe it was lack of a 64-bit compiler? --bb
Dec 11 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 D used to be there, but the folks running the shootout de-listed it
 for some reason.
 Maybe it was lack of a 64-bit compiler?

I think the notgentle person that manages the Shootout site has removed D because D programs were too much similar to the C programs. He is looking for very different code, not slight variations. Bye, bearophile
Dec 11 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Bill Baxter:
 D used to be there, but the folks running the shootout de-listed it
 for some reason.
 Maybe it was lack of a 64-bit compiler?


different code, not slight variations.
 Bye,
 bearophile

Yeah, I think it would be much more interesting (for C++ as well as D) to see benchmarks in idiomatic D style. This will likely be slower than code written in the C-like subset, as there is really not much reason why C-like D code should be any slower than C. However, it will give a better indication of how much the abstractions present in D really cost if you choose to use them.
Dec 11 2009
parent bearophile <bearophileHUGS lycos.com> writes:
dsimcha:

 Yeah, I think it would be much more interesting (for C++ as well as D) to see
 benchmarks in idiomatic D style.  This will likely be slower than code written
in
 the C-like subset, as there is really not much reason why C-like D code should
be
 any slower than C.  However, it will give a better indication of how much the
 abstractions present in D really cost if you choose to use them.

I agree. For example D programs compiled with LDC are about as fast as C programs compiled with GCC if those D programs use only C features. But essentially most D1 features that are not present in C lead to slow or very slow programs, when compiled with ldc (like interfaces, dynamic array appends, etc, etc). Anyway, the Shootout allows you to have more than one version of the same code, so you can put two versions of the same D program, one high level and one lower level. This was a C-style version of the D k-nucleotide benchmark: http://shootout.alioth.debian.org/debian/benchmark.php?test=knucleotide&lang=dlang&id=3 And my higher level version of the same benchmark (in this case the higher level is faster, but usually it's the opposite): http://shootout.alioth.debian.org/debian/benchmark.php?test=knucleotide&lang=gdc&id=1 Bye, bearophile
Dec 11 2009
prev sibling next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Bill Baxter Wrote:

 Hmm.  And Go qualifies because it has some CSP implementation built in?
 Or is it more because it has a billion-dollar company built in?  Kinda
 makes you wonder.
 
 --bb

Yeah, and if you look at the "Alternatives" to C++ on this page, C and Go are mentioned, but not D because of some bias. http://harmful.cat-v.org/software/c++/
Dec 11 2009
prev sibling next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

bearophile wrote:
 Bill Baxter:
 D used to be there, but the folks running the shootout de-listed it
 for some reason.
 Maybe it was lack of a 64-bit compiler?

I think the notgentle person that manages the Shootout site has removed=

ing for very different code, not slight variations.
=20

plus 2 for C++, not counting the Java and C# versions... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Dec 11 2009
parent reply Brad Roberts <braddr bellevue.puremagic.com> writes:
On Fri, 11 Dec 2009, "J?r?me M. Berger" wrote:

 bearophile wrote:
 Bill Baxter:
 D used to be there, but the folks running the shootout de-listed it
 for some reason.
 Maybe it was lack of a 64-bit compiler?

I think the notgentle person that manages the Shootout site has removed D because D programs were too much similar to the C programs. He is looking for very different code, not slight variations.

plus 2 for C++, not counting the Java and C# versions... Jerome

Sorry for replying deep into the thread rather than the earlier post, but this is the one I have handy... This community has a lot of bad habits. The particularly dangerous one demonstrated well in this thread is that of making assumptions about intent. D isn't listed in the shootout, it once was. We don't know the facts about why so we like to make the up. Its human. But it's really harmful. Another really good example: Silence on a top tends to be equated with rejection, especially when it comes to why whatever it was hasn't been implemented yet. The majority of the time that's not the reason for the silence.. it's merely a matter of 'haven't gotten to it yet' or 'didn't see it amongst the hundreds of other things'. Later, Brad
Dec 11 2009
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Brad Roberts Wrote:

 This community has a lot of bad habits.  The particularly dangerous one 
 demonstrated well in this thread is that of making assumptions about 
 intent.  D isn't listed in the shootout, it once was.  We don't know the 
 facts about why so we like to make the up.  Its human.  But it's really 
 harmful.
 
 Another really good example:  Silence on a top tends to be equated with 
 rejection, especially when it comes to why whatever it was hasn't been 
 implemented yet.  The majority of the time that's not the reason for the 
 silence.. it's merely a matter of 'haven't gotten to it yet' or 'didn't 
 see it amongst the hundreds of other things'.
 
 Later,
 Brad
 

The comment I made, I had talked to the author of the site and the reasons for not having D were not consistent with having Go on there. And I do believe someone did have communication with the Shootout maintainer and the reason given was "too similar to C" which is also not consistent considering the choices of languages which it does include. So I think it is safe to ponder on whether a bias is playing a role in these decisions.
Dec 11 2009
prev sibling parent Isaac Gouy <igouy2 yahoo.com> writes:
Brad wrote:

 This community has a lot of bad habits.  The particularly dangerous one
 demonstrated well in this thread is that of making assumptions about
 intent.  D isn't listed in the shootout, it once was.  We don't know the
 facts about why so we like to make the up.  Its human.  But it's really
 harmful.

+1
Dec 11 2009
prev sibling next sibling parent reply Isaac Gouy <igouy2 yahoo.com> writes:
bearophile:
 I think the notgentle person that manages the Shootout site has removed D
 because D programs were too much similar to the C programs.

I removed D because I started measuring on 4 different os/machine configurations instead of just 1 machine. https://alioth.debian.org/forum/forum.php?forum_id=2839 I also removed a whole bunch of other language implementations and that upset lots of other people.
Dec 11 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Isaac Gouy wrote:
 I removed D because I started measuring on 4 different os/machine
configurations
 instead of just 1 machine.
 
 https://alioth.debian.org/forum/forum.php?forum_id=2839

The link appears to be dead.
Dec 11 2009
next sibling parent reply Isaac Gouy <igouy2 yahoo.com> writes:
Walter Bright wrote:
 The link appears to be dead.

The link appears to work just fine from Mozilla Firefox.
Dec 11 2009
parent "Nick Sabalausky" <a a.a> writes:
"Isaac Gouy" <igouy2 yahoo.com> wrote in message 
news:hfurj4$1n9j$1 digitalmars.com...
 Walter Bright wrote:
 The link appears to be dead.

The link appears to work just fine from Mozilla Firefox.

I'm on firefox, and it's giving me some problem with the certificate.
Dec 11 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 https://alioth.debian.org/forum/forum.php?forum_id=2839

The link appears to be dead.

It's a little complex, you have to be logged in, or you have to accept some unsafe connections over a https. My suggestion is to ignore the whole thing and thread, you have better things to do. Bye, bearophile
Dec 11 2009
prev sibling parent reply merlin <merlin esilo.com> writes:
Isaac Gouy wrote:
 bearophile:
 I think the notgentle person that manages the Shootout site has removed D
 because D programs were too much similar to the C programs.

I removed D because I started measuring on 4 different os/machine configurations instead of just 1 machine. https://alioth.debian.org/forum/forum.php?forum_id=2839 I also removed a whole bunch of other language implementations and that upset lots of other people.

do you think that D2 would be worth including at some point in the future if we had some benchmark implementations showing off some of it's more functional nature? merlin
Dec 16 2009
parent reply Isaac Gouy <igouy2 yahoo.com> writes:
merlin wrote:
 do you think that D2 would be worth including at some point in the
 future if we had some benchmark implementations showing off some of it's
 more functional nature?

Last year I quadrupled what I have to do: by making measurements on 4 different cpu/os configurations - x86 x64 quad-core one-core. To reduce what I have to do: I asked - Can I think of reasons /not to include/ such and such a language implementation? Common sense tells me not to include more languages, curiosity and fun tell me to include just this one more - I'm trying /not to include/ more languages. There seems to be a D benchmarking project http://dbench.octarineparrot.com/ Couldn't that be more of a community project, extended, kept up to date, optimized for search engines, ...
Dec 17 2009
next sibling parent reply Isaac Gouy <igouy2 yahoo.com> writes:
retard wrote:
-snip-
 having the "unofficial" sources for languages not
 listed on the benchmark pages available in the shootout repository would
 help one in making his/hers own unofficial benchmarks

I'm probably misunderstanding your point, but... these days there are many places where you can have a source code repository for free, for example - http://code.google.com/p/support/wiki/GettingStarted
Dec 17 2009
parent reply Isaac Gouy <igouy2 yahoo.com> writes:
Thu, 17 Dec 2009 retard wrote

 My point was that the language shootout has a lot more publicity than
 some 3rd party mini benchmark site. Almost everyone knows the site.

That isn't accidental. Put the effort into making an interesting D benchmark site and making it well known.
Dec 26 2009
parent reply Isaac Gouy <igouy2 yahoo.com> writes:
retard Wrote:

 Sat, 26 Dec 2009 20:27:43 +0000, Isaac Gouy wrote:
 
 Thu, 17 Dec 2009 retard wrote
 
 My point was that the language shootout has a lot more publicity than
 some 3rd party mini benchmark site. Almost everyone knows the site.

That isn't accidental. Put the effort into making an interesting D benchmark site and making it well known.

I don't like benchmarks that advertise a single language. I think yours is just fine, but it could support the PL diversity a bit more. I know adding more language support and more testable features requires extra effort, but IMHO the test has become less and less useful now that all interesting languages suddenly disappeared. Another thing, probably all JVM language implementations benefit from - server switch or "steady state". But you only list those results for Java.

No, other JVM based implementations are run with -server.
 There's also gcj which produces native Java(/jvm language) 
 executables.

There's always another and another and another language implementation.
 GCC 4.3 is used although 4.4 is available.

No, 4.4 is used for the x86 Ubuntu measurements.
 It seems I'm using 4.4.2 and 
 have been using 4.4 for a long while - I even compile my kernel with it 
 despite all warnings. It would be interesting to know how much faster the 
 new one is. And how much faster the development version of 4.5 is. Same 
 thing with Java 7 / jvm languages - the early access version is already 
 out and has much better support for scalar replacement and other 
 optimizations than the currently tested version. I made a small test run 
 and Java 7 executed one of the tests in 50% less time compared to Java 6.

It seems like you want measurements for bleeding edge versions and a bunch of languages that are interesting to you - but you can't be bothered making those measurements yourself. Oh well.
Jan 10 2010
parent Isaac Gouy <igouy2 yahoo.com> writes:
2010/01/11 02:27 retard wrote:

 Sun, 10 Jan 2010 21:36:20 -0500, Isaac Gouy wrote:

 It seems like you want measurements for bleeding edge versions and a
 bunch of languages that are interesting to you - but you can't be
 bothered making those measurements yourself.


 I'm interested in the bleeding edge versions of all languages. It seems
 unfair that some languages (luajit, java steady state etc.) get more
 attention that some others.

It seems unfair that you want someone else to make the measurements that interest you.
Jan 17 2010
prev sibling parent Isaac Gouy <igouy2 yahoo.com> writes:
On Thu, Dec 17, 2009, Bill Baxter wrote
 If it were me, I'd drop everything but the 4-core x64.

It can be you - just make the measurements and publish them.
Dec 26 2009
prev sibling parent Isaac Gouy <igouy2 yahoo.com> writes:
Bill Baxter:
 And Go qualifies because it has some CSP implementation built in?

Go qualifies for the moment - it's an experiment - maybe it'll turn out not to be so interesting after all, and in golang.org forums they'll speculate about why it was removed from the benchmarks game...
Dec 11 2009
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Bill Baxter (wbaxter gmail.com)'s article
 Maybe it was lack of a 64-bit compiler?

Hint, hint, hint. I will be forever grateful to whoever makes it so I can use
4GB of RAM in D2.  (Ancient versions of D2 don't count.)  Then again, these

Dec 11 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Dec 11, 2009 at 1:17 PM, bearophile <bearophileHUGS lycos.com> wrote:
 Bill Baxter:
 D used to be there, but the folks running the shootout de-listed it
 for some reason.
 Maybe it was lack of a 64-bit compiler?

I think the notgentle person that manages the Shootout site has removed D because D programs were too much similar to the C programs. He is looking for very different code, not slight variations.

Hmm. And Go qualifies because it has some CSP implementation built in? Or is it more because it has a billion-dollar company built in? Kinda makes you wonder. --bb
Dec 11 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Dec 11, 2009 at 4:55 PM, Isaac Gouy <igouy2 yahoo.com> wrote:
 Bill Baxter:
 And Go qualifies because it has some CSP implementation built in?

Go qualifies for the moment - it's an experiment - maybe it'll turn out not to be so interesting after all, and in golang.org forums they'll speculate about why it was removed from the benchmarks game...

Cool. Thanks for popping in here to tell us that. --bb
Dec 11 2009
prev sibling next sibling parent Alexander Suhoverhov <cy ngs.ru> writes:
Jesse Phillips  at "Fri, 11 Dec 2009 18:43:30 -0500" wrote:
 JP> The comment I made, I had talked to the author of the site and the reasons
for not having D were not consistent with having Go on there.

 JP> And I do believe someone did have communication with the Shootout
maintainer and the reason given was "too similar to C" which is also not
consistent considering the choices of languages which it does include.

Is he trying to say that C++ is less similar to C than D?

 JP> So I think it is safe to ponder on whether a bias is playing a role in
these decisions.

-- 
Best regards, Alexander Suhoverhov
Dec 11 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Nick Sabalausky, el 12 de diciembre a las 00:10 me escribiste:
 "Isaac Gouy" <igouy2 yahoo.com> wrote in message 
 news:hfurj4$1n9j$1 digitalmars.com...
 Walter Bright wrote:
 The link appears to be dead.

The link appears to work just fine from Mozilla Firefox.

I'm on firefox, and it's giving me some problem with the certificate.

I think there is no problem with the certificate, it's just not signed by any certifiying authority. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Si le decía "Vamos al cine, rica" Me decía "Veamos una de Kusturica" Si le decía "Vamos a oler las flores" Me hablaba de Virginia Wolf y sus amores Me hizo mucho mal la cumbiera intelectual
Dec 12 2009
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Thu, 17 Dec 2009 16:51:42 +0000, Isaac Gouy wrote:

 merlin wrote:
 do you think that D2 would be worth including at some point in the
 future if we had some benchmark implementations showing off some of
 it's more functional nature?

Last year I quadrupled what I have to do: by making measurements on 4 different cpu/os configurations - x86 x64 quad-core one-core. To reduce what I have to do: I asked - Can I think of reasons /not to include/ such and such a language implementation? Common sense tells me not to include more languages, curiosity and fun tell me to include just this one more - I'm trying /not to include/ more languages. There seems to be a D benchmarking project http://dbench.octarineparrot.com/ Couldn't that be more of a community project, extended, kept up to date, optimized for search engines, ...

While I agree that measuring on the various configurations is a tedious and laboursome task, having the "unofficial" sources for languages not listed on the benchmark pages available in the shootout repository would help one in making his/hers own unofficial benchmarks. For example I often like to perform the JVM language benchmarks on various VMs and configurations so the default results have no value to me. I often convert code from some high level language to D, so having D in the tests would help in this regard, also.
Dec 17 2009
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Thu, 17 Dec 2009 19:37:19 +0000, Isaac Gouy wrote:

 retard wrote:
 -snip-
 having the "unofficial" sources for languages not listed on the
 benchmark pages available in the shootout repository would help one in
 making his/hers own unofficial benchmarks

I'm probably misunderstanding your point, but... these days there are many places where you can have a source code repository for free, for example - http://code.google.com/p/support/wiki/GettingStarted

My point was that the language shootout has a lot more publicity than some 3rd party mini benchmark site. Almost everyone knows the site.
Dec 17 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Thu, Dec 17, 2009 at 8:51 AM, Isaac Gouy <igouy2 yahoo.com> wrote:
 merlin wrote:
 do you think that D2 would be worth including at some point in the
 future if we had some benchmark implementations showing off some of it's
 more functional nature?

Last year I quadrupled what I have to do: by making measurements on 4 different cpu/os configurations - x86 x64 quad-core one-core.

For what it's worth, I think having more languages is more interesting than more machines. It's called "The Computer Language Benchmarks Game" and not the "Computer architectures Benchmarks Game", and comparing the benchmarks of different languages is why most people go there. The site doesn't even support making comparisons between benchmarks run on different architectures, so I doubt many people go there to make such comparisons. So to me, at least, there seems to be less value added by having more machines than value added by having more languages. If it were me, I'd drop everything but the 4-core x64. Going forward, both x86 and single core don't matter so much. It might still be interesting to have a single core result, but I see no reason to keep x86 around if the purpose is to benchmark languages and not machines. --bb
Dec 17 2009
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 26 Dec 2009 20:27:43 +0000, Isaac Gouy wrote:

 Thu, 17 Dec 2009 retard wrote
 
 My point was that the language shootout has a lot more publicity than
 some 3rd party mini benchmark site. Almost everyone knows the site.

That isn't accidental. Put the effort into making an interesting D benchmark site and making it well known.

I don't like benchmarks that advertise a single language. I think yours is just fine, but it could support the PL diversity a bit more. I know adding more language support and more testable features requires extra effort, but IMHO the test has become less and less useful now that all interesting languages suddenly disappeared. Another thing, probably all JVM language implementations benefit from - server switch or "steady state". But you only list those results for Java. There's also gcj which produces native Java(/jvm language) executables. GCC 4.3 is used although 4.4 is available. It seems I'm using 4.4.2 and have been using 4.4 for a long while - I even compile my kernel with it despite all warnings. It would be interesting to know how much faster the new one is. And how much faster the development version of 4.5 is. Same thing with Java 7 / jvm languages - the early access version is already out and has much better support for scalar replacement and other optimizations than the currently tested version. I made a small test run and Java 7 executed one of the tests in 50% less time compared to Java 6.
Dec 26 2009
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sun, 10 Jan 2010 21:36:20 -0500, Isaac Gouy wrote:

 
 It seems like you want measurements for bleeding edge versions and a
 bunch of languages that are interesting to you - but you can't be
 bothered making those measurements yourself.

I'm interested in the bleeding edge versions of all languages. It seems unfair that some languages (luajit, java steady state etc.) get more attention that some others.
Jan 10 2010
prev sibling parent retard <re tard.com.invalid> writes:
Sun, 17 Jan 2010 17:17:26 +0000, Isaac Gouy wrote:

 2010/01/11 02:27 retard wrote:
 
 Sun, 10 Jan 2010 21:36:20 -0500, Isaac Gouy wrote:

 It seems like you want measurements for bleeding edge versions and a
 bunch of languages that are interesting to you - but you can't be
 bothered making those measurements yourself.


 I'm interested in the bleeding edge versions of all languages. It seems
 unfair that some languages (luajit, java steady state etc.) get more
 attention that some others.

It seems unfair that you want someone else to make the measurements that interest you.

Just pointing out the facts. I've run the tests locally on my machine and wouldn't complain if the tests didn't do unjust to some implementations/ languages. It takes me lot of monetary effort to fix the damage the biased benchmarks do to some languages. Whatever, it seems talking to you is complete waste of time - you have your mission to ridicule the hard work of people who you personally don't like.
Jan 17 2010