On 2024-04-21, Lawrence D'Oliveiro <
ldo@nz.invalid> trolled again:
Rule 1 of power-cycling hardware: watch out for residuals. It takes
time for residual charge to drain out of the circuitry when you turn
it off. If you switch it on too quickly, the circuits are liable to
get into an inconsistent state.
This is because of power filtering capacitors, which are the largest.
When you cut power to a device, it doesn't instantly lose power. Its
internal voltage begins to drop, as the filter caps drain.
If you restore power too quickly, the device may effectively experience
only a brownout; not enough of a drop to initiate a reset.
(There is also a risk that some designs have a badly designed brownout
circuit: that the voltage at which they become unreliable yet above the
voltage that initiates a reset. But let's assume sane design.)
For simpler circuitry, count five seconds after switching off before switching on again. More complex components might take longer.
No, complexity doesn't extend this period. What extends the period
is having larger capacitors in relation to the current drain.
Complexity, however, means that there can be subsystems in the
machine which tolerate brownouts of different durations.
If you quickly toggle the power, some components in the system may reset themselves while others recover from the brownout. If you want
everything reset, you have to wait for the slowest component.
Pure garbage collectors will easily consume all of RAM if you let
them.
Yes, garbage collection could easily consume all of RAM, even though the
actual application needs only a fixed, much smaller amount of RAM.
"If you let it" is the key operative phrase.
Well, if it hurts, don't do that?
Garbage collection can easily confine itself to carving out small heaps
of memory at a time, and only claim an additional heaps form the
underlying host system only when certain conditions occur, like when a
full GC cycle is not able to recover more memory than a certain fraction
of a heap.
In other words, dynamically scale the footprint to the application.
Additionally, production garbage collectors have tunable GC parameters.
Reference-counting is a well-known technique for keeping RAM
usage within reasonable bounds in many common scenarios.
No, reference counting is not primarily technique for minimizing RAM
usage. It is primarily a technique for timely reclamation, ensuring that objects are finalized and reclaimed as soon as they are not required.
Storage reclaimed by reference counting is not always returned to the
system. Reference counting still has unused memory claimed by
application heaps, that is not available to other applications.
It also doesn't eliminate fragmentation.
All we can say is that, under no imaginable circumstances, would
reference counting (in a correct program that has no "semantic leaks")
consume, say, a gigabyte of RAM, while the program only needs a peak
usage of hundreds of kilobytes. Whereas, garbage collection could be configured such that such a thing happens.
So ... bleepity-do ... what?
scheme is a combination of both. Languages like Perl and Python are
exemplars of this. Maybe the Lisps could learn from them?
In the Lisp culture, memory management has been beat up from more angles
than anywhere else.
You're not proposing that no Lisp in existence has ever used reference
counting for anything, even objects that don't have pointers to
other objects that could get into a cycle.
But you're welcome to pitch in your contribution if you think you're
smarter than everyone else.
At that moment, Sussman was enlightened.
Commentary:
I wonder if either of them had heard of genetic algorithms?
Yeah, Sussman and Perl are waiting for none other than you to pull their ignorant heads out of their asses! Maybe while you are at it, you can
get them to study Perl and Python, so they can fix Lisp.
--
TXR Programming Language:
http://nongnu.org/txr
Cygnal: Cygwin Native Application Library:
http://kylheku.com/cygnal
Mastodon: @
Kazinator@mstdn.ca
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)