Optimierungsqualitaet von C-Compilern mit CPU-Erweiterungen
-
Beim gcc kannst du auch mal speziell ein MMX oder SSE Flag setzen (k.A. welche Option) und den generierten ASM-Code anzeigen lassen. Wie gesagt, Intel macht es bestimmt. Ist aber nicht so gut wie per Hand, da er nur den Code sieht und Semnatik nicht. Kann aber auch besser sein, falls der Compiler mehr Optimierungsmoeglichkeiten sieht als der Programmierer. Du kannst auch stueckweise portieren, indem du inline-Assembler nutzt. Wobei das auch davon abhaengt, wie den ASM-Code aussieht.
-
Nobuo T schrieb:
Tja, ist echt schade, denn mit OOP wollte ich den Code nicht auch noch aufblasen, da kann ich ja gleich alles in Java neu schreiben. :p
Und C++ mit ohne OOP fuer quasi-C-Code missbrauchen ist wohl auch nicht das Wahre...?Würde das nicht so schwarz sehen. Mit ohne OOP geht doch auch, ich weiß übrigens nicht, ob Intel nicht auch pures C unterstützt, mit einem Trick kann man die CPU- Abfrage weitgehend aushebeln und so AMD- CPUs optimierten Code unterjubeln.
Nobuo T schrieb:
Diese Laufzeitverhaeltnisse habe ich auch in etwa erwartet. Sehr viel an sinnvollen Alternativen bleibt da IMHO nicht mehr.
Die Zeit hat doch für Dich gearbeitet. Vor zehn Jahren etwa hast Du Dich an die Sache gemacht, da waren so 800 MHz "state of the Art", bei mir tuckert so'n 08/15- DualCore, der die Kisten von damals an die Wand pustet, wenn auch nur ein Kern rennt. Ist bei meinen Controllern auch nicht anders, 600 Byte handoptimierten Assembler mit 20 Byte RAM- Verbrauch zahlt mir doch keiner mehr, wenn jeder Dödelcontroller 4k Flash sowie 512 Byte RAM mitbringt (70 Cent Hunderterpreis) und abgeht wie Schmidt's Rennmaus.
Nobuo T schrieb:
So weit waere es dann eigentlich sinnvoller, wenn ich meinen Assemblercode auf Kosten von etwas Performance auf die Haelfte der Zeilen zusammenstauche und dann damit weiter arbeite.
Ich habe keine Ahnung, wie timingempfindlich Dein Zeug ist, aber als ich bei C (wieder) eingestiegen bin, hatte ich noch den Impetus, Laufzeitanalysen zu betreiben und die Zeitmörder dann per Inline- ASM zu killen, eine Möglichkeit, die auch Dir offensteht. Nur: Menschliche Faulheit siegt und zum zweiten war es nie nötig, weil die Dingerchen zu schnell und ressourcenhaltig geworden sind. Das dürfte auch bei Dir so sein.
Mein Tip im Sinne der Wartbarkeit: Schnapp' Dir ein kleines Projekt, portier's und schau' mal, ob es noch tut.
-
Nobuo T schrieb:
Einsatzgebiet ist ein Audio-Sampler. Da kann man im Prinzip sehr gut mit MMX und SSE basteln, allerdings ist der Code momentan AFAIR noch weitestgehend 386-kompatibel.
Reizt seine Moeglichkeiten aber IMHO schon ziemlich weit aus.Sampler? 386? Huh, genau das sind aber nicht die besten Freunde, zudem wird der "Ur-386er" Opcode nicht mehr durchgehend optimal durchgerissen.
Schau' doch mal in die OS- Ecke bei den Soundbearbeitungstools, da gibt es etliches und sieh' Dir an, was die hernehmen.
Es geht auch ohne ASM, jede Wette!
-
pointercrash() schrieb:
Es geht auch ohne ASM, jede Wette!
das denke ich auch. sollte mit dem schäbigsten c-compiler machbar sein.
-
Danke erstmal an alle fuer die ausfuehrlichen Ratschlaege.
Stimmt vielleicht, dass es auf aktuellen CPU wirklich oft ziemlich egal ist, wie gut so mancher Code im Detail optimiert ist und dass 386-Code auf aktuellen CPU nicht optimal laeuft, aber wie gesagt ist mir die 386-kompatibilitaet eben auch nicht so ganz egal.
Sinn und Zweck der Uebung, weshalb ich die Sache auch mal urspruenglich in Asm angefangen habe, war naemlich auch meinem uralten 486er und 586ern noch ein bisschen Multimedia zu entlocken. Aus dem Grund pflege ich u.A. auch noch einen DOS-Port.
Das Ganze laeuft halt auch relativ gut, ist nur eine Bitch zu warten und zu erweitern (zB. auch im Hinblick auf Erweiterungen aktueller CPU). Da waere C oder C++ natuerlich viel besser, aber dadurch sollte eben nicht unbedingt die Abwaertskompatibilitaet komplett draufgehen durch irgendwelchen von den Compilern billig hingeschlunzten x86-Code, der auf den alten Maschinen deutlich langsamer laeuft. Deshalb mache ich mir da schon Gedanken ueber die Code-Qualitaet.
Aus dem Grund auch meine 2. Frage nach der Moeglichkeit, einzelne Funktionen mit unterschiedlichen CPU-Features zu kompilieren und zu linken. Das klappt dann spaetestens im DOS-Port natuerlich auch nicht mehr so einfach mit DLLs.Sry, hoffe ich habe meine Motive jetzt etwas klarer gemacht.
-
nobuo, das hört sich stark nach 'premature optimization' an, was du vor hast. ist das ganze wirklich so zeitkritisch? hast du irgendwelche messdaten, berechnungen, erfahrungswerte, etc. die belegen, dass du bereits auf jeden taktzyklus achten musst?
-
Ich habe zB. einen 486er mit 66MHz, dessen CPU ich unter DOS mit einigen aelteren Versionen des IT-Players locker zu 100% auslasten konnte. Dann stockt der Sound halt unschoen. Reicht das als Erfahrungswert?
Habe das Teil zwar schon eine Weile nicht mehr aufgebaut und getestet, aber ich denke obwohl der Sampler inzwischen vielleicht knapp doppelt so viele Kanaele bringt, wuerde ich da recht schnell an die Belastungsgrenze stossen... mal sehen, vielleicht probiere ich das ueber's Wochenende mal wieder aus.
Der IRQ schlaegt halt gnadenlos zu, und die innersten Schleifen der sampler laufen insgesamt pro Kanal und Buffer ca. 1000mal durch. Ist dann also schon ziemlich zeitkritisch.Ab ~400MHz-CPU ist das natuerlich kaum noch ein Problem mehr, aber ich wuerde halt schon gern moeglichst viel auch auf langsamen Maschinen rausholen.
-
Nobuo T schrieb:
Ich habe zB. einen 486er mit 66MHz, dessen CPU ich unter DOS mit einigen aelteren Versionen des IT-Players locker zu 100% auslasten konnte. Dann stockt der Sound halt unschoen. ...
Klar, dann nuckelt der auch noch an einer Festplatte im PIO 1- Mode rum, die Kiste ist "dicht". Aber frag' Dich mal, wer überhaupt noch so eine Leiche in Betrieb und damit ausgerechnet Audiobearbeitung im Sinn hat. Ich geh' ja auch nicht auf ein Tennisturnier mit Opas Holzracket samt Naturdarmbespannung im Gepäck. Schön, im Prinzip geht's, daran kann man sich erfreuen, wie sinnig das ist, ist eine andere Geschichte.
Nobuo T schrieb:
Ab ~400MHz-CPU ist das natuerlich kaum noch ein Problem mehr, aber ich wuerde halt schon gern moeglichst viel auch auf langsamen Maschinen rausholen.
Vergiß' nicht, daß 386er- Code zunehmend stiefmütterlicher behandelt wird.
Mach' einen Schnitt, sag' das ist das alte Zeug für DOS- Fans und pfleg' das System mit einem ordentlichen Compiler und neuen Features weiter.
-
pointercrash() schrieb:
Nobuo T schrieb:
Ich habe zB. einen 486er mit 66MHz, dessen CPU ich unter DOS mit einigen aelteren Versionen des IT-Players locker zu 100% auslasten konnte. Dann stockt der Sound halt unschoen. ...
Klar, dann nuckelt der auch noch an einer Festplatte im PIO 1- Mode rum, die Kiste ist "dicht". Aber frag' Dich mal, wer überhaupt noch so eine Leiche in Betrieb und damit ausgerechnet Audiobearbeitung im Sinn hat. Ich geh' ja auch nicht auf ein Tennisturnier mit Opas Holzracket samt Naturdarmbespannung im Gepäck. Schön, im Prinzip geht's, daran kann man sich erfreuen, wie sinnig das ist, ist eine andere Geschichte.
Ich sollte da wohl noch was klarstellen: ich bin ein DOS-Fan. Ich sitze hier auf einiger alter Hardware und es macht mir Spass, noch was aus den alten Dingern rauszuholen (zB. schon mal versucht, einen mp3-Player zu finden, der vernuenftig auf einem Pentium 100 laeuft?)
Es handelt sich dabei ja auch um ein Hobby-Projekt hauptsaechlich fuer mich selbst. Nur "der Weg ist das Ziel" hat eben irgendwo auch seine Grenzen.
Offenbar genauso wie die Portierbarkeit von Software zwischen zeitlich so weit auseinanderliegender Hardware.
Tja, um wirklich effektiv weiterentwickeln zu können, bleibt mir dann wohl nichts anderes uebrig, als tatsaechlich neu anzufangen.
-
Nobuo T schrieb:
... noch was aus den alten Dingern rauszuholen (zB. schon mal versucht, einen mp3-Player zu finden, der vernuenftig auf einem Pentium 100 laeuft?)
Nein, aber ich bin mal durch Zufall über ein Projekt gestolpert, der das auf noch älterer Hardware hinbekommen hat. Mit ein paar Pins der LPT hat er per TSR- Treiber einen externen Decoderchip gefüttert.
Nobuo T schrieb:
Es handelt sich dabei ja auch um ein Hobby-Projekt hauptsaechlich fuer mich selbst. Nur "der Weg ist das Ziel" hat eben irgendwo auch seine Grenzen.
OK, klar, sowas ist meist Spaß am Machen und unter DOS gehört einem der Rechner doch zumeist selbst
Aber Du siehst ja selbst, daß der Weg immer steiniger und auch einsamer wird, weil niemand mehr will, daß da jemand langkommt.Nobuo T schrieb:
Offenbar genauso wie die Portierbarkeit von Software zwischen zeitlich so weit auseinanderliegender Hardware.
Was meinst Du, wieviele schon lange das Gate A20 zur Hölle wünschen
Nobuo T schrieb:
Tja, um wirklich effektiv weiterentwickeln zu können, bleibt mir dann wohl nichts anderes uebrig, als tatsaechlich neu anzufangen.
Kopf hoch, fängst ja nicht wirklich bei Null an ...
-
Nobuo T schrieb:
Ich sollte da wohl noch was klarstellen: ich bin ein DOS-Fan. Ich sitze hier auf einiger alter Hardware und es macht mir Spass, noch was aus den alten Dingern rauszuholen (zB. schon mal versucht, einen mp3-Player zu finden, der vernuenftig auf einem Pentium 100 laeuft?)
Es handelt sich dabei ja auch um ein Hobby-Projekt hauptsaechlich fuer mich selbst. Nur "der Weg ist das Ziel" hat eben irgendwo auch seine Grenzen.ok, dann mach's so: nimm irgendeinen C-compiler, der DOS-exen erzeugen kann (z.b. einen ollen turbo-c oder watcom) und einen x86-assembler (tasm/masm/nasm). dann machste alles, was zeitkritisch ist, bzw. spezielle instructions braucht, die der C-compiler nicht verwendet, in asm und alles andere in C (oder einer anderen sprache). 2 vorteile: du hast volle kontrolle über deine low-level routinen (kein compiler pfuscht dir minderwertigen code rein) und der high-level kram lässt sich komfortaber und schneller entwickeln, als in assembler.