Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Does this have anything to do with ticket #60692? I just repeated a run of examples/benchmarks/primes2.pir with current parrot and what used to run in 8 seconds before commit 31668, took 220 after that and now takes 133 seconds. What's so unusual evil about this program?

    • Yes, it has something to do with it. I knew we'd need an MMD cache at some point, though I didn't plan it for further down the line. A bunch of changes done in that commit (actually a branch merge) resulted in opcode dispatch in many cases going through the standard multi-dispatcher, where before they just were done with a 2D lookup table (which gets unsustainable when you get lots of types). The changes means that at least multi subs and ops dispatch the same way, which is good, but there were some issues.

      One big one was that it was much slower to compute which thing to dispatch to with the Manhattan distance algorithm than just a couple of pointer dereferences. Since this could be aided with an MMD cache, and since we wanted one for Rakudo too, I implemented something generic that would work for both (and that we can also, after a further refactor, apply to PIR :multi subs too). This was responsible for much of the speedup you see from the worst point of 220s. Some further optimizations by chromatic got us a bit more.

      However, as you see, it remains, well, slow. Which sucks. It's one of those "be correct and then be fast" cases, though, and the changes do remove an inconsistency that was there before. I've looked at what we're doing with regard to marshaling args and stuff per call at the moment, and when I saw what was going on, it was hardly surprising it's slow. :-( Happily, however, there's plenty of room for optimization. So I expect we'll start to do better on this benchmark again in the future. How soon in the future depends on people working on speeding it up - I think chromatic may be experimenting with one of the ideas soon.