8

According to a comment on https://news.ycombinator.com/item?id=31985142

The first benchmarks indicated the plain Archimedes had higher FP throughput than a 16MHz 386 with a 387.

The original Archimedes had an 8 MHz ARM-1 (no FPU). I would expect that to be roughly in the ballpark of a 16 MHz 386 for integer performance, might be a bit faster or slower depending on the benchmark. But I would expect it to fall well short of a 16 MHz 387 for floating point. An FPU is supposed to make FP run much faster; that's the whole point of having it! So the claim of higher throughput for the Archimedes is quite extraordinary.

Is there any substance behind that claim, or did something just get garbled along the way?

11
  • 1
    The link times out for me (land line and mobile). So just a comment on whats mentioned in your question: It seems like the typical combination of information bits picked by a journalist without knowing what it's about. It was said that a ARM2 could reach twice the Dhrystones as a 16 MHz 386. THen again, the most simple FP operation, (F)ADD (adding 32 bit real from memory to register) takes a 387 27 to 35 clocks. Not really sure if an ARM can do the same in half the clocks in all cases. Also, wasn't the ARM2 the first 8 MHz (ARM1 was 6 MHz). Then again, the ARM2 did support multiply.
    – Raffzahn
    Commented Jul 8, 2022 at 18:55
  • 2
    rwallace, I regularly wrote FP code for processors that lacked FP hardware. (ADSP-21xx, Intel x86, MSP430, etc.) Comparing FP performance is a tricky business when one has hardware assist and one doesn't and when the meaning of "FP" isn't defined. (Does it include transcendentals or just add, sub, mul, and div, for example?) I can say this. I stepped into the arena of FP for MSP430. There were a number of independent compiler vendors at the time competing like mad with each other. The very best one, in FP 'div' performance was 4X slower than my code that I wrote and gave to a compiler vendor.
    – jonk
    Commented Jul 8, 2022 at 19:42
  • 1
    rwallace, So perhaps you could refine the question to make it more answerable. Even then, no guarantee. But at least there might be a more objective answer.
    – jonk
    Commented Jul 8, 2022 at 19:43
  • 1
    We need to more precisely define what the measurement is. I can imagine that small floats (say, 16 bits of precision) are perfect for the ARM's barrel shifter. But as I recall the 387 has these 80-bit floats which are quick on-die but have high latency to/from memory. Commented Jul 8, 2022 at 20:14
  • 2
    @rwallace Dhrystone -> Integer; Whetstone -> Float Whetstone being the older one developed in the mid 1960s. Except, as I read it your question is about that article, not performance comparison of two CPUs, isn't it? For that, the source of that quote is the only one to add clarity. Otherwise you may want to rewrite the question toward asking for performance comparison between ARM2 and 80386, wouldn't you?
    – Raffzahn
    Commented Jul 8, 2022 at 21:47

3 Answers 3

6

The answer is no.

Finding numbers for the 387 is trivial, googling "387 whetstone test" brings you right to a great page that gives you a number of 5.68 MWIPS for the 386/387 at 40 MHz.

Finding numbers for the ARM was not so easy. The only hit you'll find is a 2020 post by SarahWalker, the maintainer of an Archimedes emulator. Those tests gave a number of 76.

But what does 76 mean? It can't be Whetstone/sec, because a 6502 can probably hit that. And 76 MWIPS from an 8 MHz chip no mater how cool is... unlikely.

I could not find contact info for SW but I saw posts by another user and they turned up on Wikipedia. So I emailed them and they forwarded it to SW and the number is 76 kWIPS. SW has since updated the original post to clarify this.

So: the ARMs were significantly slower than the 387, and likely the 386 by itself. This is not unexpected.

2
  • Thanks for going that length. Did she mention how optimized the code was? The 6502 hits about 3000 Whetstone/s at 1 MHz. (=0,003 MWIPS)
    – Raffzahn
    Commented Jul 11, 2022 at 22:24
  • 1
    UPDATE: A bare 386DX/40 gets 316 kWIPS, so assuming a 16 MHz part as in the initial post, it's still likely the 386 alone outperforms (albeit slightly) the ARM2. @Raffzahn - test conditions and compiler unknown. Commented Jul 13, 2022 at 13:12
5

I suspect the difference may lie in the floating-point formats.

BBC Basic for the Archimedes used a 5-byte Microsoft format that could be noticeably quick in software, even on the 8-bit BBC Micro, and gave more useful precision than 32-bit IEEE single precision (Source: working on CAD systems that used it, on Apple II and the BBC Micro). BBC Basic was the usual programming language in the early days of the Archimedes: I had a friend who did serious numerical simulations with it in 1989.

An 80387 using IEEE formats could plausibly be slower for add, subtract and multiply, even with compiled C or FORTRAN. An FADD is 20 cycles, according to the manual, which is surprisingly high. It would likely be faster for divide, square root and trigonometric functions.

However, the standard of discussion in the OP's source does not seem terribly high, so I'd be careful about relying too hard on it.

6
  • 1
    Good point that FP format might as well add advantage. Except memory access wasn't really a hurdle for the 387. A 32 bit access was two cycles, while crunching even a basic ADD was ten times that.
    – Raffzahn
    Commented Jul 9, 2022 at 11:41
  • @Raffzahn Really? 20 clocks for an FADD sounds almost like a bit-serial design; you might well be able to do it faster on the 386 in software. Commented Jul 9, 2022 at 11:45
  • 1
    Well, it's what the manual says And no, I don't think it can be done faster on the CPU alone. Don't underestimate the effort of denormalization and renormalization. Also the 387 timing is (next to) independent of 32 vs. 64 bit.
    – Raffzahn
    Commented Jul 9, 2022 at 12:13
  • 1
    I'm not sure if a 387 @16 MHz really would be slower then an ARM2 at 8 MHz (The Archimedes had an ARM2). While the ARM does have nice shift modifiers, they don't help as much. For an add both float needs to be loaded first, then split into significant and exponent, then shifted according to exponent, then added, then shifted again according to result to generate a new exponent. All of that isn't as simple as it seams. doing so in less than 10-15 cycles seems hard to accomplish - at least for universal operation - and don't forget over/underflow handling. I doubt that an ARM2 beats a 387 here
    – Raffzahn
    Commented Jul 9, 2022 at 14:15
  • 1
    @Raffzahn: Much of the cost of software floating-point math centers around precise handling of corner cases. If one is willing to tolerate some sloppiness (e.g. having numbers below a certain magnitude sometimes underflow to zero, but not do so consistently) such tolerance may allow code to be significantly faster and more compact. Whether such faster code is more efficient, or simply broken, would depend upon the application requirements.
    – supercat
    Commented Jul 9, 2022 at 17:00
2

The 8087 used microcoded operations for FP math, not a fully hard-wired FP ALU, as most modern processors use. IIRC, it took on the order of 100 clock cycles to do an IEEE FP multiply. IEEE FP addition can require even more clock cycles due to the need for pre and post scaling denorms.

A RISC processor could likely also do a simplified format FP multiply in roughly the same order of number of 1-clock cycle instructions.

So it would not be impossible for a single cycle RISC to do FP in the same number of clock cycles as an older microcoded FPU implementation.

1
  • 2
    Thats 8087, but the FPU in question is the387, which does an FMUL in 24-36 clocks.
    – Raffzahn
    Commented Jul 9, 2022 at 17:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .