VOGONS


A brief comparison of 386 FPUs

Topic actions

Reply 20 of 148, by Phido

User metadata
Rank Newbie
Rank
Newbie
rasz_pl wrote:

Quake doesnt need fast FPU, Quake needs pipelined one - ability to interleave instructions using zero cycle fxch register swaps. Afaik nothing x86 pre Intel Pentium did that, AMD caught up in late 1998 with CXT revision K6-2.

Which is what really caught the clone cpu makers out, FPU's up to that point were essentially only for the small professional market. Quake made it a requirement and highly valued a pipelined one. Cyrix probably would have been a much bigger success if Quake had never existed. Cyrix's FPU is quite good, it just wasn't pipelined like the pentiums.

There was also Cyrix EMC87 with memory mapping. But without special support it performed the same as regular Cyrix FPU. I have it but don't know of any program that supports it

Again, before it was clear that a FPU integrated onto the CPU was the future, memory mapped FPU's could have been. The 286 and 386 were only really limited by the FPU access mechanisims, the XT didn't care, and 486's and beyond it was tightly integrated you didn't dump lots of cycles accessing it. Writing code for different types of FPU access was a PIA.

In theory you could have made a 50Mhz or 60Mhz bus 386 socketed motherboard, and put a CPU and FPU on that (if intel had locked out sockets like they did on pentium II and greater). But it still would suck, and clock doubling would get you very little, and VLB working at those freq would have been impossible. If you think about Macintoshs, the IIFX was really a jumped up 386 (68030) equiv. They did do 40mhz bus, 50Mhz+ accelerators (motorola has 50mhz cpus and FPUS). For $9000 usd at the time.

Reply 21 of 148, by noshutdown

User metadata
Rank Oldbie
Rank
Oldbie

i ran quake with cyrix fastmath-40 and i remember getting around 2fps, but that seems not enough to evaluate the limited difference in increment of 0.1 fps.
i suggest rendering a 800*600 or 1024*768 image with autodesk 3d studio.
also note that the "40" of the fastmath is in different font from other characters, is it a remark or something?

Reply 22 of 148, by Anonymous Coward

User metadata
Rank l33t
Rank
l33t
feipoa wrote:

Why would they make a clock doubled FPU which isn't much faster than a Cyrix FasMath. What was the target CPU for the ULSI DX2 FPU?

Because these clock doubled FPUs were never officially released (at least the ULSI one wasn't), details are pretty much non-existent. These are my three theories on the crappy performance:

1.) Clock doubling on FPUs just isn't effective.
2.) The clock doubling is actually disabled, and special software is required to activate it like on SXL CPUs
3.) The DX2 moniker is just some kind of marketing gimmick, like when all the FPU manufacturers started magically churning out "487s" that were actually relabelled 387s. PEople who bought 50 and 66MHz clock doubled hybrid chips might have wanted some "faster".

"Will the highways on the internets become more few?" -Gee Dubya
V'Ger XT|Upgraded AT|Ultimate 386|Super VL/EISA 486|SMP VL/EISA Pentium

Reply 23 of 148, by feipoa

User metadata
Rank l33t++
Rank
l33t++
noshutdown wrote:

i ran quake with cyrix fastmath-40 and i remember getting around 2fps, but that seems not enough to evaluate the limited difference in increment of 0.1 fps.
i suggest rendering a 800*600 or 1024*768 image with autodesk 3d studio.
also note that the "40" of the fastmath is in different font from other characters, is it a remark or something?

I have noticed the font. I'm not sure what is up with it. Thread on that can be found here, http://www.cpu-world.com/forum/viewtopic.php?p=237935

Do you have a file to render with Autodesk? Are you suggesting I use a stop watch? Which version of Autodesk? Could you please provide some more detailed instructions?

Anonymous Coward wrote:

1.) Clock doubling on FPUs just isn't effective.
2.) The clock doubling is actually disabled, and special software is required to activate it like on SXL CPUs
3.) The DX2 moniker is just some kind of marketing gimmick, like when all the FPU manufacturers started magically churning out "487s" that were actually relabelled 387s. PEople who bought 50 and 66MHz clock doubled hybrid chips might have wanted some "faster".

Wowah, what? Clock doubling is disabled on the ULSI DX2? Which software do I need to enabled it? And if it is disabled by default, why does the ULSI DX2 perform better htan the ULSI DX1? Was there some architectural improvement? The IIT X2 has clock doubling enabled by default.

EDIT: I misread the first time. You are only offering some speculation...

Plan your life wisely, you'll be dead before you know it.

Reply 24 of 148, by kixs

User metadata
Rank l33t
Rank
l33t

They still pretty much rely on the CPU. Like I tested with AutoCAD. In FPU benchmarks you get big differences. But in ACAD it's just a few percent. If you change CPU from 386DX-40 to 486DLC-40 it's bigger improvement, than from the worst FPU to the best one.

Requests are also possible... /msg kixs

Reply 25 of 148, by Phido

User metadata
Rank Newbie
Rank
Newbie
Anonymous Coward wrote:
Because these clock doubled FPUs were never officially released (at least the ULSI one wasn't), details are pretty much non-exis […]
Show full quote
feipoa wrote:

Why would they make a clock doubled FPU which isn't much faster than a Cyrix FasMath. What was the target CPU for the ULSI DX2 FPU?

Because these clock doubled FPUs were never officially released (at least the ULSI one wasn't), details are pretty much non-existent. These are my three theories on the crappy performance:

1.) Clock doubling on FPUs just isn't effective.
2.) The clock doubling is actually disabled, and special software is required to activate it like on SXL CPUs
3.) The DX2 moniker is just some kind of marketing gimmick, like when all the FPU manufacturers started magically churning out "487s" that were actually relabelled 387s. PEople who bought 50 and 66MHz clock doubled hybrid chips might have wanted some "faster".

Because of bus access the FPU can't really do more. The cyrix fasmath is about as fast as you can make one, because it completes its FPU instructions in roughly the same amount of time it takes to access it. FPU access on the 386/387 is actually 14-20 cycles (there are only a handful that wouldn't be executed in that time). Most instructions are in fact executed faster than that on the Fasmath. So clock doubling does nothing, as it doesn't decrease the number of cycles to access it. Cyrix removed 1 waitstate from its FPU's whiched caused a very minor compatibility issue for some 386 chipsets, but it was worth it for the performance.

Hence why the development of memory mapped FPU's.

http://dougx.net/gaming/coproc.html

Using this special mode of the EMC87 provides a significant speed advantage. The traditional 387 CPU-coprocessor interface via IO ports has an overhead of about 14-20 clock cycles. Since the Cyrix 83D87 executes some operations like addition and multiplication in much less time, its performance is actually limited by the CPU-co-processor interface. Since the memory-mapped mode has much less overhead, it allows all co-processor instructions to be executed at full speed with no penalty.

In a test, the EMC87 at 33 MHz ran the single-precision Whetstone benchmark at 7608 kWhetstones/sec, while the Cyrix 83D87 at 33 MHz had a speed of only 5049 kWhetstones/sec, an increase of 50.6% [63]. In another test, the EMC87 ran a fractal computation at twice the speed of the Cyrix 83D87 and 2.6 times as fast as an Intel 387DX [64]. A third test found the EMC87's overall performance to be 20% higher than the performance of the Cyrix 83D87 [65].

So a Cyrix fasmath is actually 20%-100% faster, but is limited by its bus. So clock doubling will lift the other slow FPU's to a Fasmath level, but not higher. The fasmath can actually do some trigs functions in 1/3rd the clocks of the 486 FPU (see website).

