Hacker News Reader

Comment by johngossman | Hacker News Reader

Sometime in the 80s, I implemented the core of the Mandelbrot Set calculation using assembly on an 8087. As the article mentions, the compilers did math very inefficiently on this stack architecture. For example, if you multiplied two numbers together and then added a third, they would push the first two numbers, multiply, pop the result, push the result back onto the stack (perhaps clearing the stack? after 40 years I don't remember), push the third number, add, pop the result. For the Mandelbrot loop this was even worse, as it never kept the results of the loop. My assembly kept all the intermediate results on the stack for a 100x speed up.

Running this code, the 8087 emitted a high-pitched whine. I could tell when my code was broken and it had gone into an infinite loop by the sound. Which was convenient because, of course, there was no debugger.

Thanks for bringing back this memory.

View on HN

Ah, lots of supposedly solid state computer stuff, including CPUs, did that. I, too, used it for debugging. This wasn't very conscious on my part, but if some whine became unusual and constant, it was often a sign of something hanging.

As I got older, not only did computers stop doing that, my hearing also got worse (entirely normal for my age, but still), so that's mostly a thing of the past.

I had a Radeon 5850 that did it. I ran someone's simple test unity project with vsync disabled, was getting around 3000 fps, and heard a tone that was probably 3000hz. Supposedly the 5090 FE's are pretty bad too.

The sound usually comes from inductors and capacitors in the power supply circuitry, not the ICs themselves as they draw pulses of power in patterns at audible frequencies. Modern CPUs and GPUs will still whine audibly if given a suitable load; the amount of current they consume is amazingly high, dozens to hundreds of amps, and also changing extremely quickly.

I used to hear the 16KHz whistle of CRT monitors. Of course, there is no whistle with LED monitors, but I stopped hearing the CRT whistle before they went obsolete. It was my first sign my hearing was declining.

I thought I was protecting my ears from loud noises like rock concerts and gunshots. But I didn't know that driving with the window down damages the hearing. I crossed the country many times with the window down. I'm pretty sure that was the cause as my left ear is much worse off than my right.

I don't need a hearing aid yet, but I'm pretty careful in wearing ear plugs whenever there are loud noises.

16 kHz is very high on the spectrum. Just the normal age-related decline of hearing makes that inaudible pretty quickly, you don’t need to drive with the window down for that.

You're right, but it was coincident with my realizing I had trouble hearing my watch tick with my left ear.

The compilers available at the time that the 8087 was commonplace were overall horrible and easily beaten anyway.

On the other hand, skilled humans can do very very well with the x87; this 256-byte demo makes use of it excellently: https://www.pouet.net/prod.php?which=53816

Yah, I never did a very good job with x87 code generation. I'm a bit embarrassed by that.

Oh boy...more memories. About a decade later at work I identified a bottleneck in our line-drawing code. The final step was to cast two floats (a point) to integers, which the compiler turned into ftoa() calls. Unfortunately, ftoa changed and restored the floating point control flags in order to set the rounding behavior (the Intel default did not match the standard library spec). Even more unfortunately, this stalled the Pentium's instruction pipeline. Replacing the casts with a simple fld/fist pair was another 100x speedup. A few years later I noticed the compilers started adding optimization flags controlling this behavior.

The idea of listening to hardware running a program to tell what it is doing is surprisingly old. On the EDSAC computer[0] a little speaker was connected across one of the serial data lines, which allowed the progress of a program to be listened to. Skilled operators could immediately tell when a program had triggered a bug and either gone off into the weeds or entered a tight loop.

[0]: https://en.wikipedia.org/wiki/EDSAC

With the PDP-8E we used to do this with an AM radio.

- You can do the Mandelbrot set with integers. In Forth it's 6 lines.

- Coincidentally, Forth promotes a fixed point philosophy.

- Forth people defined the IEEE754 standard on floating point, because they knew how to do that well in software.

> - Forth people defined the IEEE754 standard on floating point, because they knew how to do that well in software.

IEEE 754 was principally developed by Kahan (in collaboration with his grad student, Coonen, and a visiting professor, Stone, whence the name KCS draft), none of whom were involved with Forth in any way that I am aware. And the history is pretty clear that the greatest influence on IEEE 754 before its release was Kahan's work with Intel developing the 8087.

I'm a big fan of Kahan's work. I am just sad that the NaN remains terribly misunderstood.

The signalling NaN, however, turned out to be quite useless and I abandoned it.

I think the Zortech C++ compiler was the first one to fully support NaN with the Standard library.

I think the 1985's standard/propotal from the Forth Vendor Group set a precedent.

Citation?

Reply on news.ycombinator.com