5 ms·
My point was that the first optimizing compiler isn't comparable with what is expected of a modern compiler, so please don't compare their code & memory footpri
by oelang 12y ago
My point was that the first optimizing compiler isn't comparable with what is expected of a modern compiler, so please don't compare their code & memory footprint. With the first fortran compiler it was garbage in, garbage out. A modern compiler can (often) turn garbage into fast code.
Nowadays inside a compiler it's 90% graph processing & reprocessing. Since you're dealing with (cyclic) graphs, garbage collection is very useful and if you don't use some automated gc, you'll probably roll you own in one way or anther.
And a X86 interpreter isn't comparable with a compiler either. I doubt that there was any GC going on in your example, everything probably runs in a single array that represents the memory. Maybe some temporary objects but JS engines have good generational GC these days, I don't think D uses a generational GC algorithm.
- tachyonbeam 12y agoExactly. Someone told me I should "avoid using the GC completely". I answered that this was basically a way of saying that I should implement my own application specific GC. It's shifting the burden onto the application developer. What I'm saying is that the D GC could probably be several times faster. That much should be obvious.
- deleted 12y ago[deleted]
- acqq 12y agoJust use structs, unions and arrays of them: http://dlang.org/struct.html http://dlang.org/struct.html http://dlang.org/arrays.html http://dlang.org/arrays.html Preallocate them and don't increase their size one at the time. And in them use indexes to positions instead of pointers. Then GC won't make you problems anymore. It would be used but it won't be a bottleneck as it would simply get much less but bigger chunks of memory and much less pointers to worry about.