[HN Gopher] The prospects for 128 bit processors (1995)
___________________________________________________________________
The prospects for 128 bit processors (1995)
Author : luu
Score : 31 points
Date : 2022-02-23 21:04 UTC (1 hours ago)
(HTM) web link (yarchive.net)
(TXT) w3m dump (yarchive.net)
| PaulHoule wrote:
| They had 128-bit computing in the 1970s if you count this sort of
| thing
|
| https://en.wikipedia.org/wiki/IBM_AS/400
|
| which used 128-bit unique identifiers for objects that could be
| in RAM or kept persistently in storage which was transparently
| managed by the OS, language runtime, etc.
| guerrilla wrote:
| Some VAXen could also do 128-bit ALU operations too. I thought
| DEC had a full 128-bit CPU but I've never been able to find
| it... I probably just remember wrong.
| PaulHoule wrote:
| Of the various claims that something is X-bit I think the
| most credible is the size of the address space as opposed to
| the size of the ALU.
|
| A 128-bit address space is large enough (UUIDs) that you can
| name 2^64 objects (about as many iron atoms are as in an iron
| filing) randomly. That lets you take two separate systems and
| then merge them into one system with no name conflicts, a
| handy property for 'distributed systems'
| Someone wrote:
| FTA: _Thus, a CPU family intended to address higher-end systems
| will typically add 2 more bits of_ physical address* every 3
| years.*
|
| For me, that loosely follows from the "CPU speed doubles every 18
| months" variant on Moore's law. Having extra address space
| doesn't help you if your CPU is too slow to fill it (1), so if
| your CPU gets twice as fast in 18 months, the amount of memory
| you can effectively address doubles.
|
| That would only change if we had non-volatile RAM.
|
| (1) yes, you could have a hash table with effectively zero chance
| of collisions if you were to use petabytes to store a few hundred
| items, and that would be useful even with a 1MHz CPU, but if you
| can spend that money on memory, you're better of spending it on
| better CPU. So, that only would help if CPU evolution stopped and
| memory got drastically cheaper, both in $ and in power usage.
| AdamH12113 wrote:
| > For example, 36-bit physical addresses support 16GB memories
| ... and there already have been shipped single-rack
| microprocessor boxes with 16GB using just 16Mb DRAMs; there are
| of course, more in the 4GB-8GB range. Of course, a 32-bit
| physical addressing machine can get around this with extra
| external-mapping registers ... assuming one can ignore the
| moaning from the kernel programmers :-)
|
| I remember 16 megabytes of RAM being enough for a good gaming rig
| in 1995. Who was using gigabytes of RAM back then, and for what?
| monocasa wrote:
| A couple years later, but in 1997 you could get one of these
| with 64GB of RAM.
|
| https://en.wikipedia.org/wiki/Sun_Enterprise#Enterprise_1000...
| hnlmorg wrote:
| Most likely databases. Pretty sure one of the Sun SPARC boxes I
| managed in 1995 and that had a few GBs of RAM. It also ran
| Informix, which I don't miss administrating.
| hackcasual wrote:
| Databases. Early high traffic internet services
| colejohnson66 wrote:
| I'm other words: the same things that, today, are using a
| _terabyte_ of RAM. Cloud computing and databases.
| cesaref wrote:
| I was building and speccing servers to run banking applications
| in the mid to late 90s and this was in the days when x86 was
| still rubbish (or perceived to be so), so it was big Solaris
| boxes (E10k etc) and beefy HP PA-RISC machines.
|
| Applications were written in C++ and COBOL, the DB was Oracle.
|
| CPUs were expensive, disks were slow (and expensive - this is
| when EMC ruled!), so memory was used to boost database
| performance, and you could put a lot of memory in these
| machines (and we did). There were often 3 machines at each
| site, 2 production (one hot standby) and 1 test/qa machine,
| usually the same chassis but with lower specs (less CPU, less
| memory, less disk etc). The production machines were often at
| two close sites (10k apart) with disk replication between them
| over fibre in the street.
|
| It was quite common back then for the clients to specify
| ridiculous projected growth, and require total resilience from
| the hardware. I'd spec up the machines, and they'd baulk at the
| price (and when you get an international bank to baulk at the
| price you can imagine we're talking multiple millions for
| hardware let alone support contracts etc). Then, following a
| slice of realism, they'd relax some of the requirements, and
| we'd get something for 1/4 of the money.
|
| Happy days, lots of travel though.
| contingencies wrote:
| How did they secure the fiber? IIRC back then it was hard to
| get decent (especially non-backdoored) hardware encryption
| solutions @ high network throughput.
|
| I wonder if anyone spliced fiber, MITM'd disk replication,
| made bank and got away with it...
| CodeWriter23 wrote:
| > Of course, a 32-bit physical addressing machine can get around
| this with extra external-mapping registers
|
| When I came up in this industry, we referred to that as "Bank
| Switching"
| CalChris wrote:
| Even 64-bit systems today don't address 64-bits of physical
| memory. The Arm A78 uses 40 bits of physical address space. The
| 128 bits would really be for arithmetic and bus widths.
| EdSchouten wrote:
| Relatedly, I hope we ever get CPUs where pointers are bit
| addressed. I'm not suggesting they should allow byte level access
| at arbitrary alignments. I just mean that the smallest
| addressable unit is a bit.
|
| That would allow us to finally declare lists of booleans without
| needing any specialization or losing the possibility of
| referencing elements.
| esmIII wrote:
| Some ARM cortex-m chips have a feature where you can address
| individual bits.
| https://developer.arm.com/documentation/ddi0439/b/Programmer...
| flohofwoe wrote:
| This would also go nicely with arbitrary-width integers.
| Load/store instructions would just need to set aside a few
| opcode bits to define the number of bits to load or store, and
| pointers would just get 3 bits wider (basically left-shifted 3
| bits, the upper bits in a 64-bit pointer are not used anyway).
| Pointer alignment could be the same as the bit width, e.g.
| 2-bit load/store could require 2-bit alignment, byte load/store
| byte alignment, and so forth...
| dang wrote:
| One small thread from the past:
|
| _The prospects for 128 bit processors (1995)_ -
| https://news.ycombinator.com/item?id=6300063 - Aug 2013 (2
| comments)
| pella wrote:
| https://en.wikipedia.org/wiki/128-bit_computing
|
| _" The RISC-V ISA specification from 2016 includes a reservation
| for a 128-bit version of the architecture, but the details remain
| undefined intentionally, because there is yet so little practical
| experience with such large memory systems"_
| monocasa wrote:
| Fabrice Bellard's TinyEmu actually implements enough of the
| RV128 spec to run code. So the spec is defined well enough to
| implement, I just think they don't want to paint themselves
| into a corner before there's an actual need.
|
| I was going to link to his site, but it seems he needs to
| update his certs.
| don-code wrote:
| We've definitely found use cases for higher-width buses, but
| seemingly less so for operating on 128-bit integers and pointers,
| like this article is describing.
|
| Take for instance VLIW architectures (Itanium used 64-bit
| registers but 128-bit instructions; you packed two ops into an
| instruction), vector extensions (AVX-512 uses 512-bit registers
| to hold multiple integers from 16 to 64 bits long) - we've long
| known these to be viable strategies for long word lengths in a
| CPU. But the ability to operate on a 128-bit integer directly
| doesn't seem to have a use case yet.
| Dylan16807 wrote:
| > (Itanium used 64-bit registers but 128-bit instructions; you
| packed two ops into an instruction)
|
| Three ops.
| ajuc wrote:
| > Of course, if somebody does an operating system that uses
| 128-bit addressing to address every byte in the world uniquely,
| _and_ this takes over the world, it might be an impetus for
| 128-bitters :-)
|
| I'd like to see such OS.
| kloch wrote:
| You joke but I found this interesting (from
| https://en.wikipedia.org/wiki/Metal_oxide_semiconductor):
|
| > It is the basic building block of modern electronics, and the
| most frequently manufactured device in history, with an
| estimated total of 13 sextillion (1.3x10^22) MOSFETs
| manufactured between 1960 and 2018
|
| 64 bits can address 1.8x10^19 bytes. Of course there is not a
| 1:1 correlation between mosfets ever made and bytes of ram
| usable today but it's curiously close to the 64-bit limit so
| you could say 64 bits is just enough to address every byte in
| the world.
|
| I wonder how much magnetic storage would add to that?
| Dylan16807 wrote:
| > I wonder how much magnetic storage would add to that?
|
| A lot.
|
| Just looking at hard drives, if you take an estimate of 250
| million units made in 2020 and multiply by a conservative
| 4TB, you get 10^21 bytes for that single year.
| Animats wrote:
| Symbolics tried that.
|
| Scary thought: how many bytes of RAM are there in the world?
| Probably more than 2^64. There are around 7 billion
| smartphones, and many have over 4GB of memory. That's over 2^64
| right there.
|
| I'd like to have 128-bit atomic operations. If you're doing
| lock-free programming, hardware compare and swap on a structure
| that contains two pointers is useful. Then you can update lists
| atomically. In a 64-bit pointer machine, that takes 128 bit
| atomics. So far, not much hardware offers that.
| Dylan16807 wrote:
| CMPXCHG16B has been standard for the vast majority of the
| time x86_64 has existed. If a CPU can run windows 8.1, then
| it has 128-bit atomic operations.
| wantoncl wrote:
| There _might_ be a bit of a problem powering it:
|
| https://hbfs.wordpress.com/2009/02/10/to-boil-the-oceans/
| Dylan16807 wrote:
| So a few notes on that:
|
| * That's the threshold where you go from 128 to 256, not
| where you go from 64 to 128.
|
| * If you're not going for the physically maximum overclock,
| the energy per bit is a lot less.
|
| * That's for storing 512 byte blocks, so you'll run out of
| RAM bits 512 times sooner.
|
| * Humans use about 10^20 joules of electricity per year.
|
| * 10^20 joules at the cost in the link would be about 2^110
| bytes, which is not all that far off.
| reincarnate0x14 wrote:
| I'd be curious if anyone with understanding of memory transistor
| density has an idea of what sort of physical footprint and power
| requirements 128-bit addressable memory would look like, because
| I'm having a hard time picturing even a distributed, shared
| virtual memory space realistically exceeding 16 exabytes.
|
| It looks like the Fugaku ARM cluster with 158,000 nodes uses < 5
| PiB for 40 MW.
|
| As an aside, man does reading something from @sgi.com on USENET
| take me back to a better time. Title should probably note [1995]
|
| [0]
| https://www.fujitsu.com/global/about/innovation/fugaku/speci...
|
| [1] Also https://arxiv.org/abs/quant-ph/9908043 "Ultimate
| physical limits to computation"
| Laremere wrote:
| 85.8 grams of DNA is enough to overflow 64bits. Not that we're
| anywhere close to being able to use or process information on
| those scales, but it at least storage on that scale doesn't
| outright violate the laws of physics/information theory.
| littlestymaar wrote:
| Storage needs don't affect pointer size though. To need
| bigger pointers, you must need an _addressable space_ this
| big.
|
| That said, how to you make your calculation about DNA's
| information density? Without counting water, I've arrived at
| 720g for one "mole of bits", which is a bunch of orders of
| magnitude higher than your figure: 2 amino-acids (262g/mole)
| [1], 2 Deoxyribose (135g/mole each) and 2 Phosphate (94g/mole
| each).
|
| [1]: and it's the same value be it A-T or G-C, that's
| interesting
| jandrewrogers wrote:
| It is not too difficult to imagine for virtual memory. Servers
| with high storage density are right up against the current
| virtual memory limits such that you can't mmap() storage as it
| is. Not that you'd _want_ to mmap() if you cared about
| performance. Similarly, the largest data models have been in
| the exabyte range for a while. It is just a matter of time
| before they are not byte-addressable using a 64-bit integer.
|
| I think there is more utility in 128-bit ALUs than 128-bit
| pointers, as a practical matter.
___________________________________________________________________
(page generated 2022-02-23 23:00 UTC)