Remember 32 bit code is 2x the size of 16 bit stuff.
On 2023-06-16 2:31 p.m., r.stricklin via cctalk wrote:
Are you, like, trying to play the list for laughs, with this kind of
comment?
On Fri, 16 Jun 2023, ben via cctalk wrote:
It is not? 3x's better.
All I know after x86 programs keep growing faster than MORE's law.
64 bit code is slightly larger than the same code for 32 bit, which
is slightly larger than the same code for 16 bit, which is slightly larger
than the same code for 8 bit.
But, it ISN'T the same code. The programmer is told to rewrite it, and
given twice as much space to put it in. That is what you see twice the
size.
Moore's law was about the doubling of transistors, and indirectly about
doubling of capacity and speed. After his death, are there any efforts to
repeal it, or at least not enforce it?
Boyle's law is that the software will expand to fill all available
memory and storage, and a little more.
MICROS~1 technique for dealing with performance problems is to throw
hardware at it. They are certainly not unique.
MICROS~1 technique for dealing with performance complaints is to blame
inadequacy of the user and their hardware. "You are running it on WHAT??
That hardware has been obsolete for MONTHS! I'm surprised that it would
even fit!"
On an 8 bit system, with 64K or less of RAM, a word processor would load
one or two pages at a time into RAM. If you scrolled, it would fetch
other pages as needed from disk. Document size was limited by disk
capacity.
With 640K of RAM,we got word processors that kept the entire document in
RAM, and abandoned the technique of paging in portions of the documant as
needed. Thus there was a smaller limit on document size.
I used to give some of my students an asssignment of writing a program to
sort a database that was too large to fit the whole thing in memory at
one time. A few insisted that the ONLY answer was to get more
memory.
So, each new "generation" is larger, but the software depends on that,
and won't even run on the previous generation of hardware.
--
Grumpy Ol' Fred [email protected]
