[HN Gopher] Arch: Remove Itanium (IA-64) architecture
___________________________________________________________________
Arch: Remove Itanium (IA-64) architecture
Author : ndesaulniers
Score : 49 points
Date : 2023-11-02 16:28 UTC (6 hours ago)
(HTM) web link (git.kernel.org)
(TXT) w3m dump (git.kernel.org)
| twoodfin wrote:
| Imagine HP & Intel execute on Itanium to perfection: Were they
| still doomed to failure, or is VLIW/EPIC actually a viable
| competitive approach for high-performance general purpose CPUs?
|
| The market evidence suggests it's not, but there haven't been
| that many well-funded, competent attempts (Itanium, Transmeta,
| ???) so the sample size is small.
| KMag wrote:
| Code density is an issue, requiring huge caches for Itanium to
| remain competitive. These large caches consume lots of die
| area, making the chips both expensive and power-hungry.
|
| As I and others have pointed out, instead of a constant 3
| instructions in 128 bits, a variable number of instructions in
| 64 bits should get you competitive code densities. (Say, have a
| 4-bit prefix that indicates if 1x60 bits, 2x30 bits, 4x15 bits,
| or 5x12 bits instructions are packed in the remaining 60 bits.
| For 12-bit instructions, you probably have the first
| instruction only able to store into r1 or r2, the second
| instruction only able to store into r3 or r4, etc. so that you
| have a 6-bit opcode, 1 bit for destination register and 5 bits
| for operand register. Plenty of old processors had an
| accumulator that was the implicit destination for most
| instructions.) Some of the other 4-bit prefixes would be used
| to indicate a combination of instruction widths and instruction
| parallelism to allow lower-powered in-order superscalar
| implementations.
|
| Fixed alignment of 64-bit bundles of variable-width
| instructions makes parallel instruction decoding cheaper (and
| makes static analysis easier/finding ROP exploit targets very
| slightly harder).
|
| Your high-performance cores are probably still going to have
| dynamic out-of-order scheduling in hardware. However, your
| power-efficient in-order cores might use parallelism data
| embedded in that 4-bit prefix.
|
| Ideally, the hardware would have reservoir sampling for which
| branches are mispredicted and which instructions stall the
| pipeline. This information could be aggregated for a background
| process to re-optimize the binary, similar to what the current
| Android Runtime does.
|
| Efficient hardware branch tracing (perhaps a second stack
| where, when the tracing machine state bit is set, the
| destination of each conditional/indirect branch target is
| pushed, along with an interrupt when the trace gets full) might
| allow for efficient runtime re-optimization of binaries,
| including inlining of dynamic library code into the code hot
| spots.
|
| On a side note, I know RSIC-V at least at one point had a
| proposal for an extension to use the integer registers for
| floating-point. Does anyone have a feel for how costly it would
| be for register renaming logic to handle separate integer and
| floating point register files so that low-power implementations
| could use a single unified register file (perhaps without
| register renaming) and higher performance implementations
| (which would presumably have register renaming anyway) could
| use separate integer and floating-point register files?
|
| In general, I hope we can find ISA designs that leave room for
| both very-low power implementations that can push some of the
| work into software, and high-performance implementations that
| aren't hindered by the features that allow lower-power/simpler
| implementations.
| dragontamer wrote:
| Xilinx Versal AI cores suggest that VLIW + SIMD is a winner.
|
| Speaking of which: so was AMD Terrascale:
| https://en.wikipedia.org/wiki/TeraScale_(microarchitecture)
|
| -----------
|
| It just needs to be in the right situation. GPUs almost
| entirely compute inside of register space, while FPGAs have
| carefully laid out memory exactly perfectly for their compute,
| so once again VLIW can fly.
|
| SIMD is an important technique to scale vs GPUs, because...
| well... SIMD is basically free scaling so might as well get it.
|
| So that's the combo IMO. Remove the random memory delays
| associated with general purpose compute, have a crap-ton of
| register space to never touch memory under normal
| circumstances, have huge kernels for DSP / GPU like tasks, and
| let the machine fly.
|
| ----------
|
| I think it so happens that SIMD-parallelism was easier than
| expected, while VLIW-parallelism is harder than expected. So
| SIMD takes priority, but both should happen in these use cases.
| If you consider that the 2000s period of AMD64 vs IA-64 going
| on, the AMD systems focused on SSE / SIMD parallelism to
| provide us with the high-performance multimedia DivX decoders
| and whatnot (and other multimedia problems that consumers
| needed SIMD compute for back in the day). That parallelism was
| enough to be competitive vs IA-64.
|
| "General purpose CPUs" are so RAM-latency limited in practice.
| So out-of-order machines that can find work while waiting for
| RAM (again: AMD64) get a benefit.
| touisteur wrote:
| Carefully waiting to see whether Versal actually ends up
| making money for Xilinx and whether they stabilize on
| something after the shotgun approach of the first Versal
| iteration.
| chasil wrote:
| The first iteration of Itanium, known as Merced, was truly
| awful, and this was Intel's fault.
|
| The second iteration, McKinley, was designed by HP and had more
| reasonable performance, but not enough to stop AMD64.
|
| A big problem was that a quality compiler was hard to find, and
| without it everything just ran very slowly.
| jcranmer wrote:
| VLIW is one of those things that looks good on paper but just
| doesn't work that well in practice, and there's two main
| reasons for this.
|
| The first issue is the static versus dynamic scheduling
| problem. Static scheduling first requires a sufficiently smart
| compiler to output the correct static schedule. But you're also
| limited in your ability to parallelize based on what you can
| divine statically. Some operations have fundamentally dynamic
| execution times (memory operations, branches, and division
| operations are the most common of these), and if you guess
| wrong as to how long they're going to take, you're going to
| force the computer to do nothing where a dynamic scheduler
| could have slotted other work in instead
|
| Additionally, you can only schedule work to be done in parallel
| within a relatively small scope, largely a basic block, and
| definitely on function boundaries. Functions like sin and cos
| boil down to polynomial evaluation, a chain of ~5 FMAs that
| have to be executed sequentially. Even if you have two FMA
| execution units, a static scheduler is forced to execute sin(x)
| * cos(y) serially, whereas a dynamic scheduler can usually get
| some overlap between the FMA chains.
|
| A sufficiently smart compiler that can create the optimal
| static schedule for a VLIW chip can also emit the code so that
| the superscalar chip will dynamically choose the optimal
| schedule, so a VLIW chip ends up getting no better throughput
| than a regular superscalar chip, and if the stars align less
| well, will likely get worse throughput.
|
| The other fundamental issue with VLIW is that it forces you to
| expose more of your microarchitectural details at the ISA
| level, which makes it harder to adjust those details (e.g., add
| more execution units) should you desire to in later chip
| iterations. Now Itanium does have a design which ameliorates
| this to a degree, but the cost of such a design is largely
| bringing back the transistor- and power-hungry aspects of the
| superscalar chip into your VLIW design, at which point you
| start asking how much you're really saving.
| pjmlp wrote:
| I am convinced they only failed because AMD was allowed to come
| up with AMD64.
|
| Had it not been for them, Intel and HP would have managed to
| push Itanium no matter what.
| sneed_chucker wrote:
| From the thread:
|
| > I'm a little bias because my company is a re-sellers of the HP
| Itanium ia64 hardware (RX & ZX boxes), as well as PA-RISC. For
| that reason, I would hate to see it fade away in any sector. The
| ia64 platform is still widely used with HP-UX Unix and Open VMS
| users worldwide. This hardware is embedded in most every data
| center and large and medium companies that have been around since
| the 80s/90s, its probably the oldest box they have in there but
| its the one thats in the corner running for 20 years, long before
| most people started working there.
|
| Can anyone speak to how true this is? Are there still a bunch of
| companies that run some critical service using machines/OSs like
| this? I have a morbid curiosity about "obsolete" tech still being
| in everyday use.
| ch_123 wrote:
| Yes, there are companies who are still using HP-UX and VMS in
| production on IA64. The current maintainers of VMS have created
| an x86 port so I would expect VMS sites will probably move over
| to it in the coming years. HP-UX is stuck on IA64, meaning that
| anyone using that platform has a more risky port to Linux if
| they want to move off IA64.
| chasil wrote:
| VMS has a reputation for clustering. At one point, [I heard
| that] Oracle bought clustering technology out of VMS that was
| used in making RAC (Real Application Cluster), and ditching
| Parallel Server.
|
| VMS for x86-64 has just emerged for production deployment in
| the past year. I don't know if it has the OS-level emulation of
| previous architectures (macro32 and vest, if I am correct in
| the VAX components, and their Alpha and Itanium equivalents),
| but the most modern VMS installations are on Itanium.
|
| Intel was a big user of VMS in the past, although I don't know
| if that remains true.
| sterlind wrote:
| VMS was indeed ahead of its time on clustering. iirc, Leslie
| Lamport actually discovered Paxos while he was at DEC. DEC
| was building a fault-tolerant, distributed filesystem, but
| their protocols were unsound, and Leslie set to work trying
| to prove that their design goals were impossible. instead, he
| found a mathematically sound way to do it (Paxos!)
|
| see https://lamport.azurewebsites.net/pubs/pubs.html
| dekhn wrote:
| I read the man pages for Real Application Cluster and they
| appeared to be lightly reformatted version of the man pages
| for TruCluster (I can't speak about VMS clustering, I only
| know Tru64's clustering).
|
| TruCluster was definitely interesting, but expensive and
| fairly esoteric. Most Linux people would just horizontally
| scale their applications without depending on its features (a
| filesystem that was shared seamlessly across 8 machines,
| along with virtual IP address aliasing with fast failover).
|
| More details on the underlying technology: https://www.hpl.hp
| .com/hpjournal/dtj/vol8num1/vol8num1art1.p...
| jamesfmilne wrote:
| It may be true, but anyone who's still running missing-critical
| applications on those machines won't migrate to Linux. If they
| moved to Linux they'd surely just dump the hardware too.
| vbezhenar wrote:
| On my previous work they run Oracle 9i on HPUX Itanium server.
| It was horribly slow (my laptop was faster) and weird to work
| with, it really dragged them down. They had to call pricey
| consultant for very basic tasks and those consultants did bad
| job. I could do anything with Linux, but there's no way I'd
| touch this thing with a long pole, it's absolutely foreign and
| I'm not really interested learning forgotten proprietary things
| that have zero value on job market.
|
| Still works as of today, AFAIK.
| snovymgodym wrote:
| That's insane to me. Oracle is just a relational database
| right? Wonder why that hasn't been migrated long ago. Guess
| it's just a case of not wanting to touch something that
| "works".
| pstuart wrote:
| It is insane, but it's a reflection of the incentive
| structure (like everywhere else). Lots of risk with little
| _recognizable_ upside.
|
| It's funny that companies can ostensibly track their
| expenses down to the penny but can't recognize the costs of
| technical debt.
| TylerE wrote:
| Oracle is a marketing engine for consultants that
| masquerades as a relational database to get through the
| front door.
| chasil wrote:
| Oracle 9i went out of regular patch support in 2007.
|
| If you found whatever PC that you were running from this
| era, would it be slower than your laptop? Very likely.
| organsnyder wrote:
| I'm pretty sure my smartwatch is more powerful than my
| 2007-era PC, at least for some metrics.
| ZiiS wrote:
| My NVMe laptop also runs a DB faster then Multi-AZ RDS
| costing its total purchase price per month. TBH I am not even
| sure if bandwidth and availability are actually better but I
| know where I run production.
| pvtmert wrote:
| RDS's storage is not physically mounted there. It uses
| network (hence, EBS).
|
| Plus, value of RDS = not having to upgrade/replicate
| cluster and backups manually.
|
| Of course there are better managed services...
| chasil wrote:
| Logical volume management under Linux is very close in syntax
| to HP-UX, and this was intentional.
|
| "Heinz Mauelshagen wrote the original LVM code in 1998, when
| he was working at Sistina Software, taking its primary design
| guidelines from the HP-UX's volume manager."
|
| https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)
| nubinetwork wrote:
| My $dayjob runs hpux on itanium, however the application has
| been decommissioned and we have to keep the hardware around for
| a while still for "reasons"...
| kstrauser wrote:
| I'm sure it's true. I'm also sure there's zero need to run a
| new kernel on such a critter. It's not as though new apps are
| coming out that only run on Itanic. Shops can run existing
| programs on the kernel they shipped for, and use far cheaper,
| faster, and energy-efficient x86-64 hardware for newer things.
| jauntywundrkind wrote:
| Is there an ok emulator anywhere? Does qemu have support?
| basementcat wrote:
| There is ski but it may be tricky to build on newer kernels
| because of changes in syscalls. https://github.com/trofi/ski
| jauntywundrkind wrote:
| Nice, thanks. It's a pointless optimization problem but it'd
| be interesting to futz around & see what either compiler
| techniques or weird things we could get AI to generate for
| this architecture.
|
| I always wonder if there's some kind of strange explicit smt
| or on-thr-fly instruction building or swapping... dynamically
| melding coroutines into ones main code.
| brycewray wrote:
| Might want to change "Arch" to "Architecture" in the headline,
| since this is about Linux, after all. :-)
| redundantly wrote:
| I was confused, wondering why Arch Linux was dropping support
| for it.
| trebligdivad wrote:
| I have fond memories of ia64 code optimisation at a startup in
| the mid 2000's; it was a fun [but slow] architecture. I have less
| fond memories of lifting the Intel Tiger systems, Intel would
| happily send out to devs in the desperate attempts to get them to
| port anything to Itanium.
| touisteur wrote:
| Well at least they tried that (sending dev kits with HW) for
| Itanium. Wish they'd done some of that on their last (PVC) GPU
| run.
| extraduder_ire wrote:
| I guess that's it for rearranging the deckchairs on the Itanic.
___________________________________________________________________
(page generated 2023-11-02 23:02 UTC)