4 ms·

I'm by no means an expert on the .Net platform, but are these equivalent? You generate ~20GB of garbage, about half of which could comfortably fit in your memor

I'm by no means an expert on the .Net platform, but are these equivalent? You generate ~20GB of garbage, about half of which could comfortably fit in your memory; more importantly, it appears that .Net, in some modes, does garbage collection in a different thread than the one running the program. And it's clear that using a different thread to zero memory is faster... Also note that I was talking about object creation, which may be a lot heavier than array creation.

barrkel 16y ago
The memory usage never climbs above 15MB - that's for the whole process, the .NET runtime, code, system DLLs, etc. all in. With object creation, reuse is far harder whereas with an array, you can just zero it out. In other words, the argument in favour of reuse is even weaker for objects than it is for arrays. I would say that if you have large arrays - large enough to go into .NET's large object heap, at about 70K - you're better off reusing those, because they only get collected during expensive gen2 collections, and they aren't compacted. As to the fact that the GC can zero memory on a different thread, that's not a problem - it's a benefit, as it's guaranteed correct concurrent zeroing, as opposed to the contortions you'd have to do to reuse. Again, an argument in favour of GC.
- JoachimSchipper 16y ago
  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

The memory usage never climbs above 15MB - that's for the whole process, the .NET runtime, code, system DLLs, etc. all in. With object creation, reuse is far harder whereas with an array, you can just zero it out. In other words, the argument in favour of reuse is even weaker for objects than it is for arrays. I would say that if you have large arrays - large enough to go into .NET's large object heap, at about 70K - you're better off reusing those, because they only get collected during expensive gen2 collections, and they aren't compacted. As to the fact that the GC can zero memory on a different thread, that's not a problem - it's a benefit, as it's guaranteed correct concurrent zeroing, as opposed to the contortions you'd have to do to reuse. Again, an argument in favour of GC.

JoachimSchipper 16y ago
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!