A rapidcad isn't limited by the 386 bus access for the FPU, so it is about 20-85% faster than the original intel 387 and about 20% faster again than the Cyrix fasmath. The 486 FPU isn't really anything magical, if Intel just disabled the entire interger core of a 486 and made it pin compatible with the 387, it would only be as fast as a Cyrix Fasmath. When cyrix intergrated its FPU on the 486 it was pretty much as fast as the intel 486. It wasn't until intel went pentium its FPU became clearly superior. It is also why the 487 is also a fraud in that it is a whole cpu upgrade and doesn't operate like the 386 setup.

It was quite likely that intel originally intended not to intergrate the 486 FPU, but just make a faster fasmath like FPU, but as the co-processor wars heated up, Cyrix had a memory mapped FPU that ran x87 code, that would have broken the platform and arguably got away from intel. So intel was forced to integrate, and thus the RapidCAD and the 487 oddities.

I find this stuff fascinating. 386 was when there were massive decisions about the whole x86 architecture being made, good and bad, from half a dozen cpu and FPU manufacturers.. I could literally live in this time period forever.

Reply 26 of 148, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie
Phido wrote:

The 486 FPU isn't really anything magical, if Intel just disabled the entire interger core of a 486 and made it pin compatible with the 387, it would only be as fast as a Cyrix Fasmath.

Perhaps not magical but the design did have an interesting feature - the FPU uses the integer ALU to speed up some instructions. This has some side-effects:
- the exact cycle count for these FPU instructions depens on whether or not the ALU was free (486 is a pipelined CPU so ALU might be still busy with the previous instruction)
- interrupts have much greater latency when FPU executes really slow instructions (if interrupt is detected and taken, these will be aborted and later restarted)
It is, in theory, possible to hang a 486 in an infinite loop of restarting a long FPU instruction with high-frequency external interrupt.

Reply 27 of 148, by ph4nt0m

User metadata
Rank Member
Rank
Member

It could be interesting to test 387SX compatible FPUs as well. There were some fast CPUs like IBM 486SLC2 and TI 486SXLC2. I'm also a bit sceptical of Landmark for benchmarking purposes.

My Active Sales on CPU-World

Reply 28 of 148, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie

I found the GREEN MATH 4C87SLC-40 to be very unstable when paired with TI 486SXLC2 at 50MHz. It does work fine at 25MHz so I'm wondering why, bus speed is the same in both cases. Perhaps there some issue with BUSY signal timings in clock-doubled mode?

Reply 29 of 148, by matze79

User metadata
Rank l33t
Rank
l33t

Hm looks like its hold back due to bandwith.

The RAPIDCAD FPU is no FPU right ? its build in the CPU. As far is i know the RAPIDCAD FPU Socket Plug just generates some Signals.

Are there any tools for the X2 FPU ?

https://www.retrokits.de - blog, retro projects, hdd clicker, diy soundcards etc
https://www.retroianer.de - german retro computer board

Reply 30 of 148, by noshutdown

User metadata
Rank Oldbie
Rank
Oldbie
feipoa wrote:

I have noticed the font. I'm not sure what is up with it. Thread on that can be found here, http://www.cpu-world.com/forum/viewtopic.php?p=237935

Do you have a file to render with Autodesk? Are you suggesting I use a stop watch? Which version of Autodesk? Could you please provide some more detailed instructions?

about the font, my fastmath-40 is printed the same way so i am curious on this, but there seems to be no clear conclusion.
3d studio comes with some scenes, and it displays a progress bar as well as passed time during render(usually a few minutes with a 387). the newest version for dos is 4.0, after which they switched to 3ds-max for windows.

Reply 31 of 148, by ph4nt0m

User metadata
Rank Member
Rank
Member
rasz_pl wrote:
dirkmirk wrote:

I wonder if you would see any difference when running quake......

Quake doesnt need fast FPU, Quake needs pipelined one - ability to interleave instructions using zero cycle fxch register swaps. Afaik nothing x86 pre Intel Pentium did that, AMD caught up in late 1998 with CXT revision K6-2.

