April 23, 2005
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'.
April 23, 2005
"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.


April 23, 2005
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&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


April 23, 2005
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

April 23, 2005
"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...

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.


April 23, 2005
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


April 23, 2005
"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


April 23, 2005
"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


April 24, 2005
"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


April 24, 2005
"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


1 2 3
Next ›   Last »