3 ms·

I was never arguing in favour of reuse; I was arguing in favour of the C approach (keep everything in local variables and build a state machine.) And yes, conc

I was never arguing in favour of reuse; I was arguing in favour of the C approach (keep everything in local variables and build a state machine.) And yes, concurrent zeroing is nice. I don't dispute that: I just wanted to point out that the speedup you demonstrate above (partially) comes from using additional resources (CPU time on another processor), not from using existing resources more efficiently.

barrkel 16y ago
If the problem can be solved with a finite state machine, you'd be silly to allocate an amount proportional to the input size, for sure. I wasn't arguing against the C approach; when I write compilers, I implement lexical analyzers as state machines all the time. (In my day job, I write C most of the time.) And even when state is in object fields, I copy them out into local variables before doing work, and copy them back in to fields after work, because it's much easier for a compiler to enregister locals than fields. What I was actually arguing against is the idea that it's a good idea, in a GC environment, to avoid allocations when trying to improve performance. Allocations are extremely cheap in a GC environment; and automatic memory management by a precise copying collector is asymptotically faster than manual memory allocation on a per-item basis. (If you use pools or zones, you can get better manual memory management performance again, but then you lose allocation granularity.) It's not clear that the code I posted uses more resources. It uses some time from the other processor (i7 920 has 8 logical cores, CPU usage as Windows measures it never exceeds about 17%) but it also completes sooner. The collector also has opportunity to use more optimized zeroing strategies, whereas I coded the manual array zeroing with an explicit loop.
- JoachimSchipper 16y ago
  I think we are in violent agreement, although I think your GC benchmark is still "cheating". ;-)
  - barrkel 16y ago
    I fully agree - the point of using GC is that it cheats!

barrkel 16y ago

If the problem can be solved with a finite state machine, you'd be silly to allocate an amount proportional to the input size, for sure. I wasn't arguing against the C approach; when I write compilers, I implement lexical analyzers as state machines all the time. (In my day job, I write C most of the time.) And even when state is in object fields, I copy them out into local variables before doing work, and copy them back in to fields after work, because it's much easier for a compiler to enregister locals than fields. What I was actually arguing against is the idea that it's a good idea, in a GC environment, to avoid allocations when trying to improve performance. Allocations are extremely cheap in a GC environment; and automatic memory management by a precise copying collector is asymptotically faster than manual memory allocation on a per-item basis. (If you use pools or zones, you can get better manual memory management performance again, but then you lose allocation granularity.) It's not clear that the code I posted uses more resources. It uses some time from the other processor (i7 920 has 8 logical cores, CPU usage as Windows measures it never exceeds about 17%) but it also completes sooner. The collector also has opportunity to use more optimized zeroing strategies, whereas I coded the manual array zeroing with an explicit loop.

JoachimSchipper 16y ago
I think we are in violent agreement, although I think your GC benchmark is still "cheating". ;-)
- barrkel 16y ago
  I fully agree - the point of using GC is that it cheats!