Pipelining isn't about the FXCH instruction. It's the ability to fetch and execute an instruction while the previous one is still being executed. While Pentium could execute FXCH in parallel with other floating point instructions, it only meant easier register stack access. Quake makes extensive use of FMUL/FDIV and, to a lesser extent, of FADD. FDIV is very expensive, 19 clocks for single precision to 39 clocks for extended precision. FMUL and FADD take 3 clocks each. However FMUL can be executed every 2 clocks and FADD every 1 clock. That's pipelining. FDIV wasn't pipelined, latency = throughput.

The 486 FPU wasn't pipelined, but it was also much worse in latencies. FADD for 8+ clocks, FMUL for 16 clocks, FDIV for up to 73 clocks. That's why Pentium was so much better than either AMD or Cyrix 5x86 in Quake. I have recently tested an AMD 5x86-160 vs. Pentium OverDrive - 100 with the same configuration. It was 16 vs. 26 fps.

I don't have latency data for all 387 coprocessors, but their performance was even more troublesome than of 486 due to port based I/O. Intel 387: FADD for 23 to 37 bus clocks, FMUL for 27 to 57 bus clocks, FDIV for 88 to 94 bus clocks. No surprise to get less than 1 fps in Quake with these.

AMD improved their FPU in K6, so FMUL and FADD took 2 clocks each. No pipelining still. However it had to compete with Pentium Pro etc. which offered higher latencies combined with excellent pipelining. FMUL every 5 clocks, FADD every 3 clocks, throughput every 1 clock. AMD worked around this with 3DNow! and left the complete FPU redesign for K7.

My Active Sales on CPU-World

Reply 32 of 148, by Phido

User metadata
Rank Newbie
Rank
Newbie

THere are some transcendental functions that can take hundreds of clock cycles that would be much faster (twice as fast) with a clocked doubled FPU, but most benchmarking software don't even execute those instructions.

Before Quake the main uses of math co-processors were:

3D rendering (most required) 3D studio, POVray also existed at this time, as did some other software.
CAD (2d and 3d most required FPU). Autocad for example required an FPU.
Spreedsheets (much faster but not required). Excel/Lotus 123.
Programmers/data scientists/Scientists creating custom code and working with large number mathematics. C compilers, pascal, basic, fortran, etc. Dropping in an FPU could make your code execute 10 times faster or more at runtime if it was heavy FP based.
Some image formats were originally implemented in FPU, but later integer algorithms were created. Some filters/effects etc used FPU's.

All of this would have been fine for the Cyrix/AMD FPU's, and in fact intel probably would have struggled in the 486 era against them and they would have been competitive in the early pentium era.

So it wasn't even that Cyrix/AMD FPU's were bad, they werent, just quake took specific advantage of the pipelining, as in it was specifically built around pentiums pipelining. Quake was much slower on all other CPU's, even those with more powerful FPU's (ones that could execute instructions in fewer cycles). Quake changed computers forever. Intel should buy John Carmack a ferrari for the rest of his life. Carmack did try to help AMD out, and ID did try supporting 3dNow! But by then things had moved on, and the 3D game had arrived.

Also regarding the 386/387 it was loads faster than the 287. Even the slow intel 387 FPU was loads faster. Most of which didn't even run at full 286 clock speeds. Most cases the 287 was slower than the 8087 in the XT. Because of the way the XT worked, Quake for an XT would have worked quite well as you could design code (assembly) that would execute integer/ALU in parallel with the FPU while it was doing its calculations. Sort of a gumby version of pipe-lining. the 387 also saw the adoption of the IEEE standards, and accuracy and precision and math handling became a lot less cowboy.

I wrote some quick basic code that benchmarked some FPU instructions, depending on the FPU make, some were twice as fast as others. Even though basic is quite a high level language and each math operation would be padded with a dozen other instructions, and NOP's as the whole compiler X87/X87 emmulation at run time trick.

Reply 33 of 148, by Phido

