undefined | Better HN

story

0 pointsnostrademons9y ago0 comments

I think the idea behind real-world software performance is that "if you need it, you really need to have it, but most of the time you don't need it." The benchmarks game isn't all that unrealistic for this. Most of the time, you won't care about performance at all. When you do care about performance, you'll be able to devote an experienced engineer to carefully optimize a specific hot spot, not unlike a microbenchmark. It matters how fast you can get the code to go when it's a hot spot, not how fast all your little support code runs.

My one complaint is that there's no benchmark that measures FFI performance. Realistically, if you build a system in Python or Ruby - you're going to be dropping down to C for your hot spots. And so scripting language performance on all these compute-intensive tasks is somewhat irrelevant, you really want to know how much overhead you'll incur crossing the scripting/C boundary (which, in my experience can sometimes be large enough that it wipes out all the gains of coding in C in the first place).

0 comments

igouy9y ago

> measures FFI performance

Many of the pi-digits programs use GMP.

https://benchmarksgame.alioth.debian.org/u64q/performance.ph...

rbehrends9y ago

I have some experience with codegolfing for speed and in my experience, these benchmarks do not reflect the reality of such problems, either. If you really want to tweak code for speed, you'll use a mix of algorithmic improvements (that's where the biggest gains are) tailored to your language and compiler/hardware, possibly using FFI/assembly if you absolutely need it. But the benchmark game explicitly disallows algorithmic improvements, for example. Except through the backdoor, where language implementors can sometimes tweak libraries to circumvent restrictions.

And to make things more complicated, the performance increase is generally a function of the time spent on optimizing the problem, which is dependent not only on any innate speed, but also the expressiveness of the language and the programmer's familiarity with the language. Given that you don't have infinite time, there are further tradeoffs here.

igouy9y ago

> Except through the backdoor, where language implementors can sometimes tweak libraries to circumvent restrictions.

Which programming language implementations are doing that to your knowledge?

"… Kernels … Toy programs … Synthetic benchmarks … discredited today, usually because the compiler writer and architect can conspire to make the computer appear faster on these stand-in programs than on real applications."

http://benchmarksgame.alioth.debian.org/why-measure-toy-benc...

rbehrends9y ago

> Which programming language implementations are doing that to your knowledge?

My point here is not that this is being done (I'm generally assuming that language implementors have better things to do than to pollute their standard libraries for a benchmark game); I was making a different point, namely the inability to do algorithmic improvement, and mentioned that possibility for the sake of completeness.

igouy9y ago

There's been a good deal of play, flex and slop in the interpretation of "use the same algorithm" for some of those tasks.

I think your point is more that "Don't optimize away the work." is antithetical to what we do.

1 more reply

j / k navigate · click thread line to collapse

0 comments

igouy9y ago

> measures FFI performance

Many of the pi-digits programs use GMP.

https://benchmarksgame.alioth.debian.org/u64q/performance.ph...

rbehrends9y ago

igouy9y ago

> Except through the backdoor, where language implementors can sometimes tweak libraries to circumvent restrictions.

Which programming language implementations are doing that to your knowledge?

http://benchmarksgame.alioth.debian.org/why-measure-toy-benc...

rbehrends9y ago

> Which programming language implementations are doing that to your knowledge?

igouy9y ago

There's been a good deal of play, flex and slop in the interpretation of "use the same algorithm" for some of those tasks.

I think your point is more that "Don't optimize away the work." is antithetical to what we do.

1 more reply

j / k navigate · click thread line to collapse