www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Analysis of programming languages on Rosetta

reply "Cliff" <cliff.s.hudson gmail.com> writes:
The study doesn't analyze D, but the relationships between
languages may be interesting and in some cases surprising.

http://se.inf.ethz.ch/people/nanz/research/rosettacode.html

NOTE: The link contains only a summary, there is a pointer to the
full paper there however.
Sep 24 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Wednesday, 24 September 2014 at 17:37:27 UTC, Cliff wrote:

 The study doesn't analyze D, but the relationships between
 languages may be interesting and in some cases surprising.

 http://se.inf.ethz.ch/people/nanz/research/rosettacode.html

 NOTE: The link contains only a summary, there is a pointer to 
 the
 full paper there however.


I wonder why they found Haskell to be so slow, I thought it was 
compiled.
Sep 24 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Joakim:


 I wonder why they found Haskell to be so slow, I thought it was 
 compiled.


The first reason for the performance of programs is how much care 
the programmer has to write a fast program, secondly how good the 
chosen algorithms are, and only then at a third place there are 
language implementations.

So the short answer to your question is that most of the Haskell 
programs of Rosettacode are not written for performance. The 
corollary is that performance comparison is silly/bogus.

Often the faster programs of Rosettacode are in... guess a 
language? Yes, in D. Because I have written also performance 
conscious D entries (sometimes I have added various D solutions, 
at various levels of performance, succinctness, safety & 
correctness).

Bye,
bearophile
Sep 24 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 12:38 PM, bearophile wrote:

 Joakim:


 I wonder why they found Haskell to be so slow, I thought it was compiled.


 The first reason for the performance of programs is how much care the
 programmer has to write a fast program, secondly how good the chosen
 algorithms are, and only then at a third place there are language
 implementations.

 So the short answer to your question is that most of the Haskell
 programs of Rosettacode are not written for performance. The corollary
 is that performance comparison is silly/bogus.

 Often the faster programs of Rosettacode are in... guess a language?
 Yes, in D. Because I have written also performance conscious D entries
 (sometimes I have added various D solutions, at various levels of
 performance, succinctness, safety & correctness).


I wonder why D appeared only scarcely in this paper. -- Andrei
Sep 24 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 I wonder why D appeared only scarcely in this paper. -- Andrei


Near the start of the paper they explain their relatively complex 
strategy to choose languages to study. The D didn't come among 
the chosen ones by that strategy.

I don't care of having them include D because it's a not so 
interesting study, it's partially bogus because it partially 
relies on "fantasy data" (Tiobe site used in a supposedly 
scientific paper, really?), and uses ideas about code that are 
partially wrong (like the performance of Haskell programs shows).

See also:
https://news.ycombinator.com/item?id=8363666

Bye,
bearophile
Sep 24 2014
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Wednesday, 24 September 2014 at 19:38:37 UTC, bearophile wrote:

 Joakim:


 I wonder why they found Haskell to be so slow, I thought it 
 was compiled.


 The first reason for the performance of programs is how much 
 care the programmer has to write a fast program, secondly how 
 good the chosen algorithms are, and only then at a third place 
 there are language implementations.


So Haskell programmers don't care about fast programs and don't 
know how to choose good algorithms? ;)


 So the short answer to your question is that most of the 
 Haskell programs of Rosettacode are not written for 
 performance. The corollary is that performance comparison is 
 silly/bogus.


I understand that Rosettacode is not geared towards performance, 
but that's why it makes a good sample for the authors of 
idiomatic code in each language, albeit potentially skewed by the 
skill of the volunteers contributing.  What's interesting is that 
the performance results for most of the other languages are about 
what I'd expect, except for Haskell.


 Often the faster programs of Rosettacode are in... guess a 
 language? Yes, in D. Because I have written also performance 
 conscious D entries (sometimes I have added various D 
 solutions, at various levels of performance, succinctness, 
 safety & correctness).


Yes, I've seen your samples and different versions on that site 
before.  Good to see you put so much time into publicizing D, but 
I wonder how well-known that site is, as I never heard of it till 
you mentioned your involvement with it here.
Sep 24 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Joakim:


 So Haskell programmers don't care about fast programs and don't 
 know how to choose good algorithms? ;)


Haskell programmers that write the Rosettacode entries usually 
care for code succinctness and code simplicity more than they 
care for performance (and I think they are often right). Often 
the best algorithms requires longer programs.

You can see it very well here:
http://rosettacode.org/wiki/Iterated_digits_squaring



 I understand that Rosettacode is not geared towards 
 performance, but that's why it makes a good sample for the 
 authors of idiomatic code in each language,


Look at the four D entries I have written for that 
Iterated_digits_squaring task. I think all the first three 
entries are idiomatic, but their run-time varies wildly. Saying 
"idiomatic code" is not enough. You can write a very idiomatic 
Haskell entry that's much faster than the basic currently present.



 albeit potentially skewed by the skill of the volunteers 
 contributing.  What's interesting is that the performance 
 results for most of the other languages are about what I'd 
 expect, except for Haskell.