User metadata
Rank Newbie
Rank
Newbie
Deunan wrote:
Perhaps not magical but the design did have an interesting feature - the FPU uses the integer ALU to speed up some instructions. […]
Show full quote
Phido wrote:

The 486 FPU isn't really anything magical, if Intel just disabled the entire interger core of a 486 and made it pin compatible with the 387, it would only be as fast as a Cyrix Fasmath.

Perhaps not magical but the design did have an interesting feature - the FPU uses the integer ALU to speed up some instructions. This has some side-effects:
- the exact cycle count for these FPU instructions depens on whether or not the ALU was free (486 is a pipelined CPU so ALU might be still busy with the previous instruction)
- interrupts have much greater latency when FPU executes really slow instructions (if interrupt is detected and taken, these will be aborted and later restarted)
It is, in theory, possible to hang a 486 in an infinite loop of restarting a long FPU instruction with high-frequency external interrupt.

Oh wow, didn't know this. Will have to look deeper. Make sense as intel had microcoded their fpu so once intergrated it would make sense to borrow resources.

Like I said I find this who era fascinating.

I wonder if society had a nuclear war in say 1991 or so and technological development had been stunted at that level, what the world would look like. The adoption and development of the FPU really changed the world. 3D cad didn't become just a workstation thing, (and painful at that) but something that could be done on any engineers desk. Cars, buildings, research, engineering, MP3, JPEG, etc are all majorly impacted.

Reply 34 of 148, by rasz_pl

User metadata
Rank l33t
Rank
l33t
ph4nt0m wrote:
rasz_pl wrote:
dirkmirk wrote:

I wonder if you would see any difference when running quake......

Quake doesnt need fast FPU, Quake needs pipelined one - ability to interleave instructions using zero cycle fxch register swaps. Afaik nothing x86 pre Intel Pentium did that, AMD caught up in late 1998 with CXT revision K6-2.

Pipelining isn't about the FXCH instruction. It's the ability to fetch and execute an instruction while the previous one is still being executed. While Pentium could execute FXCH in parallel with other floating point instructions, it only meant easier register stack access.

Yes, but interleaving fpu instructions is, otherwise you would be reusing same parameters.
https://www.phatcode.net/res/224/files/html/ch63/63-02.html

ph4nt0m wrote:

Quake makes extensive use of FMUL/FDIV and, to a lesser extent, of FADD. FDIV is very expensive, 19 clocks for single precision to 39 clocks for extended precision. FMUL and FADD take 3 clocks each. However FMUL can be executed every 2 clocks and FADD every 1 clock. That's pipelining. FDIV wasn't pipelined, latency = throughput.
..
AMD improved their FPU in K6, so FMUL and FADD took 2 clocks each. No pipelining still. However it had to compete with Pentium Pro etc. which offered higher latencies combined with excellent pipelining. FMUL every 5 clocks, FADD every 3 clocks, throughput every 1 clock. AMD worked around this with 3DNow! and left the complete FPU redesign for K7.

What I didnt realize when I wrote this was that AMD didnt bother making their fpu pipelined even in K6-2/3. I foolishly assumed K6 -> K-2 upgrade included fpu pipelining, but just lacked quick FXCH.

Phido wrote:

Quake changed computers forever. Intel should buy John Carmack a ferrari for the rest of his life.

Afair that would be Abrash, he was the wizard optimizing bare metal stuff for Quake. I remember reading interview somewhere where Michael admits trying everything, and this trick being the best he could come up with. Perhaps not including optional second best codepath, one not tied so fully to specific vendor, would of changed history a bit.

Open Source AT&T Globalyst/NCR/FIC 486-GAC-2 proprietary Cache Module reproduction

Reply 35 of 148, by canthearu

User metadata
Rank Oldbie
Rank
Oldbie

Nah, it was likely that targetting Intel's pipelined FPU was the only way to reach decent overall performance on processors of the day.

