osmler schrieb am 2. April 2012 15:34
> > Darunter fallen Audiodaten, Videodaten, Bilddaten, CAD-Daten, oder
> > beim Schach auch Hashtabellen.
>
> Wobei jetzt nach wie vor im Dunkeln bleibt, warum das jetzt
> ein Thema des linearen Addressraums ist. Diese Daten sind auch
> problemlos von jedem 32-Bitter zu bewältigen.
Kommt drauf an wieviel. Bei CAD, FEM usw. kann man beliebig fein
auflösen und damit die Datenmenge beliebig hoch treiben. Auch auf
über 4GB. Videodaten in FullHD sind je nach Filmlänge auch nicht ganz
wenig. Selbst bei Audio kriegt man das durchaus hin, indem man mit
192kHz und 32bit float und diversen Spuren mastert. Das sind aber
alles Anwendungen, die einiges auch an CPU-Kraft brauchen, die ein
ARM sowieso nicht hat, so daß es vollkommen sinnfrei wäre, mit so
einer lahmen CPU etwas in 64bit zu machen, was man nicht genausogut
auch in 32bit machen könnte.
> Ein ARM kann Videodaten, Bilddaten, Audiodaten und Hashtabellen
> nicht bearbeiten?
Nein, kann er nicht. Was er sehr gut kann, das ist beispielsweise
Videodecodierung, aber der Unterschnitt zwischen Videobearbeitung und
Videodecodierung ist hoffentlich offensichtlich.
> Der Atom ist ziemlich mies darin, aber
> ARMs mit ein wenig Zusatz-IP im Core leisten heute die
> Hauptarbeit auf diesem Feld. In jedem besseren Fernseher ist
> so ein Ding.
Und im Fernseher werden Videos eben nicht bearbeitet, sondern
decodiert. Ein himmelweiter Unterschied.
> Aber irgendwann wolltest du doch noch damit herausrücken,
> wie 64Bit das System/Rechenwerk beschleunigen :o)
Hä? Nein, wollte ich nicht. Das ist zwar bei x86 zum Teil der Fall,
aber nicht wegen 64bit, sondern weil man mit x86-64 mehr Register zur
Verfügung hat. Das ist aber kein Feature von 64bit, sondern eine
Schwäche von x86-32, die andere Architekturen gar nicht erst haben,
so daß letztere von 64bit nur begrenzt geschwindigkeitsmäßig
profitieren würden. Beispielsweise bei Schachprogrammen, sofern sie
mit Bitfeldern arbeiten (was auch nicht alle tun).
> Um was? Nö, du bist immer noch auf dem Holzweg. Es geht nicht
> um GPL & Co. Es geht darum, warum Uraltbinaries nicht für
> Paralelisierung und effiziente Ausführung auf modernen
> Systemen taugen.
Das wird auch mit Neucompilierung und Open Source nicht besser. Da
muß sich schon jemand dransetzen und überhaupt eine parellelisierte
Version erstellen, und das ist nicht unbedingt trivial, wenn nicht
die Aufgabenstellung (wie etwa Webserver) einem das regelrecht
aufnötigt.
> Es geht immer noch darin, warum x86-Maschinen
> einseitig auf SingleThread ausgelegt werden und entsprechend
> ins Schwitzen kommen.
Das ist Humbug - ganz im Gegenteil sind Multicores seit Jahren
Standard bei x86. Die Software ist eher das Problem, und da nannte
ich bereits gute Gründe, wieso die bei Singlethread bleiben. Und
nein, der Grund ist nicht die Wintelverschwörung aus Bielefeld.
> > *facepalm* um es durch Parallelverarbeitung zu lösen, muß es zuvor
> > erstmal parallelisiert worden sein.
>
> Exakt, und damit hat Apple das Problem der Reaktivität
> bei seinem Touch-OS gelöst.
*nochmal facepalm* Das ist das OS. Kannst Du Dich jetzt mal
entscheiden, ob Du über das OS sprechen möchtest, über Anwendungen
oder über Hardware? Deine diffuse Wintelabneigung grenzt hier langsam
an Trollerei, sorry.
Nebenbei bemerkt, ICH habe mit Win7 KEINE Reaktivitätsprobleme. Hatte
ich aber mit KDE3 auch nicht.
> Es gibt nur sehr wenige Dinge, die sich nicht massiv
> parallelisieren lassen, das aber nur so nebenbei.
Es gibt viele Dinge, wo es weitaus schwieriger ist, als es auf den
ersten Blick aussieht. Und wo der Speedup auch nicht so traumhaft
ist. Es ist im allgemeinen IMMER besser, eine gegebene Rechenleistung
mit möglichst wenig Kernen zur Verfügung zu stellen, weil man dann
insgesamt wegen fallenden Speedsups bei mehr Kernen schneller
arbeiten kann. Das ist der Grund, wieso Singlethreadperformance auch
künftig wichtig sein wird. AMD hat sich genau deswegen mit dem Bulli
auf dem Desktop eine Klatsche eingefangen - was auch nicht anders zu
erwarten war.
> Was es dazu braucht ist eine Handvoll gesunder Pragmatismus
> und etwas Offenheit. Z.B. geht man ein wenig weg von der
> absuluten Universalmaschine und verbaut für die Videobearbeitung
> ein wenig HW.
Das ist doch sowieso üblich, so Sachen wie Rendering über die GPU zu
schicken.
> Hat Intel bei den Atoms verpennt und deshalb
> schlägt jeder mittelmässige ARM den Atom solange der keine
> HW-Erweiterung hat.
Braucht man bei den Atoms auch nicht. Videobearbeitung mit so ner
lahmen Gurke.. ich würd das K*tzen kriegen und mir gleich nen
Core-i-irgendwas hinstellen.
> Dann miss mal knallhart was die meisten Anwender mit ihren
> Geräten machen.
Klar, für MP3 hören und Facebook braucht man keine schnellen Rechner.
Daß die Leute sie sich dennoch kaufen, kannste nicht x86 vorwerfen.
> Man kann immer ein paar Anwendungen finden,
> die jede Brachialmaschine auslasten, aber das sind
> Minderheitenthemen.
DVD und CD rippen sind keine Minderheitenthemen, finde ich. Mal eben
die Startreksammlung auf Platte ziehen beispielsweise.
> Verpuffen tut die Rechenleistung hingegen in Lieschen Müllers
> PC
Nö, tut sie nicht - denn sie wird gar nicht abgefordert, also
verpufft sie auch nicht.
> und das auch nöch mit lästiger Geräuschkulisse.
Also mein 1100T ist nun wahrlich kein Stromsparwunder, AMD halt, aber
von laut kann gar keine Rede sein. Man könnte allerdings durch mehr
Abschaltung nicht benötigter Einheiten den Idleverbrauch noch
drücken, das wäre ganz nett.
> > iOS kann auch nur einen Task im Vordergrund, und genau das konnte TOS
> > schon ab Werk.
>
> Dass du den Unterschied nicht begreifst wundert mich jetzt
> auch nicht wirklich.
Naja, D uschreibst da einfach zusammenhangsloses Zeug, dessen einzige
Aussage ist "Wintel mag ich nicht". Fundiert sieht anders aus.
> UNIXoiden OS mitbringt. Zudem sei auf Android verwiesen, das
> diese auch mitbringt.
Ähhhmm.. nein. Wenn dem nämlich so wäre, dann hätte man diese
desolate Updatesituation nicht, weil dann die Hardwarehersteller wie
bei Windows sich einfahc um ihre Schicht kümmern würden, man könnte
Android direkt von Google ziehen (so wie Windowsupdates von MS) und
gut. Stattdessen gibt Google ein Androidupdate raus, und die
Hardwarehersteller fangen an, damit herumzufummeln und es auf die
Geräte zu portieren. Das sieht mir nicht nach Abstraktion aus!
Hier macht MS das wesentlich besser. Allein die Vorstellung, der
Hersteller meines Netbooks müßte bei Windowsupdates noch irgendwas
rumfummeln und ich wäre auf dessen Gnade angewiesen.. *LOL*. Geht gar
nicht.
> Dass diese Abstraktionen etwas besser und moderner gestaltet
> sind, versteht sich von selber, denn immerhin will keiner mehr
> die Anwender mit 'bitte legen sie die Treiber-CD ein' nerven.
Wenns Abstraktionen WÄREN, dann könnte man sich mit jedem
Androidhandy die Updates direkt bei Google ziehen! Sinds aber nicht.
Selber Zustand wie in den 80ern halt. Was Du hier als Innovation
abfeierst, betrachte ich als Rückschritt um 25 Jahre. In DER Hinsicht
ist Windows tatsächlich deutlich weiter.
> > Darunter fallen Audiodaten, Videodaten, Bilddaten, CAD-Daten, oder
> > beim Schach auch Hashtabellen.
>
> Wobei jetzt nach wie vor im Dunkeln bleibt, warum das jetzt
> ein Thema des linearen Addressraums ist. Diese Daten sind auch
> problemlos von jedem 32-Bitter zu bewältigen.
Kommt drauf an wieviel. Bei CAD, FEM usw. kann man beliebig fein
auflösen und damit die Datenmenge beliebig hoch treiben. Auch auf
über 4GB. Videodaten in FullHD sind je nach Filmlänge auch nicht ganz
wenig. Selbst bei Audio kriegt man das durchaus hin, indem man mit
192kHz und 32bit float und diversen Spuren mastert. Das sind aber
alles Anwendungen, die einiges auch an CPU-Kraft brauchen, die ein
ARM sowieso nicht hat, so daß es vollkommen sinnfrei wäre, mit so
einer lahmen CPU etwas in 64bit zu machen, was man nicht genausogut
auch in 32bit machen könnte.
> Ein ARM kann Videodaten, Bilddaten, Audiodaten und Hashtabellen
> nicht bearbeiten?
Nein, kann er nicht. Was er sehr gut kann, das ist beispielsweise
Videodecodierung, aber der Unterschnitt zwischen Videobearbeitung und
Videodecodierung ist hoffentlich offensichtlich.
> Der Atom ist ziemlich mies darin, aber
> ARMs mit ein wenig Zusatz-IP im Core leisten heute die
> Hauptarbeit auf diesem Feld. In jedem besseren Fernseher ist
> so ein Ding.
Und im Fernseher werden Videos eben nicht bearbeitet, sondern
decodiert. Ein himmelweiter Unterschied.
> Aber irgendwann wolltest du doch noch damit herausrücken,
> wie 64Bit das System/Rechenwerk beschleunigen :o)
Hä? Nein, wollte ich nicht. Das ist zwar bei x86 zum Teil der Fall,
aber nicht wegen 64bit, sondern weil man mit x86-64 mehr Register zur
Verfügung hat. Das ist aber kein Feature von 64bit, sondern eine
Schwäche von x86-32, die andere Architekturen gar nicht erst haben,
so daß letztere von 64bit nur begrenzt geschwindigkeitsmäßig
profitieren würden. Beispielsweise bei Schachprogrammen, sofern sie
mit Bitfeldern arbeiten (was auch nicht alle tun).
> Um was? Nö, du bist immer noch auf dem Holzweg. Es geht nicht
> um GPL & Co. Es geht darum, warum Uraltbinaries nicht für
> Paralelisierung und effiziente Ausführung auf modernen
> Systemen taugen.
Das wird auch mit Neucompilierung und Open Source nicht besser. Da
muß sich schon jemand dransetzen und überhaupt eine parellelisierte
Version erstellen, und das ist nicht unbedingt trivial, wenn nicht
die Aufgabenstellung (wie etwa Webserver) einem das regelrecht
aufnötigt.
> Es geht immer noch darin, warum x86-Maschinen
> einseitig auf SingleThread ausgelegt werden und entsprechend
> ins Schwitzen kommen.
Das ist Humbug - ganz im Gegenteil sind Multicores seit Jahren
Standard bei x86. Die Software ist eher das Problem, und da nannte
ich bereits gute Gründe, wieso die bei Singlethread bleiben. Und
nein, der Grund ist nicht die Wintelverschwörung aus Bielefeld.
> > *facepalm* um es durch Parallelverarbeitung zu lösen, muß es zuvor
> > erstmal parallelisiert worden sein.
>
> Exakt, und damit hat Apple das Problem der Reaktivität
> bei seinem Touch-OS gelöst.
*nochmal facepalm* Das ist das OS. Kannst Du Dich jetzt mal
entscheiden, ob Du über das OS sprechen möchtest, über Anwendungen
oder über Hardware? Deine diffuse Wintelabneigung grenzt hier langsam
an Trollerei, sorry.
Nebenbei bemerkt, ICH habe mit Win7 KEINE Reaktivitätsprobleme. Hatte
ich aber mit KDE3 auch nicht.
> Es gibt nur sehr wenige Dinge, die sich nicht massiv
> parallelisieren lassen, das aber nur so nebenbei.
Es gibt viele Dinge, wo es weitaus schwieriger ist, als es auf den
ersten Blick aussieht. Und wo der Speedup auch nicht so traumhaft
ist. Es ist im allgemeinen IMMER besser, eine gegebene Rechenleistung
mit möglichst wenig Kernen zur Verfügung zu stellen, weil man dann
insgesamt wegen fallenden Speedsups bei mehr Kernen schneller
arbeiten kann. Das ist der Grund, wieso Singlethreadperformance auch
künftig wichtig sein wird. AMD hat sich genau deswegen mit dem Bulli
auf dem Desktop eine Klatsche eingefangen - was auch nicht anders zu
erwarten war.
> Was es dazu braucht ist eine Handvoll gesunder Pragmatismus
> und etwas Offenheit. Z.B. geht man ein wenig weg von der
> absuluten Universalmaschine und verbaut für die Videobearbeitung
> ein wenig HW.
Das ist doch sowieso üblich, so Sachen wie Rendering über die GPU zu
schicken.
> Hat Intel bei den Atoms verpennt und deshalb
> schlägt jeder mittelmässige ARM den Atom solange der keine
> HW-Erweiterung hat.
Braucht man bei den Atoms auch nicht. Videobearbeitung mit so ner
lahmen Gurke.. ich würd das K*tzen kriegen und mir gleich nen
Core-i-irgendwas hinstellen.
> Dann miss mal knallhart was die meisten Anwender mit ihren
> Geräten machen.
Klar, für MP3 hören und Facebook braucht man keine schnellen Rechner.
Daß die Leute sie sich dennoch kaufen, kannste nicht x86 vorwerfen.
> Man kann immer ein paar Anwendungen finden,
> die jede Brachialmaschine auslasten, aber das sind
> Minderheitenthemen.
DVD und CD rippen sind keine Minderheitenthemen, finde ich. Mal eben
die Startreksammlung auf Platte ziehen beispielsweise.
> Verpuffen tut die Rechenleistung hingegen in Lieschen Müllers
> PC
Nö, tut sie nicht - denn sie wird gar nicht abgefordert, also
verpufft sie auch nicht.
> und das auch nöch mit lästiger Geräuschkulisse.
Also mein 1100T ist nun wahrlich kein Stromsparwunder, AMD halt, aber
von laut kann gar keine Rede sein. Man könnte allerdings durch mehr
Abschaltung nicht benötigter Einheiten den Idleverbrauch noch
drücken, das wäre ganz nett.
> > iOS kann auch nur einen Task im Vordergrund, und genau das konnte TOS
> > schon ab Werk.
>
> Dass du den Unterschied nicht begreifst wundert mich jetzt
> auch nicht wirklich.
Naja, D uschreibst da einfach zusammenhangsloses Zeug, dessen einzige
Aussage ist "Wintel mag ich nicht". Fundiert sieht anders aus.
> UNIXoiden OS mitbringt. Zudem sei auf Android verwiesen, das
> diese auch mitbringt.
Ähhhmm.. nein. Wenn dem nämlich so wäre, dann hätte man diese
desolate Updatesituation nicht, weil dann die Hardwarehersteller wie
bei Windows sich einfahc um ihre Schicht kümmern würden, man könnte
Android direkt von Google ziehen (so wie Windowsupdates von MS) und
gut. Stattdessen gibt Google ein Androidupdate raus, und die
Hardwarehersteller fangen an, damit herumzufummeln und es auf die
Geräte zu portieren. Das sieht mir nicht nach Abstraktion aus!
Hier macht MS das wesentlich besser. Allein die Vorstellung, der
Hersteller meines Netbooks müßte bei Windowsupdates noch irgendwas
rumfummeln und ich wäre auf dessen Gnade angewiesen.. *LOL*. Geht gar
nicht.
> Dass diese Abstraktionen etwas besser und moderner gestaltet
> sind, versteht sich von selber, denn immerhin will keiner mehr
> die Anwender mit 'bitte legen sie die Treiber-CD ein' nerven.
Wenns Abstraktionen WÄREN, dann könnte man sich mit jedem
Androidhandy die Updates direkt bei Google ziehen! Sinds aber nicht.
Selber Zustand wie in den 80ern halt. Was Du hier als Innovation
abfeierst, betrachte ich als Rückschritt um 25 Jahre. In DER Hinsicht
ist Windows tatsächlich deutlich weiter.