Mailinglist Archive: opensuse (686 mails)

< Previous Next >
Re: [opensuse] 64 bit vs 32 bit RAM consumption
Felix Miata said the following on 07/23/2013 08:05 AM:
In googling the possibility of using a 64 bit kernel on an otherwise 32 bit
openSUSE (consensus: don't try it), I found quite a bit of mention of 64 bit
apps using twice as much RAM? Is this true? Or is it just misunderstanding
arising from 64 bit using twice as many CPU registers to increase its own
speed? Or something else? My main system running 32 bit 11.4 has 4GB RAM and
is consistently using >50% of RAM for open apps, most of the rest for disk
cache, and always around 360MB unused. Would running 64 bit on this system be
consuming virtually all RAM for apps, leaving little free for disk cache?

We've - the larger community - have had this argument a couple of times before.

There were a lot of simple (as in not complex or bloated) applications for the Z-80 and its peers, 8-bit systems, that worked very well, thank you, up to an including some basic word processing applications. Oh, and a LOT of embedded systems. When 16-bit processors came along were they really needed? For speed? No! For additional functionality? Well, that's how they were sold.

We had this same pizzing match when Vaxen replaced PDP-11s as UNIX backbones. It was more justifiable then, but still, there was a lot of bloat.

The argument revolved around two things.
The first was 'constants' and counters.
Many initialization values were small numbers, zero and one being, thank you Poisson and in particular Benford's law
http://en.wikipedia.org/wiki/Benford%27s_law
so having bytes for these rather than 16-bit or now 32-bit integers made more sense.

The second was addressing.
This went hand in hand with address space.
An efficient compiler (and in the Z-80 days that might mean a human) could use relative branches, shorter code than absolute addresses.
larger address spaces tended to drag in a lot of non-tight coding because addresses were often resolved at link-time, the programs being bigger for various reasons (think of it as a version of Parkinson's Law -- code expands to fill the available space) and you don't know at compile time how 'far away' the destination of a call or jump will be.


Are these valid arguments? Well there are always counter arguments.
Its very hard to justify what amounts to 'parsimony' when the forces of market economics has moved on.

Yes, a 5MHz Z-80 may do the fob and chip yields of that will be fantastic and won't require the advanced technology (and cost) of what is being produced today. Not quite 'garage entrepreneur' but not far from it. Similarly low demands of memory, memory speed, circuit boards (think capacitors) and so on.

After all, if we strip out the creeping featureism, many embedded systems really don't need complex controllers. I think of the amazing things I did in the 1970s with Z-80s and even those rom-in-a-cpu from Intel,
https://en.wikipedia.org/wiki/Intel_MCS-48
and even http://www.cpu-world.com/CPUs/8035/
While, as https://en.wikipedia.org/wiki/Embedded_system points out, many embedded systems need to keep costs down (and that includes production costs and maintenance, so simple & reliable hardware counts) and so 'economy of scale' applies (and mature devices like the microelectronics from the 1970s figure), I've also done some larger, one-off applications, treating the core as a FORTH engine.

===================================

Well, that's what was, and still is, I suppose, the reasoning behind the reluctance to move to 16-bit, 32-bit and now 64-bit.

The arguments in favour amount to things like "more power", but lets face it, how often is the 'more power' actually eaten up by what amounts to 'eye candy'? I can see that server farms need 'more power', but that's as a much an argument for installing those neato-small IBM "mainframes' that run over 4,000 instances of SLES as it is for 64-but Intel slices.

Desktop? What, games? maybe you need a better graphics engine instead of a 64-but main CPU. Because, lets face it, the legacy of the Intel x86 architecture and its archaic instruction set (aka 'backward comparability') costs in terms of silicon real-estate, complexity and hence production cost to Intel/AMD and power costs to you. No wonder the ARM chips in phones and tablets can do so well and make batteries last for days!

======================================

Agree or disagree - this is most likely a religious war.

I keep saying "Context is Everything", and that's one reason I pointed to embedded systems and things that are too small/light to need an OS.

If you want 'eye candy', if you're a gamer, that's fine. I have no argument, but do recognise that there are other people with other needs.

--
The man who trades freedom for security does not deserve nor will he ever receive either
-- Benjamin Franklin
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
References