Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: GEOS-InfoBase-Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Montag, 14. Dezember 2015, 19:52

Mandelbrot

Rechtzeitig zur Weihnachtszeit: Ein Marzipanbrot...ääähhh...Mandelbrot für R-Basic. Braucht nur ca. 15min zur Berechnung. ;)
»jpolzfuss« hat folgendes Bild angehängt:
  • Mandelbrot.png
»jpolzfuss« hat folgende Datei angehängt:
  • MANDELBR.ZIP (5,52 kB - 1 236 mal heruntergeladen - zuletzt: 4. Dezember 2022, 22:54)
There are two rules in life:
1. Never give out all of the information.

2

Montag, 14. Dezember 2015, 21:28

Braucht nur ca. 15min zur Berechnung. ;)
Länger. ^^ Aber sowenig Code.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »msgeo« (14. Dezember 2015, 22:05)


3

Freitag, 22. Januar 2016, 13:52

Die Berechnung hat bei mir unter DOSBox MegaBuild 6 (OS X, 75000 Cycles, GEOS mit 256 Farben) unglaubliche 30 Minuten gedauert. Anschließend ging die GEOS-Systemzeit um 15 Minuten nach. Irgendwie scheint meine DOSBox bei solchen Berechnungen an ihre Grenzen zu stoßen. Interessant wäre, ob DOSBox unter anderen Wirtssystemen ähnlich lange für die Berechnung braucht.

http://www.geopixel.de/RBPROGS/MANDELBR.HTM
Bernd

4

Sonntag, 24. Januar 2016, 13:09

Habe gestern mal die DOSBox-Cycles auf 36000 eingestellt, mehr als halbiert. Die Berechnung dauert weiterhin 30 Minuten, also gleich schnell/langsam. Allerdings lief die GEOS-Systemuhr nun wieder richtig...
Bernd

5

Sonntag, 24. Januar 2016, 20:06

Hallo,

ich führe aktuell auch Geschwindigkeitstest durch. Da ich nicht so viel Zeit habe hab ich die Grafikauflösung im UI Code auf 320x200 heruntergesetzt. Datei rechnet er das Fraktal in 3 min 41 Sek. (bei 7500 Cycles). Die Systemuhr stimmt noch.
Setzt man die Cycles af 150000 geht die Uhr schon nach, ohne das er das Fraktal berechnet.
Die Berechung dauer letzlich genau so lange (auch wenn das System saht: doppelt so schnell :-)

Vielleicht ist das ja der ultimative Weg, die maximale Taktzahl für die DosBox zu ermitteln: Solange die Systemuhr bei Fraktalrechnen nicht nachgeht ist noch Luft nach oben ;-)

Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

6

Sonntag, 24. Januar 2016, 20:56

Wozu so ein kleines Basicprogramm doch gut sein kann.... ;)
There are two rules in life:
1. Never give out all of the information.

7

Montag, 1. Februar 2016, 23:33

Anschließend ging die GEOS-Systemzeit um 15 Minuten nach.
In der Dosemu diesbezüglich keine Probleme.

8

Samstag, 6. Februar 2016, 10:29

Um zu untersuchen, inwieweit die Geschwindigkeit des Bildaufbaus beim Apfelmännchen von der Programmierart abhängt, habe ich drei kleine Applikationen entwickelt, die alle das gleiche Bild mit denselben Farben in derselben Auflösung (500 x 500) zeigen. Die erste Version ist eine reine C-Version (GOC). Bei der zweiten habe ich die Rechnungen von den von Geos zur Verfügung gestellten Fließkomma-Mechanismen ausführen lassen. Für die dritte Version habe ich etwas Zeit gebraucht: Die Rechnungen werden in Assembler auf dem 80x87 ausgeführt. Für diese dritte Version hatte ich mir erhebliche Geschwindigkeitsvorteile versprochen.

Auf meinem Rechner läuft Geos unter Windows XP. Auf anderen Systemen habe ich diese Applikationen noch nicht probiert. Die Progrämmchen sind ohne jeglichen Komfort, also ohne Bildausschnittswahl oder Zoom. Man kann lediglich die Iterationstiefe einstellen.

Besteht Interesse an den Apfelmännchen-Versionen?

Wilfried

9

Samstag, 6. Februar 2016, 10:40

Apfelmännchen

Ja, Wilfried, sehr großes Interesse... :)
Gruss Johannes

=================================
www.moellerjaner.de
www.kirche-geithain.de
=================================

11

Samstag, 6. Februar 2016, 22:15

Mich würde auch interessieren, was bei deinen Tests heraus gekommen ist.
Bernd

12

Samstag, 6. Februar 2016, 23:52

Tut mir leid, wenn ich mit meinem Beitrag hier etwas Off Topic bin, aber es passt eben so gut zum Thema Mandelbrot.

Die Programme sind mit der Iterationstiefe 20 voreingestellt. Diese Tiefe genügt bereits, um einen guten Eindruck vom Apfelmännchen zu bekommen. Mit steigender Iterationstiefe steigt natürlich auch die Rechenzeit. Die 80x87-Version bietet eine Überraschung.

