hier noch ein hübsches Ergebnis aus dem "Fraktalgenerator", nach umbasteln auf non-K&R
Sehr schönes Tool ! Und als Benchmark geradezu genial, weil man die Größe des generierten GIFs einstellen kann. Also auch mal 12000x9000 Pixel, dann rechnet auch die Box hier schon ein Weilchen dran rum. Ist aber natürlich auch nicht mehr-Kern-fähig ... 1992 war das wohl auch noch nicht nötig ...
./fract -x 1280 -y 960 -o /tmp/fine.gif -r 0 -i 0 -x1 -1.26 -y1 -0.39 -x2 -1.25 -y2 -0.375
Mehrkernfähig ist so ein Fractalcode aber einfach zu machen, einfach die Bildhöhe geteilt durch die Anzahl gewollter/verfügbarer Threads, und dann jeden Kern an seinem Bildteil rechnen lassen.
Meistens müssen nur die Funktionsköpfe geändert werden.
Aus so etwas:
julia(xpixel,ypixel,x1,y1,x2,y2,cr,ci,xres,yres)
int xpixel,ypixel;
float x1,y1,x2,y2;
float cr,ci;
int xres,yres;
{ ...wird dann:
int julia( int xpixel, int ypixel, float x1, float y1, float x2, float y2, float cr, float ci, int xres, int yres )
{...Statt die einzelnen Parameter noch mal alle aufzulisten, kommt der Typ des Parameters direkt in die Klammer. Und wenn eine Funktion keinen Typ für den Rückgabewert hat, dann wird automatisch int genommen. Wenn kein Funktionsparameter vorhanden ist, dann muss void eingetragen werden:
Genau, mehr habe ich letztlich da auch nicht gemacht.
Und genau das muß dann eben noch für die jsin, jcos, jexp Routinen gemacht werden, wenn man die Bilder dafür sehen mag. ( Querlink zur Paralleldiskussion mit src )
Es gibt anscheinend auch Tools, die ein bißchen was von dieser Übersetzerei von K&R nach "modern"-C übernehmen können. Empfohlen werden
https://github.com/awarthen/un-obsolize
https://sourceforge.net/projects/cproto/
wobei ich das erste schonmal probiert habe, aber leider wollte das nicht mitspielen (zumindest nicht mit dem fract Programm). Beim zweiten steht der Test noch aus. Mal sehen.
Man muß halt auch schauen, welches C der Compiler erwartet. Gerade bei solchen Geräten ala "alte DEC" kann das vermutlich noch recht lange die originale Schreibweise sein. Dann könnte man sich das Umbauen komplett sparen. Manchmal gibt es evtl. auch einen Compilerswitch womit man ein "kompatibles" Verhalten zur alten Notation einschalten kann.
Zur "Threadifizierung" : da das Programm jeden Pixel direkt ins GIF rendert, wird das vermutlich gar nicht so ganz einfach sein, das in viele Threads aufzuteilen. Wenigstens muß man dann beim Zusammensortieren irgendwie die richtige Reihenfolge einhalten und/oder entsprechend warten. Die Bibliothek pthread ist aber schon ziemlich zeitig und allgemein über alle Workstations verfügbar gewesen.
Auf den DECs gibt es auch noch so einen Modus, wo man solche Rechnereien in einen Cluster verteilen kann, was eine beliebige Zusammenstellung verschiedener DECs sein kann - wie man das programmiert, habe ich aber noch nicht gesehen. Ist quasi die advanced Variante - und wird sicherlich demnächst mal "wiedererfunden" werden. Spätestens wenn M$ auf die Idee kommt, daß man in der Cloud nicht nur Daten speichern kann.
Ich finde v.a. aber auch so schon erschreckend, wie schnell das heute durch ist (das Fraktal). Auf so einer AXP wirds auch schon schnell gehen, aber immer noch mit bißchen Wartezeit. Kein Vergleich zu der Warterei auf einem 386er/486er oder CBM/Atari.
Deutsch