At least this way, the game worked pretty OK on most computers of the day. In mid 1996, when Quake released, the Pentium 233 MMX was Intel's top of the line mainstream processor, however, most people would be running systems much slower than that.

Between the choice of having Quake run well only on Intel Pentium Processors, and crap elsewhere, vs having it just run like crap everywhere, the first option was the best.

Reply 36 of 148, by alvaro84

User metadata
Rank Member
Rank
Member
feipoa wrote:

How did you get two decimal place precision running Fractint? Is there a built-in timer that I don't know about? And what version were you using?

According to my article the version was 20.0. And I didn't even remember that there were versions that can't show two decimals on completion time. Even though I've been using Fractint since, like, 1993.

Okay, it may actually be less accurate. I guess the granularity is not 1/100 of a second, but more like 1/18.2 😐

Shame on us, doomed from the start
May God have mercy on our dirty little hearts

Reply 37 of 148, by alvaro84

User metadata
Rank Member
Rank
Member
ph4nt0m wrote:

AMD improved their FPU in K6, so FMUL and FADD took 2 clocks each. No pipelining still. However it had to compete with Pentium Pro etc. which offered higher latencies combined with excellent pipelining. FMUL every 5 clocks, FADD every 3 clocks, throughput every 1 clock.

And AMD's FPU probably works very well for old code that wasn't prepared for pipelining at all. It can even re-arrange instructions a bit so if the FPU code has integer instructions in the vicinity can be mixed with the latter and it can hide the FPU's non-pipelined nature to an extent. All in all, it should be able to run oldschool FPU code better than the pipelined but in-order P5.

Once you start to utilize FXCH to gain access to the depths of the stack to kind of simulate direct mapped registers and reach some parallelism you don't only make the code run faster on the P5 (which can run FXCHs in parallel with regular FPU instructions, so it's essentially free) but also slow it down on the K6 that isn't only unable to benefit from this manual parallelism but wast actual cycles on the extra FXCH operations.

The P6 can probably deal with the FXCHs efficiently and it's also a true out-of-order core so it may excel on both code bases.

