Re: MD5 is slow

[Saku Ytti via NANOG <nanog () lists nanog org>]

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
<nanog () lists nanog org> 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 <nanog () lists nanog org>
> Sent: Wednesday, September 10, 2025 17:36
> To: North American Network Operators Group <nanog () lists nanog org>
> Cc: Tom Beecher <beecher () beecher cc>
> 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 <nanog () lists nanog org>
> wrote:
>
> > Once upon a time, nanog () immibis com <nanog () immibis com> 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 <cma () cmadams net>
> > _______________________________________________
> > NANOG mailing list
> >
> > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/RI
> > 46RBUWSGZU7CWSCOPIB6SQZNWIIJYE/
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/BE3UNLEPJKFSQCIEDAERG4DNEVVY47UW/
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/R2MNUBZ6QOQUG4GLASIB7UHZWNG3VHHT/



-- 
  ++ytti
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/XFFHBQ776XITOB5QPXRGVETYAZRA6VNL/