3 ms·

It should crunch doubles in a way typical to what a real-world program would. I'm fine with a ray tracer or something like that. The point is I don't care abou

It should crunch doubles in a way typical to what a real-world program would. I'm fine with a ray tracer or something like that. The point is I don't care about the performance of recursion for its own sake in a context for which there is no serious use. You might, but then you are disconnected from reality, as I said. That isn't an insult, it's just true from the definition.

chc 16y ago
The point is that the performance of recursion is not very context-dependent, and more complex contexts are less capable of accurately measuring the performance of any single operation — you don't know what elements of the function are slow or fast unless you measure them in relative isolation. Like, OK, so it runs that function fast — that tells me nothing about how any other function will perform, because you haven't determined what's fast and slow. Doing "benchmarks" with huge functions that do a lot of unrelated things is like "unit testing" a program by running it and seeing if it crashes. It tells you something, but that something is pretty vague.
- WilliamLP 16y ago
  Why would the performance of recursion not be very context-dependent? I would expect it to be extremely context dependent depending on how much memory is being put on the stack, cache hits and misses, and so forth. I can easily imagine optimizing performance for an unrealistic micro-benchmark that would actually hurt overall recursion performance. If there are any famous last words in optimization it's that something isn't very context-dependent, no?
  - jules 16y ago
    Of course it is not perfect, but it is one of the best ways to get a quick idea of the speed of a language. For example if we do it in OCaml we get native machine integers and cheap function calls. If we do it in Ruby we get expensive integers and heavy weight procedure calls. > I can easily imagine optimizing performance for an unrealistic micro-benchmark that would actually hurt overall recursion performance. I can't. Can you explain this and give an example?
  - deleted 16y ago
    [deleted]

chc 16y ago

The point is that the performance of recursion is not very context-dependent, and more complex contexts are less capable of accurately measuring the performance of any single operation — you don't know what elements of the function are slow or fast unless you measure them in relative isolation. Like, OK, so it runs that function fast — that tells me nothing about how any other function will perform, because you haven't determined what's fast and slow. Doing "benchmarks" with huge functions that do a lot of unrelated things is like "unit testing" a program by running it and seeing if it crashes. It tells you something, but that something is pretty vague.

WilliamLP 16y ago
Why would the performance of recursion not be very context-dependent? I would expect it to be extremely context dependent depending on how much memory is being put on the stack, cache hits and misses, and so forth. I can easily imagine optimizing performance for an unrealistic micro-benchmark that would actually hurt overall recursion performance. If there are any famous last words in optimization it's that something isn't very context-dependent, no?
- jules 16y ago
  Of course it is not perfect, but it is one of the best ways to get a quick idea of the speed of a language. For example if we do it in OCaml we get native machine integers and cheap function calls. If we do it in Ruby we get expensive integers and heavy weight procedure calls. > I can easily imagine optimizing performance for an unrealistic micro-benchmark that would actually hurt overall recursion performance. I can't. Can you explain this and give an example?
- deleted 16y ago
  [deleted]