Ich habe eine weitere Überraschung beigefügt. In den Beispielprogrammen vom SDK ist auch eine Apfelmännchenversion enthalten. Ich habe sie so angepasst, dass sie das gleiche Bild wie in meinen Versionen erstellt. Sie läuft aber nur, wenn die beigefügte Library MSET in den System-Ordner von BBE kopiert wird. Mit dieser Version wird die Fähigkeit der damaligen Geoworks-Programmierer sehr deutlich.

Wilfried
»Wilfried« hat folgende Datei angehängt:
  • Fractale.zip (17,6 kB - 1 207 mal heruntergeladen - zuletzt: 4. Dezember 2022, 23:35)

13

Sonntag, 7. Februar 2016, 19:23

Schade, dass man die Zeit manuell stoppen muss und das das Fraktal verschwindet, wenn man das Fenster anschließend bewegt :-(
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

14

Sonntag, 7. Februar 2016, 23:45

Mich würde ja mal interessieren, wie sich die Apfelmännchen auf anderen Systemen schlagen.

Hier meine Messwerte (Windows XP, Intel E6600) mit der Iterationstiefe 20 :

Fractal GOC: 2m36s Fractal_GOCFP: 2m03s Fractal 8087: 2m48s Benoit: ca. 1s

Wilfried

15

Montag, 8. Februar 2016, 00:04

Hallo Wilfried

Auf meinem X300 braucht schon das Benoit 3 Sekunden. Die anderen Versionen wahrscheinlich 5-10 Minuten.

So ein gigantischer Unterschied kann meines Erachtens nicht alleine durch die Implementierung des Algorythmus zustande kommen. Kann es sein, dass das locken von Speicherbereichen anders läuft oder eventuell geswappt wird ? Oder wird bei jedem Pixel eine Draw-Funktion aufgerufen ? Speichermässig würde ich Zeile um Zeile rendern und dann ausgeben.

Hast Du mal die enstandenen Bilder Pixel um Pixel verglichen ? Diese Funktion sollten diverse Bildprogramme haben. Könnte ja sein, dass mit unterschiedlichen Genauigkeiten gerechnet wird.

Gruss
Andreas

16

Montag, 8. Februar 2016, 10:55

Intel Core i5, 4 Kerne, 2,5 GHz, 4 GB RAM, Geos in Dosemu auf Linux Mint 17.3

Geos läuft mit der Auflösung 1280x720x64k, Iterationstiefe 20:
Benoit = 1,2 sec.
EC Fractal 80x87 = 10:02 min.
EC Fractal GOC = 9:27 min.
EC Fractal GOCFP = 7:22 min.

Scheint mir, das diese Coprozessor-Geschichte alles ausbremst.
Gruß Achim



PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

17

Montag, 8. Februar 2016, 16:06

Benoit berechnet bei mir ein anderes Bild als die anderen beiden. Das erklärt den Unterschied.
Gruß
Rainer

Wo habt ihr die Zeiten her? 1,2 Sekunden kann man doch nicht messen? Bei mir zeigt er keine Zeiten an. Hab ich was übersehen????? :?: :?: :?: :?:
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

18

Montag, 8. Februar 2016, 16:40

Das Benoit-Bild müsste aber fast identisch zu den drei anderen sein.

Die Zeit kann man in etwa messen, wenn man den Benoit-Rahmen verschiebt oder die andere Genauigkeit wählt.

Wilfried

19

Montag, 8. Februar 2016, 18:00

Intel Core2Duo P8600 2,4GHz. Geos/Dosemu Xubuntu 14.04, 4GB Speicher, Prozessorauslastung 53% lt. Conky

Geos Auflösung 1024 x 768 64k

Gemessen mit Stopuhr.
80 x 87 = 12.05 Min.
GOC = 11.35 Min.
GOCFP = 8.50 Min.
Benoit = 2.5 Sek.

Jens
- geos-tiger -

20

Montag, 8. Februar 2016, 19:24


Hallo Andreas,


<<So ein gigantischer Unterschied kann meines Erachtens nicht alleine durch die Implementierung des Algorythmus zustande kommen.>>

na ja, bei Benoit erfolgt die Berechnung der Bildpunkte in Assembler, das sollte schon schneller gehen. Daher meine Verwunderung, dass die Assembler-Berechnungen im 8087 nicht so schnell ablaufen, sogar langsamer als mit den C-Rechenroutinen.

<<Kann es sein, dass das locken von Speicherbereichen anders läuft oder eventuell geswappt wird ? >>

Da bin (zur Zeit noch) überfragt. Meine Versionen beschäftigen sich nicht damit.

<<Oder wird bei jedem Pixel eine Draw-Funktion aufgerufen ? >>

Bei jedem farbigen Punkt ja, die schwarzen Punkte (für die die meiste Rechenzeit verwendet werden muss) werden nicht gezeichnet, da der Hintergrund von vornherein schon schwarz ist. Die farbigen Bereiche (wesentlich weniger Berechnungen) werden ja ziemlich schnell gezeichnet.

<<Könnte ja sein, dass mit unterschiedlichen Genauigkeiten gerechnet wird.>>

Die GOC-Version rechnet mit dem Typ double, während die beiden anderen Versionen mit dem 80-Bit (long double) arbeiten. Benoit hat ein eigenes Zahlenformat (16 bzw. 48 Bit) .


Wilfried


Thema bewerten