Codearchiv - Längenproblem
Übersicht

![]() |
Willi die RübeBetreff: Codearchiv - Längenproblem |
![]() Antworten mit Zitat ![]() |
---|---|---|
Hi,
ich wollte im Codearchiv nen Code posten, allerdings scheint der Code wohl zu lang zu sein(23k Zeilen/712 KB) ![]() Zumindest bekomme ich folgende Fehlermeldung: Zitat: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1483945 bytes) in /var/www/vhosts/default/htdocs/forum/includes/functions_post.php on line 87
Wie lässt sich das Problem denn lösen? ![]() |
||
Ich habe keine Lösung, aber ich bewundere das Problem.
Tehadon Q6600, MSI Neo2-FR, 4GB Ram, nVidia 7800 GTX At the Farewell Party visit: MySpace | Homepage |
![]() |
Mr.Keks |
![]() Antworten mit Zitat ![]() |
---|---|---|
Sag mal, aber sonst geht's noch? Ich hoffe, der Source ist über 30 Dateien verteilt, die du jetzt einfach in ein Archiv packen und hochladen kannst.... Das Codearchiv ist nicht dazu gedacht, da irgendwelche Projekte opensource zu machen, sondern nur für kleinere Lösungen und Funktionen mit Beispiel. Wie hast du dir denn vorgestellt, dass Leute 23 000 Zeilen in ihrem Browser anzeigen lassen, markieren und in ihr Blitz pasten? | ||
MrKeks.net |
![]() |
Willi die Rübe |
![]() Antworten mit Zitat ![]() |
---|---|---|
Es handelt sich ja auch nur um eine einzige Funktion, genauergenommen einem Triangle Kollisionstest, den ich schon vor längerer Zeit nach einem Beispiel in C, das auf Olivier Devillers&Philippe Guigues Artikel "Fast and Robust Triangle-Triangle Overlap Test Using Orientation Predicates" basiert, in BB nachprogrammiert habe.
Bevor der Code jetzt unnötig auf meiner Platte vergammelt und verstaubt, hab ich mir gedacht, vllt. brauch ja der ein oder andere mal sowas und wollte es eben hier posten ![]() |
||
Ich habe keine Lösung, aber ich bewundere das Problem.
Tehadon Q6600, MSI Neo2-FR, 4GB Ram, nVidia 7800 GTX At the Farewell Party visit: MySpace | Homepage |
![]() |
Mr.Keks |
![]() Antworten mit Zitat ![]() |
---|---|---|
Lade die Datei einfach dort hoch https://www.blitzforum.de/upload/ und verlinke sie in deinem Thread.
Dreieckskollision ist zwar ein halbwegs komplexes Thema, aber wie kann das nur eine einzige Funktion von 23000 Zeilen sein? |
||
MrKeks.net |
![]() |
Smily |
![]() Antworten mit Zitat ![]() |
---|---|---|
Du könntest ja mal schauen, ob sich der Code Kürzen lässt.
Bei 23.000 Zeilen für eine Funktion muss irgendwas deutlich schiefgelaufen sein. |
||
Lesestoff:
gegen Softwarepatente | Netzzensur | brain.exe | Unabhängigkeitserklärung des Internets "Wir müssen die Rechte der Andersdenkenden selbst dann beachten, wenn sie Idioten oder schädlich sind. Wir müssen aufpassen. Wachsamkeit ist der Preis der Freiheit --- Keine Zensur!" stummi.org |
![]() |
Willi die Rübe |
![]() Antworten mit Zitat ![]() |
---|---|---|
Ok danke ![]() Zitat: Dreieckskollision ist zwar ein halbwegs komplexes Thema, aber wie kann das nur eine einzige Funktion von 23000 Zeilen sein? Gerade weil es nur eine einzige Funktion ist. Im Orginal in C werden etliche zusätzliche Hilfsfunktionen definiert, die den Code um das 30-fache verkürtzen(ca. 600 Zeilen). Da ich mir damals gedacht habe, dass diese Funktionsaufrufe in dieser hohen Anzahl zu viel Zeit benötigen(was wahrscheinlich auch so ist ![]() ![]() Zitat: Du könntest ja mal schauen, ob sich der Code Kürzen lässt.
Aus dem gerade genannten Grund bleibe ich der Meinung, dass der Code in der Form am schnellsten läuft. Ich mal noch ein paar Tests, indem ich mal die selbe Funktionsweiße des C Codes(aber nur weil mich der reine Code Längenvergleich von C und BB interessiert Bei 23.000 Zeilen für eine Funktion muss irgendwas deutlich schiefgelaufen sein. ![]() ![]() |
||
Ich habe keine Lösung, aber ich bewundere das Problem.
Tehadon Q6600, MSI Neo2-FR, 4GB Ram, nVidia 7800 GTX At the Farewell Party visit: MySpace | Homepage |
![]() |
Arrangemonk |
![]() Antworten mit Zitat ![]() |
---|---|---|
funktionsaufrufe sind geringfügig zetraubend, in assembler is das parameter in stack schreiben, funktion aufrufen, da drin register speichern, arbeiten, rückgabewert in stack speichern, register wiederherstellen, stackpointer wieder auf anfangsadresse zurücksetzen, fertig
das sind paar befehle... |
||
ingeneur |
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Willi: du weisst schon das deine "optimierung" eine grauenvolle deoptimierung ist oder?
Loopunrolling etc macht ja vielleicht bei shadern sinn, aber nicht bei heutigen CPUs die in der lage sind operationen parallel abzuarbeiten vorausgesetzt man geht ihnen nicht vorsätzlich aufn Nerv. Da hättest du mal gescheiter das ganze als funktionen gelassen oder wenn nicht als funktionen dann immerhin gosub statt hirnverbrannt copy-paste zu machen. Das Codearchiv hat qualitätsansprüche, dafür qualifiziert sich etwas mit so einem ansatz definitiv nicht. 23'000 zeilen in eine funktion kann man nahezu garantiert als erheblich langsamer annehmen. |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
![]() |
Willi die Rübe |
![]() Antworten mit Zitat ![]() |
---|---|---|
Zitat: funktionsaufrufe sind geringfügig zetraubend, in assembler is das parameter in stack schreiben, funktion aufrufen, da drin register speichern, arbeiten, rückgabewert in stack speichern, register wiederherstellen, stackpointer wieder auf anfangsadresse zurücksetzen, fertig
... von denen jeder Befehl verarbeitet werden muss.
das sind paar befehle... Kleine Korrektur: Der Rückgabewert kommt bei BB ins eax Register und nicht auf den Stack. Zitat: aber nicht bei heutigen CPUs die in der lage sind operationen parallel abzuarbeiten vorausgesetzt man geht ihnen nicht vorsätzlich aufn Nerv. Dies ist aber nur mit Multitheading möglich, welches BlitzBasic nicht unterstützt. Deshalb dürfte Loop Unrolling in BB immer einen Sinn haben. Klär mich auf, wenn ich mich irre.
Denn zu deiner Frage mit der "grauenvollen deoptimierung" irrst du dich nämlich: Siehe Edit. 1 Million Kollisionstest: 370 Zeilen: 970-980 Millisekunden 23k Zeilen: 460-470 Millisekunden In der kurzen Variante sind es pro Test 5410 Funktionscalls, in der langen gibt es keinen einzigen zusätzlichen. Und die kurze Version braucht sogar ein wenig länger als das doppelte, imho ein eindeutiges Ergebnis. Bestimmt lässt sich in beiden Versionen sehr viel optimieren. Aber ein gleiches Ergebnis wird man ohne Multithreading nie erreichen können. Also der Punkt mit der Codequalität wäre der einzige, der für die kurze Variante spricht. Allerdings ist mir Qualität und auch Quantität piepsegal, solange am Ende der Speed stimmt. Und tu mir einen Gefallen Dreamora und vermeide solche Ausdrücke wie "hirnverbrannt copy-paste zu machen.". Geschwindigkeitsoptimierung ist meiner Meinung nach ein sehr interessanter Diskussionspunkt und ich möchte nicht, dass dies in unnötigen Flames endet. Ok, ist ja gut, du bist hier der Mod ![]() Mit Gosub lässt wahrscheinlich schon ein wenig was rausholen, aber ich denke nicht wirklich viel. Dazu mach ich auch mal ein paar Tests. EDIT: Habe einen gravierenden Fehler entdeckt. Die oben genannten Daten stimmen nicht mehr, allerdings ist nachwievor die kurze Version langsamer, allerdings nur noch um 10-20 Millisekunden bei 1 Million Tests. Da dies nicht mehr so arg viel ist wie vorher, werde ich zu eurer Zufriedenheit die kurze Version ins Archiv stellen. |
||
![]() |
BladeRunnerModerator |
![]() Antworten mit Zitat ![]() |
---|---|---|
Könntest Du den Minitext-Mist bitte lassen? Entweder etwas ist wichtig genug zu erwähnen- dann schreib es in lesbarer Größe- oder es ist es eben nicht, dann lass es bleiben.
Ich werde intern mal anregen diese Minischrift aus dem System zu verbannen. Echt nervig das. |
||
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92 |
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Willi die Rübe hat Folgendes geschrieben: Zitat: aber nicht bei heutigen CPUs die in der lage sind operationen parallel abzuarbeiten vorausgesetzt man geht ihnen nicht vorsätzlich aufn Nerv. Dies ist aber nur mit Multitheading möglich, welches BlitzBasic nicht unterstützt. Deshalb dürfte Loop Unrolling in BB immer einen Sinn haben. Klär mich auf, wenn ich mich irre.
Ich rede nicht von Multithreading Ich rede von Optimierungen auf Basis eines einzelnen Threads die einen erheblichen Unterschied bei der Performance machen und die alle heutigen CPUs besitze. Seien es umsortierte Befehlsreihenfolgen um Cache Latency zu kompensieren oder andere Mechanismen, es gibt da unzählige Dinge die reinkommen seit Pentium-M / Core und AMDs neueren Generationen Mag schon sein das das ganze zu P3 Zeiten problematischer war, aber Intel und AMD haben massive Fortschritte gemacht seit damals, nicht zuletzt seit & dank den Pentium-M Prozessoren. |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
![]() |
Arrangemonk |
![]() Antworten mit Zitat ![]() |
---|---|---|
compiler optimieren aufjedenfall um welten besser als du das kannst^^ | ||
ingeneur |
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group