Eine Atari ST 800 gab es nicht.
Da habe ich mich vertan, meine den Atari 800 XL. Erst die Tage gelesen und doch falsch geschrieben, ich Nasenbär. ^^
PREISUPDATE ->ATARI 800XL inkl. Zubehör<-
Da könnte man direkt zuschlagen und ein Bastel-Nostalgie-Wochenende starten. ^^
Ich hatte nur ein Kassettenlaufwerk, während Freunde schon einen C64 mit Diskettenlaufwerk hatten, da war ich richtig neidisch.
Der 2990WX hat 4 Speicherkanäle, zwei davon gehen an DIE 0, und die anderen zwei an DIE 2. Hat ein Speicherkanal nur Zugriff auf bestimmte Steckplätze? Speicherkanal 0 kann nur auf Steckplatz 0 und 1 zugreifen, Speicherkanal 1 nur auf Steckplatz 2 und 3, usw.. Wenn jetzt DIE 0 auf Steckplatz 4 zugreifen möchte, muss dies dann über DIE 2 erfolgen?
Ja, so ist es ja fest auf verdrahtet.
Ja mit all den Nachteilen bzgl. der Latenz.
Also ist das, um das nochmal "abschließend" zusammenzufassen, die Hauptursache für die teils schlechte Performance von einigen Programmen. Die notwendige Cache-Kohärenz kann das dann noch verschärfen, wenn zwei Threads auf unterschiedlichen DIEs in einem bestimmten Zeitraum die gleichen Daten/Speicherbereiche nutzt. Das Abgleichen und Aktualisieren der Daten in den Caches zur Erhaltung der Kohärenz kostet erneut Zeit/Performance, und wenn Cache und Speicher auf unterschiedlichen DIEs sitzen, hat man wieder höhere Latenzen.
Im Umkehrschluss wäre es also erforderlich, um die optimale Performance zu erreichen, den Thread auf dem DIE laufen zu lassen, an dem auch der Speicher "angeschlossen" ist, mit dem der Thread arbeitet. Ausgenommen davon wären Threads, bzw. wäre es dort nicht so "schlimm", welche viel im Cache arbeiten (wenig Cache misses?) und nur selten auf den Arbeitsspeicher zugreifen müssen.
Ich sehe da noch Hoffnung, das Microsoft/AMD das irgendwie "verbessert". Gerade ein wenig im Netz gesucht, und es scheint eine Möglichkeit zu geben, herauszufinden, wie viele Cache misses ein Thread hat (Windows und Linux). Ob man feststellen kann, wo welcher Speicher gerade wirklich physikalisch liegt, muss ich noch gucken, für Microsoft/AMD wird das aber sicher möglich sein.
Dann ist die Welt wohl ein riesen Puff!
Ich kenne niemanden, der beruflich nur Sachen machen muss, die er mag, bzw. gut findet, vor allem nicht in der IT. Meistens muss man doch irgendeinen "Blödsinn" umsetzen, weil die Person, die darüber zu entscheiden hat, was wann wo und wie gemacht wird, selten wirklich Ahnung hat. Oder es fehlt Geld und man ist gezwungen mit irgendwelchen Altlasten neue Probleme zu lösen. Das kann Spaß machen, klar, aber irgendwann kann es auch nerven.
Warum sollten diese Leute irgendwelche Hypes mitgemacht haben, weil sie zu der Zeit 23 waren?
Was hat das mit einem Hype zutun? Java z.B. nutzt man nicht wegen eines Hypes, sondern weil es zahlreiche Vorteile bietet und es sehr viele Bereiche gibt, wo die Nachteile (Performance) unwichtig, bzw. vernachlässigbar sind. Immer eine Frage von Kosten und Nutzen.
@flxmmr
ASM skaliert nicht. Quasi prinzipbedingt
Wie ist das gemeint? Skaliert womit nicht? Takt, Multithreading, ... ?
Aber man kann sich damit so manche subroutine ums Vielfache beschleunigen. Auch in profiling Zeiten der C-Compiler.
Das bezweifelt auch keiner. Kein Compiler ist perfekt. Aber auch hier muss man immer gucken, ob es sich lohnt, selber Hand anzulegen und den Teil selber in Assembler zu implementieren.
Das ASM galt weniger ASM, als dem Typus des Programmierers, der sowas auch drauf hat. Diese Leute lassen sich eben viel schwieriger prostituieren.
Wie ich schon zuvor sagte, sehe ich absolut keinen Vorteil, wenn ich als Entwickler, der nicht mit Assembler arbeitet, Assembler kenne. Es mag Ausnahmen geben, ja, aber das wird sehr selten der Fall sein.
Sie finden sehr gute Jobs, schnell. Auch wenn sie da kein Asm machen müßen. Ist halt eine andere Generation
Asm hin oder her.
Da habe ich jetzt keine Erfahrungen gemacht, aber ich kann mir nur schwer vorstellen, dass die Kenntnis über Assembler z.B. einem C#-Entwickler dabei hilft, schneller einen Job zu finden. Würde ich jetzt einen C#-Entwickler suchen, wäre es mir fast egal, ob der Assembler kann oder nicht.
Du glorifizierst Assembler, bzw. die Personen, die Assembler beherrschen. Als ob man gleich ein cooler Typ sei, wenn man Assembler programmieren kann. Finde ich seltsam. Die Kunst eines Programmierer ist es, eine Anforderungen so gut wie möglich zu erfüllen, am besten sauber, wartungsfreundlich, wiederverwendbar und wenn möglich/nötig performant. Jemand der komplizierte Anforderungen/Funktionen verstehen und programmieren kann, ist ein "cooler" Typ. Assembler kann jeder "Schimpanse" lernen. Es entscheidet nicht die Programmiersprache, sondern das, was man damit macht. Ein Tischler ist ja auch nicht gut, weil er ein bestimmtes Werkzeug besitzt, bzw. damit umgehen kann, sondern weil er z.B. robuste, praktische und/oder schöne Möbel bauen kann.
Deine Einstellung erinnert mich teilweise an meine Einstellung, die ich vor über 10 Jahren hatte, wo ich noch dachte, C/C++ ist das einzig Wahre und alles andere ist Kinderkram. Java, lol, die haben nicht mal richtige Pointer und nen Müllsammler (garbage collector), was für Idioten! Können nicht mal vernünftig ihre Ressourcen verwalten, was für Trottel. Tja, der wahre Trottel war aber ich, der aus irgendwelchen hirnverbrannten Gründen dachte, man ist geil, wenn man C/C++ programmiert. Heute erscheint mir das so absurd. Aber so ist das halt, man lernt ständig und das was man gestern gemacht hat, bzw. wie man es gemacht hat, findet man morgen schon schlecht, weil man wieder was Neues gelernt hat.
ich habe dich nie als Fanboy bezeichnet. Ich vermute aber, dass eben an manchen Stellen eine Schraube locker sein könnte.