See the answer on Stackoverflow from the maintainer of the 
Computer Game site. You see there are other strange results in 
that study.



 Good to see you put so much time into publicizing D,


The Rosetta code site is far more important/interesting than just 
publicizing languages. And I have written entries in several 
other languages too.



 but I wonder how well-known that site is,


It's sufficiently known, but perhaps only for certain 
programmers. The ones that care about the design of programming 
languages are more likely to know it.

Bye,
bearophile
Sep 24 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Wednesday, 24 September 2014 at 21:54:12 UTC, bearophile wrote:

 Joakim:


 So Haskell programmers don't care about fast programs and 
 don't know how to choose good algorithms? ;)


 Haskell programmers that write the Rosettacode entries usually 
 care for code succinctness and code simplicity more than they 
 care for performance (and I think they are often right). Often 
 the best algorithms requires longer programs.

 You can see it very well here:
 http://rosettacode.org/wiki/Iterated_digits_squaring


Ouch, your worst idiomatic yet simple D version took 10 seconds, 
whereas the Haskell version took "less than eight minutes."  Of 
course, that's meaningless if they were run on CPUs that varied a 
lot in ability, but am I right in guessing that you wrote the 
Haskell version too?

If so, I do think it means something that the simple version for 
D was so much faster, but depending on the possibly easy 
optimizations missed by the Haskell implementor, maybe not much.


 I understand that Rosettacode is not geared towards 
 performance, but that's why it makes a good sample for the 
 authors of idiomatic code in each language,


 Look at the four D entries I have written for that 
 Iterated_digits_squaring task. I think all the first three 
 entries are idiomatic, but their run-time varies wildly. Saying 
 "idiomatic code" is not enough. You can write a very idiomatic 
 Haskell entry that's much faster than the basic currently 
 present.


Yes, the skill of the contributors and amount of time spent 
matters a lot, no doubt.  I will note that none of the D runtimes 
goes up to 8 mins, even the translated Haskell version, but maybe 
you're just that much better than that volunteer. ;)


 Good to see you put so much time into publicizing D,


 The Rosetta code site is far more important/interesting than 
 just publicizing languages. And I have written entries in 
 several other languages too.


Yeah, it's great for all coders to explore different ways of 
implementing the same concepts and see lots of sample code 
generally.  Too bad most aren't that interested in the former, 
but that's understandably a small group.


 but I wonder how well-known that site is,


 It's sufficiently known, but perhaps only for certain 
 programmers. The ones that care about the design of programming 
 languages are more likely to know it.


Yeah, that doesn't include me.
Sep 24 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Joakim:


 Of course, that's meaningless if they were run on CPUs that 
 varied a lot in ability,


The CPU is the same (mine) but the Haskell timings is imprecise 
and can't be relied upon (perhaps I have to recompute it).
(Rosettacode has a policy of not showing the run-time of 
programs. They are probably making an exception for me because of 
some reasons and because they are gentle with me, but I 
understand their reasons are also good.)



 but am I right in guessing that you wrote the Haskell version 
 too?


The Haskell entry was written by someone else, but later I have 
cleaned up it a little in several ways.



 If so, I do think it means something that the simple version 
 for D was so much faster, but depending on the possibly easy 
 optimizations missed by the Haskell implementor, maybe not much.


There are so many differences between the way Haskell manages 
lists and trunks lazily compared to how D manages ranges... very 
different tradeoffs on many different levels. The size of this 
newsgroup post is not enough to even list them :-)



 Yes, the skill of the contributors and amount of time spent 
 matters a lot, no doubt.


It's not just a matter of skill of the contributors and amount of 
time spent, it's also first of all a matter of how much 
semantically clean you want to write the code, how many 
abstractions you accept to remove from the implementation, how 
much you care for many factors more than performance, etc.

Bye,
bearophile
Sep 24 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 2:43 PM, Joakim wrote:

 On Wednesday, 24 September 2014 at 19:38:37 UTC, bearophile wrote:

 Joakim:


 I wonder why they found Haskell to be so slow, I thought it was
 compiled.


 The first reason for the performance of programs is how much care the
 programmer has to write a fast program, secondly how good the chosen
 algorithms are, and only then at a third place there are language
 implementations.


 So Haskell programmers don't care about fast programs and don't know how
 to choose good algorithms? ;)


Sadly that's only half of a joke.

Google for "Haskell tutorial", you'll get 
http://www.haskell.org/haskellwiki/Tutorials at the top. First "best 
place to start" leads to 
http://www.seas.upenn.edu/~cis194/lectures/01-intro.html. On that page, 
literally the first function defined is:

sumtorial :: Integer -> Integer
sumtorial 0 = 0
sumtorial n = n + sumtorial (n-1)

i.e. an linear-space way of doing summation. Just a bit below there's:

-- Compute the length of a list of Integers.
intListLength :: [Integer] -> Integer
intListLength []     = 0
intListLength (x:xs) = 1 + intListLength xs

i.e. an linear-space way of computing length. These are functions that 
are computationally bankrupt, we're not talking small constant fish here.

Well maybe that's not a very good tutorial. Let's move on to the second 
recommended reading, the famous "Learn You a Haskell for Great Good!" 
Sure that's going to be awesome. The first nontrivial function the 
tutorial ever defines from first principles at 
http://learnyouahaskell.com/syntax-in-functions#pattern-matching is...

factorial :: (Integral a) => a -> a
factorial 0 = 1
factorial n = n * factorial (n - 1)

... again, a gratuitously linear-space function.

Someone should do hard time for this.


Andrei
Sep 24 2014
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 09/24/2014 03:03 PM, Andrei Alexandrescu wrote:


 ... again, a gratuitously linear-space function.

 Someone should do hard time for this.


Fine! :p

I've just removed my recursive factorial example which did not add much 
value anyway:

   https://code.google.com/p/ddili/source/detail?r=766#

Ali
Sep 24 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/24/14, 3:46 PM, Ali Çehreli wrote:

 On 09/24/2014 03:03 PM, Andrei Alexandrescu wrote:

  > ... again, a gratuitously linear-space function.
  >
  > Someone should do hard time for this.

 Fine! :p

 I've just removed my recursive factorial example which did not add much
 value anyway:

    https://code.google.com/p/ddili/source/detail?r=766#

 Ali


You can always add the one that uses recursion with a local function. -- 
Andrei
Sep 24 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/25/2014 12:03 AM, Andrei Alexandrescu wrote:

 On 9/24/14, 2:43 PM, Joakim wrote:

 On Wednesday, 24 September 2014 at 19:38:37 UTC, bearophile wrote:

 Joakim:


 I wonder why they found Haskell to be so slow, I thought it was
 compiled.


 The first reason for the performance of programs is how much care the
 programmer has to write a fast program, secondly how good the chosen
 algorithms are, and only then at a third place there are language
 implementations.


 So Haskell programmers don't care about fast programs and don't know how
 to choose good algorithms? ;)


 Sadly that's only half of a joke.
 ...


Some (non-exhaustive!) basic evidence for the other half:

http://book.realworldhaskell.org/read/profiling-and-optimization.html
http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf


 Google for "Haskell tutorial", you'll get
 http://www.haskell.org/haskellwiki/Tutorials at the top. First "best
 place to start" leads to
 http://www.seas.upenn.edu/~cis194/lectures/01-intro.html. On that page,
 literally the first function defined is:

 sumtorial :: Integer -> Integer
 sumtorial 0 = 0
 sumtorial n = n + sumtorial (n-1)

 i.e. an linear-space way of doing summation.


sumtorial = foldl' (+) 0 . enumFromTo 0 :: Integer -> Integer

sumtorial n = n*(n+1) `div` 2 :: Integer

The next link, that wasn't considered, is 
http://book.realworldhaskell.org/read/types-and-functions.html which 
does a better job, by defining a function that is actually usable.


 Just a bit below there's:

 -- Compute the length of a list of Integers.
 intListLength :: [Integer] -> Integer
 intListLength []     = 0
 intListLength (x:xs) = 1 + intListLength xs

 i.e. an linear-space way of computing length. These are functions that
 are computationally bankrupt, we're not talking small constant fish here.
...


Note that GHC has a history of transforming certain O(1) space 
computations to Ω(N) space computations with certain optimizations 
enabled. The relative overhead will decrease in such cases. :o)

But the other direction is allowed. I.e. it is not actually a given that 
those examples will use linear space. (IIRC they will in practice.)


 Well maybe that's not a very good tutorial. Let's move on to the second
 recommended reading, the famous "Learn You a Haskell for Great Good!"
 Sure that's going to be awesome. The first nontrivial function the
 tutorial ever defines from first principles at
 http://learnyouahaskell.com/syntax-in-functions#pattern-matching is...

 factorial :: (Integral a) => a -> a
 factorial 0 = 1
 factorial n = n * factorial (n - 1)

 ... again, a gratuitously linear-space function.

 Someone should do hard time for this.
 ...


To be fair, a "real" factorial uses Ω(n log n) space anyway.
Sep 24 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Sep 2014 21:43:54 +0000
Joakim via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 So Haskell programmers don't care about fast programs and don't=20
 know how to choose good algorithms? ;)


;-) they care, but they also want to show how shiny haskell is. the
infamous "quick sort" sample comes to mind (which actually neither
quick, nor "quick sort" for that matter).


 Yes, I've seen your samples and different versions on that site=20
 before.  Good to see you put so much time into publicizing D, but=20
 I wonder how well-known that site is, as I never heard of it till=20
 you mentioned your involvement with it here.


it's relatively well-known and it pops high in google when searching
for "<algorithm-name> sample code" (at least for some algorithms).
Sep 24 2014