Completing C code with D style
H. S. Teoh
hsteoh at quickfur.ath.cx
Thu Nov 11 00:11:07 UTC 2021
On Wed, Nov 10, 2021 at 11:39:40PM +0000, forkit via Digitalmars-d-learn wrote:
[...]
> I still remember compiling code on my 286x86 ... talk about low
> memory..whoaaah.
That's nothing! ;-)
When I was a kid, I programmed a computer that had only 48K of RAM
(that's 48 *kilo*bytes, not megabytes!). The address space was 64K
(16-bit), but beyond the 48K boundary was occupied by ROM which cannot
be modified.
> These days, I have a 4GB ramdisk, put all the dmd/phobos..etc source
> code into that, and everything is read/compiled completely in memory,
> in seconds. The slowest part is copying the compilation back to disk,
> but even that happens so fast I don't even see it happen.
In all likelihood, it isn't actually copying everything back to disk in
that instant, but rather sitting in the HD cache while the controller
slowly writes it to disk in the background. :-D (Well, before that, in
the OS cache.)
> Worrying about an extra allocation here or there seems kinds trivial
> over here ;-)
It depends on what you're doing. In the OP's example, yeah worrying
about allocations is totally blowing things out of proportions.
But if you're in a time-constrained inner loop, you do *not* want to be
allocating memory without a second thought, lest you provoke the ire of
the GC and get a stop-the-world pause in the wrong moment. E.g., when
your radiotherapy dosage controller is just about to shut off the
radiation beam, and the extra pause can mean death from overdose. :-P
Or y'know, the more important thing these days -- hundreds of your
gamers will complain about jerkiness or lower framerates in their
totally-important 60fps GPU-raytraced game. ;-)
Or, on a more serious note, if you're trying to solve a mathematically
hard problem, needless allocations can mean the difference between
getting the answer next week vs. the next century. Sometimes these
things *do* add up.
T
--
MSDOS = MicroSoft's Denial Of Service
More information about the Digitalmars-d-learn
mailing list