Talking about IA is almost nonsense, it doesn't have any implied performance losses or gains. RISC/CISC is utterly uninteresting in the modern world.
For more than 20 years CPUs have not executed the code compilers deliver to them. There is a front-end that translates the standard IA into some proprietary micro ops the CPU uses. We could argue this is really bad, as the compiler has no control over execution. But the reality is the compiler is terrible and produces code that doesn't have sufficient information how to run it fast. So to run that low information code fast, hardware designers came up with this design where hardware does magic tricks (which will inherently make CPU unsafe) to usually run code very fast. In Itanium Intel tried to fix this, it tried to make the CPU dumb, and the compiler smart. But no one ever produced a smart compiler for Itanium. Turns out, it is a lot easier to make a business case out of selling CPU hardware than it is to make a business case out of selling smart compiler licenses. So we have a lot of R&D budget to make CPUs increasingly complex and increasingly detached from the instruction set, and no R&D budget to make smart compilers which emit enough information to run the code fast without unsafe assumptions made by HW. There is no particular reason why the CPU couldn't have two front-ends and run two IA using its proprietary micro ops. You can certainly have SHA instruction set in ARM: https://developer.arm.com/documentation/ddi0602/2025-06/SIMD-FP-Instructions/SHA256H--SHA256-hash-update--part-1-- https://datatracker.ietf.org/doc/html/rfc2385 Some measurements of a sample implementation showed that on a 100 MHz R4600, generating a signature for simple ACK segment took an average of 0.0268 ms, while generating a signature for a data segment carrying 4096 bytes of data took 0.8776 ms on average. This is an over 20 years old CPU, even then the MD5 cost was under millisecond. But it actually mattered much more, because the same core was doing packet lookup and copying memory. This R4600 was used in NPE100, NPE150 in 7200, amongst others. If you want to believe that MD5 and SHA are intentionally slow, I apologise for trying to rob that joy from you and will not do it again. On Thu, 11 Sept 2025 at 09:23, Vasilenko Eduard via NANOG <[email protected]> wrote: > > There is a trend to move to ARM on desktops. Apple has finished. Microsoft > has ambitious plans. RISC architecture is gaining more attention now. It is > the trend that makes sense to support. > > RISC has consequences: more cores, greater effectiveness (in terms of power > and cost), and a lower cost per workload, but fewer resources per core > (always) and lower frequency (typically). > > Pointing to CISC is not in the trend. > Agree, CISC is probably fast enough not to pay attention to the hash > calculation time (if you do not care about an additional > 1ms*2(input/output)*5(hops) on the control plane). > Ed/ > -----Original Message----- > From: Tom Beecher via NANOG <[email protected]> > Sent: Wednesday, September 10, 2025 17:36 > To: North American Network Operators Group <[email protected]> > Cc: Tom Beecher <[email protected]> > Subject: Re: MD5 is slow > > > > > I don't know what's common right this minute (as I haven't been > > shopping for routers for a bit), but for example, all the Juniper MXes > > outside of the MX80 have been competent-to-beefy Intel CPUs. I don't > > think the routers likely to be running a lot of BGP are going to be > > using some low-end CPU. > > > Anything reasonably newer on MX has Haswell or Icy Lakes in them, and > multicore. But even that Ford Model T of an MX80 wouldn't flinch at MD5 > operations. > > On Wed, Sep 10, 2025 at 9:33 AM Chris Adams via NANOG <[email protected]> > wrote: > > > Once upon a time, [email protected] <[email protected]> said: > > > A hash is also way faster than 5ms to compute. I suggest doing your > > > own > > benchmark. Run it on an old raspberry pi or one of Amazon's cheapest > > ARM servers to be sure it's comparable to typical router CPU hardware. > > > > I don't know what's common right this minute (as I haven't been > > shopping for routers for a bit), but for example, all the Juniper MXes > > outside of the MX80 have been competent-to-beefy Intel CPUs. I don't > > think the routers likely to be running a lot of BGP are going to be > > using some low-end CPU. > > -- > > Chris Adams <[email protected]> > > _______________________________________________ > > NANOG mailing list > > > > https://lists.nanog.org/archives/list/[email protected]/message/RI > > 46RBUWSGZU7CWSCOPIB6SQZNWIIJYE/ > > > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/[email protected]/message/BE3UNLEPJKFSQCIEDAERG4DNEVVY47UW/ > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/[email protected]/message/R2MNUBZ6QOQUG4GLASIB7UHZWNG3VHHT/ -- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/XFFHBQ776XITOB5QPXRGVETYAZRA6VNL/