(Also it's funny how the 486 can be halted by the combination of FPU code and frequent enough interrupts 😁 It was new to me, thanks Deunan 😁)

Shame on us, doomed from the start
May God have mercy on our dirty little hearts

Reply 38 of 148, by rasz_pl

User metadata
Rank l33t
Rank
l33t
canthearu wrote:

Nah, it was likely that targetting Intel's pipelined FPU was the only way to reach decent overall performance on processors of the day.

At least this way, the game worked pretty OK on most computers of the day. In mid 1996, when Quake released, the Pentium 233 MMX was Intel's top of the line mainstream processor

That would be $594 June 1997. 1996 was $599 non MMX 200MHz, $84 K5-PR100 and ~$150 Pentium 100MHz. The game worked well only on Intel computers for over a year, and even after that you needed >$250 K6 to get close to <$100 Pentium speeds.

canthearu wrote:

however, most people would be running systems much slower than that.

Between the choice of having Quake run well only on Intel Pentium Processors, and crap elsewhere, vs having it just run like crap everywhere, the first option was the best.

Im talking about shipping two code paths, something ID did later anyway in Quake 3. There was a chance for no fpu version running decently(20fps) on non Intel 100MHz CPUs (K5/Cyrixes), maybe even fastest socket 3 ones.

fixed point certainly can be done, consider Atari Falcon (Motorola 68030 @ 16 MHz; Motorola 56001 @ 32 MHz) running Quake engine at ~6-10fps https://www.youtube.com/watch?v=hDXSMgW-r5M
https://www.youtube.com/watch?v=WpwlZgQPCpk&l … 3Ww_M5nMm10m0UM

Open Source AT&T Globalyst/NCR/FIC 486-GAC-2 proprietary Cache Module reproduction

Reply 39 of 148, by feipoa

User metadata
Rank l33t++
Rank
l33t++

if Intel just disabled the entire interger core of a 486 and made it pin compatible with the 387, it would only be as fast as a Cyrix Fasmath.

This is also what past benchmarks have confirmed.

386 was when there were massive decisions about the whole x86 architecture being made, good and bad, from half a dozen cpu and FPU manufacturers.. I could literally live in this time period forever.

You aren't the only one!

noshutdown wrote:
feipoa wrote:

I have noticed the font. I'm not sure what is up with it. Thread on that can be found here, http://www.cpu-world.com/forum/viewtopic.php?p=237935

Do you have a file to render with Autodesk? Are you suggesting I use a stop watch? Which version of Autodesk? Could you please provide some more detailed instructions?

about the font, my fastmath-40 is printed the same way so i am curious on this, but there seems to be no clear conclusion.
3d studio comes with some scenes, and it displays a progress bar as well as passed time during render(usually a few minutes with a 387). the newest version for dos is 4.0, after which they switched to 3ds-max for windows.

The unit with the odd font was China-sourced. The one with the proper font was US-sourced. I've received a lot of funny fonted IC's from China, but a counterfeit Cyrix FasMath? Hard to say.

I'm messing with Autocad R11 and R12 now.

FDIV is very expensive, 19 clocks for single precision to 39 clocks for extended precision. FMUL and FADD take 3 clocks each. However FMUL can be executed every 2 clocks and FADD every 1 clock. That's pipelining. FDIV wasn't pipelined, latency = throughput.

I recall the Cyrix 6x86 being relatively fast for FDIV. I ran some PassMark benchmark for the cx6x86 vs. the Pentium at the same clock and Cryix's FPU divison equalled that of the Pentium at the same clock. Unfortunately (for Cyrix), FADD, FSUB, and FMUL fell short. I am curious how Cyrix pulled this off and just for FDIV?

That's why Pentium was so much better than either AMD or Cyrix 5x86 in Quake. I have recently tested an AMD 5x86-160 vs. Pentium OverDrive - 100 with the same configuration. It was 16 vs. 26 fps.

I have noticed similar results with GLQuake: Voodoo 1 vs. Voodoo 2 on a 486 The POD-100 was 57% faster than the Am5x86-160 (26.1 fps vs. 40.9 fps). In your results, the POD-100 was roughly 62% faster.

Phido wrote:

I wrote some quick basic code that benchmarked some FPU instructions, depending on the FPU make, some were twice as fast as others. Even though basic is quite a high level language and each math operation would be padded with a dozen other instructions, and NOP's as the whole compiler X87/X87 emmulation at run time trick.

Can I test it?

Phido wrote:

I wonder if society had a nuclear war in say 1991 or so and technological development had been stunted at that level, what the world would look like.

Exceptionally efficient coding perhaps? Less fluff in the software.

alvaro84 wrote:
feipoa wrote:

How did you get two decimal place precision running Fractint? Is there a built-in timer that I don't know about? And what version were you using?

According to my article the version was 20.0. And I didn't even remember that there were versions that can't show two decimals on completion time. Even though I've been using Fractint since, like, 1993.

Okay, it may actually be less accurate. I guess the granularity is not 1/100 of a second, but more like 1/18.2 :neutral:

Can you provide some more specifics on how you are able to see a timer? With version 19.6, I select the fractal to draw, it draws it, but the only timer I see is an analogue stop watch in my left hand.

alvaro84 wrote:

(Also it's funny how the 486 can be halted by the combination of FPU code and frequent enough interrupts :D It was new to me, thanks Deunan :D)

Confessions of a 1990's era cyber hacker?

rasz_pl wrote:

Im talking about shipping two code paths, something ID did later anyway in Quake 3. There was a chance for no fpu version running decently(20fps) on non Intel 100MHz CPUs (K5/Cyrixes), maybe even fastest socket 3 ones.

Good point. Anyone know if there are any compilations of Quake for non-Pentiums?

Plan your life wisely, you'll be dead before you know it.