Linked by Thom Holwerda on Wed 28th Jun 2017 19:28 UTC
Hardware, Embedded Systems

Last week I wrote a Mandelbrot set program for the Xerox Alto, which took an hour to generate the fractal. The point of this project was to learn how to use the Alto's bitmapped display, not make the fastest Mandelbrot set, so I wasn't concerned that this 1970s computer took so long to run. Even so, readers had detailed suggestions form performance improvements, so I figured I should test out these ideas. The results were much better than I expected, dropping the execution time from 1 hour to 9 minutes.

Articles like this are very satisfying to post, because we can all agree this is just plain awesome, no ifs or buts.

Order by: Score:
great stuff!
by project_2501 on Wed 28th Jun 2017 22:56 UTC
project_2501
Member since:
2006-03-20

especially the bit about turning off the screen ..

Reply Score: 2

RE: great stuff!
by DeepThought on Thu 29th Jun 2017 05:43 UTC in reply to "great stuff!"
DeepThought Member since:
2010-07-17

Turning off the screen also improved speed on ZX81 :-) The "FAST" mode.

Reply Score: 3

RE[2]: great stuff!
by avgalen on Thu 29th Jun 2017 07:54 UTC in reply to "RE: great stuff!"
avgalen Member since:
2010-09-23

Turning off the "screen" is still a valid approach for many tasks.

dir /a /s on c:\ takes forever because it is displaying all the output, but dir /a /s > %temp%\c.txt finishes a whole lot quicker

Basically all automation tasks should be run with either their window minimized or with https://excel.tips.net/T002498_Turning_Off_Screen_Updating.html

We are living in a computerworld where literally tens of billions of computations are done per second and processing times are often measured in miliseconds while screen refresh is mostly once per 17 miliseconds.

I once improved the performance of a program by a factor 100 by not updating the progressbar every time something changed but only once per second.

Reply Score: 3

RE[3]: great stuff!
by DeepThought on Thu 29th Jun 2017 08:17 UTC in reply to "RE[2]: great stuff!"
DeepThought Member since:
2010-07-17

Turning off the "screen" is still a valid approach for many tasks.

I once improved the performance of a program by a factor 100 by not updating the progressbar every time something changed but only once per second.


I guess every programmer has a story like this.

Mine is from embedded: Used to measure timing with an GPIO pin and got shocked. Taskswitching on a 1.2GHz CPU was horrible. But then I learned that the GPIO is connected to a 33MHz bus. So "turning off the screen" decreased the times by factor 10. :-)

Reply Score: 2

RE[4]: great stuff!
by Kochise on Thu 29th Jun 2017 12:20 UTC in reply to "RE[3]: great stuff!"
Kochise Member since:
2006-03-03

Made a progress bar and got a great speedup just by limiting the redraw frequency to something coherent and humanly bearable, like 4 times a second, which already doesn't allow to read the text with precision.

Reply Score: 3

Manual
by Earl C Pottinger on Thu 29th Jun 2017 00:35 UTC
Earl C Pottinger
Member since:
2008-07-12

I downloaded the manual. I was surprise that there was no "OR" function in the CPU. The work-a-round would work but would be slow compared to a proper instruction set.

Reply Score: 1

RE: Manual
by jockm on Thu 29th Jun 2017 05:01 UTC in reply to "Manual"
jockm Member since:
2012-12-22

I was surprise that there was no "OR" function in the CPU.


Well one could be added to the microcode store, and there were alternate microcoded instruction sets for the Alto and D-Machines that did include OR; it was just that the default DG Nova compatible microcode didn't include it.

Reply Score: 2

RE[2]: Manual
by avgalen on Thu 29th Jun 2017 08:03 UTC in reply to "RE: Manual"
avgalen Member since:
2010-09-23

Well one could be added to the microcode store, and there were alternate microcoded instruction sets for the Alto and D-Machines that did include OR; it was just that the default DG Nova compatible microcode didn't include it.

This comment should be send to every developer on every locked down platform so they realize just how different their current solutions to problems are from the past.
While they chew on that they can be served a bit of desert in the shape of "how Compaq reverse engineering of the IBM-PC BIOS started the general computing area for the masses"

Reply Score: 2

RE[3]: Manual
by jockm on Fri 30th Jun 2017 02:59 UTC in reply to "RE[2]: Manual"
jockm Member since:
2012-12-22

Well most computers at that time didn't have a writable microcode store. But it is also important to remember that that flexibility came at a price.

Intel and AMD implement a CISC instruction set on top of a hidden RISC microarchitecture. Microarchitectures can be seen as the modern equivalent of microcode

Reply Score: 2

RE[4]: Manual
by viton on Sat 1st Jul 2017 16:02 UTC in reply to "RE[3]: Manual"
viton Member since:
2005-08-09

Microarchitectures can be seen as the modern equivalent of microcode

Some RISC CPUs have microcode too.

Reply Score: 2

Limited Hardware...
by FortranMan on Thu 29th Jun 2017 02:28 UTC
FortranMan
Member since:
2011-12-21

Some of this stuff reminds me of programming my HP48GX calculator back in the day. Turning off the screen to improve performance was a common tactic on that platform too.

After switching from what basically constituted a high-ish level assembly (SystemRPL) to modern computer languages such as Fortan 2003+, C++, etc, its sometimes hard to capture the charm of those limited languages and systems. That being said, I like all the processing power and capability of modern tools.

Reply Score: 1

Fun reminds me of
by dizzey@gmail.com on Thu 29th Jun 2017 11:34 UTC
dizzey@gmail.com
Member since:
2016-08-11

Reminds me of when we had a seriall graphical dec vt 340 terminal connected to a vax workstation.

We had it do the spinning 3d cube on the terminal and also did some mandelbrott drawings.

the first implementation of the cube was horrible slow since we did draw the lines with pixels but at a later point we optimised it to send "lines" and it became decent

Reply Score: 1