4 ms·

What should be noted, though, is that Rosetta code examples are usually not written for speed of execution, but instead in an educational manner and thus favor

by ygra 12y ago

What should be noted, though, is that Rosetta code examples are usually not written for speed of execution, but instead in an educational manner and thus favor clearer code over faster code. At least that's how I wrote my contributions and I feel fits the aim of the project better.

vanderZwan 12y ago
Isn't that kind of the point though? Highlighting the lanuage differences proper, instead of comparing benchmarks that are optimised with non-idiomatic code?
- lmm 12y ago
  Suppose language A offers only a very low-level way to express something, and language B offers the same thing but also a much more expressive (but less performant) way to express it. IMO it's misleading to say that language B is "slower" than language A.
  - derefr 12y ago
    Often, though, language B's low-level API won't be "language B" so much as it will be "another syntax for language A". At which point, it's often more idiomatic and simple to write in language A, than to write in language B's "version" of language A. (For just one example of this, inline assembler in C vs. actual assembler.)
- ygra 12y ago
  For code length maybe. But for performance I'd find that questionable. For most things you don't need all the performance you can get from the machine. If clicking a button spends 100 cycles too many, who cares? Performance is something where you investigate when you have a problem and then optimize the part that is problematic. Sure, if performance out of the box is inacceptable and cannot even be optimized, the language should probably not used at all. But for idiomatic code I'd find speed of execution a questionable benchmark, simply because you rarely find idiomatic code in performance-critical places. That holds for C as well as for Java. There are all sorts of rules that have to be followed to make code fast, such as no allocations in the hot path, etc. that don't usually hold for normal code.
  - lucozade 12y ago
    It's still interesting to have a feel as to the point at which you have to drop out of idiomatic code. Generally there is a complexity cost associated with performance tuning so there's value in avoiding it if possible. Whether or not that value trumps other factors e.g. convenience, expressivity will depend on your usage but I think it's a useful data point.
  - buster 12y ago
    Or, simply: If i have language X and language Y and the most straigforward and easy-to-read version of my program is 100x faster in language X and given that both languages have the same featureset, i'll chose language X and not language Y. Someone will always say "i can make it just as fast in language Y, i just need hideous tweaks and 10 times the LOC". But that's a moot point.
    - dllthomas 12y ago
      I think the interesting question is when there is a fast-and-complicated method available in both X and Y, and a slow-and-simple method available in only Y. Saying Y has to use the slow and simple method because that is "idiomatic" would be misleading, when you could be comparably fast with work comparable to doing it in X and that is the solution that would be used when performance matters. I don't know whether this is actually a situation borne out by reality or merely a hypothetical, though.

by ygra 12y ago

vanderZwan 12y ago

Isn't that kind of the point though? Highlighting the lanuage differences proper, instead of comparing benchmarks that are optimised with non-idiomatic code?

lmm 12y ago
Suppose language A offers only a very low-level way to express something, and language B offers the same thing but also a much more expressive (but less performant) way to express it. IMO it's misleading to say that language B is "slower" than language A.
- derefr 12y ago
  Often, though, language B's low-level API won't be "language B" so much as it will be "another syntax for language A". At which point, it's often more idiomatic and simple to write in language A, than to write in language B's "version" of language A. (For just one example of this, inline assembler in C vs. actual assembler.)
ygra 12y ago
For code length maybe. But for performance I'd find that questionable. For most things you don't need all the performance you can get from the machine. If clicking a button spends 100 cycles too many, who cares? Performance is something where you investigate when you have a problem and then optimize the part that is problematic. Sure, if performance out of the box is inacceptable and cannot even be optimized, the language should probably not used at all. But for idiomatic code I'd find speed of execution a questionable benchmark, simply because you rarely find idiomatic code in performance-critical places. That holds for C as well as for Java. There are all sorts of rules that have to be followed to make code fast, such as no allocations in the hot path, etc. that don't usually hold for normal code.
- lucozade 12y ago
  It's still interesting to have a feel as to the point at which you have to drop out of idiomatic code. Generally there is a complexity cost associated with performance tuning so there's value in avoiding it if possible. Whether or not that value trumps other factors e.g. convenience, expressivity will depend on your usage but I think it's a useful data point.
- buster 12y ago
  Or, simply: If i have language X and language Y and the most straigforward and easy-to-read version of my program is 100x faster in language X and given that both languages have the same featureset, i'll chose language X and not language Y. Someone will always say "i can make it just as fast in language Y, i just need hideous tweaks and 10 times the LOC". But that's a moot point.
  - dllthomas 12y ago
    I think the interesting question is when there is a fast-and-complicated method available in both X and Y, and a slow-and-simple method available in only Y. Saying Y has to use the slow and simple method because that is "idiomatic" would be misleading, when you could be comparably fast with work comparable to doing it in X and that is the solution that would be used when performance matters. I don't know whether this is actually a situation borne out by reality or merely a hypothetical, though.