[Linux-aus] contest proposal

Tue Jan 2 10:18:56 AEDT 2024

Brendan,

I appreciate your comment, but let me add some real history about this:

[For those of you not interested in historical discussion of this, you can skip this section]

In the early 1990s DEC had the OSF/1 based release of OSF/1 Alpha.   In its initial release it needed 64 Megabytes of Main memory in order to boot and run.   This was declared to be too much main memory to be required on a SERVER CLASS machine.   Marketing wanted it reduced to 32 Megabytes.

Now you have to understand the underlying requirements of this.   First of all, most customers did not use DEC semiconductor memory, they used National Semiconductor or other RAM, but they needed to have the first 32 Mbytes of memory in order to allow the DEC service people to truthfully install and qualify an "All DEC" system.   If we required 64 Mbytes of DEC main memory to install and qualify it, it might have increased the cost of the "All DEC" system by thousands of dollars.

By reducing the amount of DEC main memory to "only" 32 MBytes, the customer could then buy the much cheaper National Semiconductor memory to fill out their system.

So the DEC engineers spent an entire YEAR squeezing libraries and the kernel, etc. down to the point where the system would boot and load in 32 MBytes.   But we did not anticipate the next thing.

[Here the people not interested in history can continue]

The DEC OSF/1 Alpha system reduced from 64 MBytes to 32 MBytes actually benchmarked as 7% FASTER than before all this work was done.

It was faster because more of the runtime set lived in the cache of the system and processor.   Reading the program text coming off disk was more compact, and took up less pages of the runtime set.   More of the instructions stayed in cache.   The DEC OSF/1 kernel did not page, so it had to stay in main memory.  But that did not mean it had to stay in the CACHE of that main memory or the processor.   And if the kernel HAD to stay in levels of main memory cache, that left less space for actively used programs, including the shell, the X-server, etc.

But it was not just the size of the code.   There was a lot of work done on "locality of reference", trying to get the next instructions on the same page of cache as the last ones.

Not every processor has a lot of cache.   Some have little or no cache, but they still do demand-paged virtual memory and compete with other processes for the space the system has.

I would also propose that we talk about "performance".   This contest so far about memory performance, but should also be about processor performance.   I hear the same talks about "why are we so interested in 'performance'" when processors are so fast (and memory is so cheap) I respond back that we care about performance because we do not want o charge our phones three times a day or that Google might only need 9000 servers instead of 10,000 servers or use "only" 900 megabytes of electricity instead of 1 Gigabyte of electricity (and less power needed for cooling).

Often I hear the reasons given for these inefficiencies because of "virtualization".  WRONG. Virtualization might actually help improve some of these issues, but it has to be virtualization done correctly, and we may have to make tradeoffs, but we should be doing these in a reasonable way.

Warmest regards,

maddog

> On 12/31/2023 11:18 PM EST Brendan Halley via linux-aus <linux-aus at lists.linux.org.au> wrote:
>  
>  
> Hi Russell,
>  
> I've seen the issue of memory bloat discussed many times by lots of people, all with different priorities. The consensus at the end of the conversation is always why waste part of someone's life fixing the problem when memory is so cheap.
>  
> Is your idea focused on the current state of affairs or more worried about scaling issues in years to come if RAM prices increase/there aren't as many technical developments in that area?
>  
> Just want to be clear, I think any optimisations to improve efficiency are good, just thinking from a realistic point of view.
>  
> Brendan
> 
> On Mon, Jan 1, 2024 at 12:46 PM Russell Coker via linux-aus <linux-aus at lists.linux.org.au mailto:linux-aus at lists.linux.org.au> wrote:
> 
> > We have an ongoing problem of system bloat.  Linux laptops with 8G of RAM
> > aren't doing much more than laptops with 96M of RAM did 25 years ago.  Yes we
> > have new features such as Bluetooth and integrated controls for pausing audio
> > etc but that sort of thing doesn't justify 80* more RAM.
> > 
> > I think that a way of alleviating this problem is to gamify it.  Make a
> > contest to find the best reduction of memory in commonly used FOSS programs
> > and give recognition at the next Everything Open conference.  Reduction can be
> > by optimising the source of a program, optimising configuration, or developing
> > a way of easily using alternative less memory hungry programs.
> > 
> > Give the best contestants small trophys (a quick Google suggests that's $20
> > including delivery) and everyone who does something noteworthy a mention on
> > the web site.
> > 
> > I think this would be easy to run, entertaining for delegates, and good for
> > the community.
> > 
> > What do you think?
> > 
> > 
> > PS I tried sending this directly to the council but hit an SPF problem.
> > 
> > --
> > My Main Blog         http://etbe.coker.com.au/
> > My Documents Blog    http://doc.coker.com.au/
> > 
> > 
> > 
> > _______________________________________________
> > linux-aus mailing list
> > linux-aus at lists.linux.org.au mailto:linux-aus at lists.linux.org.au
> > http://lists.linux.org.au/mailman/listinfo/linux-aus
> > 
> > To unsubscribe from this list, send a blank email to
> > linux-aus-unsubscribe at lists.linux.org.au mailto:linux-aus-unsubscribe at lists.linux.org.au
> > 
> _______________________________________________
> linux-aus mailing list
> linux-aus at lists.linux.org.au
> http://lists.linux.org.au/mailman/listinfo/linux-aus
> 
> To unsubscribe from this list, send a blank email to
> linux-aus-unsubscribe at lists.linux.org.au
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.org.au/pipermail/linux-aus/attachments/20240101/5ea8405e/attachment-0001.html>