Daelach schrieb am 2. April 2012 16:21
> Bei CAD, FEM usw.
gehts nicht um handelsübliche PCs sondern um Workstations. Warum
flüchten sich die PC-Freaks eigentlich immer in solche
Extrempositionen - keine Argumente bei den üblichen PC-Themen?
So nebenbei - ich kann dir Autos auf der Strasse zeigen, die
per CATIA mit R4000/R6000 gezeichnet wurden. Ja, das ist MIPS,
einer der Konkurrenten von ARM und schon ewig 64-bittig.
64Bit hängen also weder von der Leistung ab, noch von der
Arbeitsgeschwindigkeit - es ist und bleibt eine Frage des
adressierbaren Speichers.
> Nein, kann er nicht. Was er sehr gut kann, das ist beispielsweise
> Videodecodierung, aber der Unterschnitt zwischen Videobearbeitung und
> Videodecodierung ist hoffentlich offensichtlich.
So weit auseinander wie Batchjob und Echtzeit? Beim Abspielen
bedeutet geht nicht ruckeln und beim Batchjob etwas Wartezeit
die niemanden interessiert weil man eh dabei nicht vorm
Rechner sitzt - oder siehst du gerne Vortschrittsbalken zu?
> Und im Fernseher werden Videos eben nicht bearbeitet, sondern
> decodiert. Ein himmelweiter Unterschied.
Und aufzeichnen wäre das was? Und für Videoschnitt gibt's
AFAIK längst Apps.
> Hä? Nein, wollte ich nicht.
Nein, du wolltest nur nachweisen, dass kleine SoCs keine
64Bit haben, weil sie zu schwach sind, mehr als 4GB zu
schaufeln? Schade dass dir da Mips in die Quere gekommen ist.
> Das wird auch mit Neucompilierung und Open Source nicht besser.
Nein, aber damit das man sich nicht an uralten (Betonung liegt
nicht bei binaries sondern auf Uralt) Binaries bindet, sondern
neu entwickelt und z.B. APIs nutzt, über die Parallelisierung
nutzbar wird, z.B. bei iOS das Rendern per GPU.
> Da
> muß sich schon jemand dransetzen und überhaupt eine parellelisierte
> Version erstellen,
Da ist der Knackpunkt und beim x86 macht das so gut wie keiner,
denn die Progger wurde über viele Jahre instruiert, das ja nicht
zu tun, denn Speicher ist ja immer in Massen vorhanden und
Parallelisierung lohnt sich ja nicht denn der nächste GHtz-
Kracher wäre ja schon in der Pipeline. Deshalb auch der grosse
Unterschied zu den Servern, auch Windowsservern. Da rentiert sich
das parallelisieren und ein Server macht ebensowenig die
Lastverteilung vollautomatisch wie ein Decoder.
> Das ist Humbug - ganz im Gegenteil sind Multicores seit Jahren
> Standard
Und ebensolange liest man in den Testberichten, dass so gut
wie keine Desktop-SW darauf optimiert ist ... Gründe, siehe oben.
> Das ist das OS. Kannst Du Dich jetzt mal
> entscheiden, ob Du über das OS sprechen möchtest, über Anwendungen
> oder über Hardware?
Jetzt wäre es an dir zu kapieren, dass es genau um die Kombination
geht...
> Es gibt viele Dinge, wo es weitaus schwieriger ist, als es auf den
> ersten Blick aussieht.
Aber auch nicht so schwierig - ich machs, du acuch?
> Das ist doch sowieso üblich, so Sachen wie Rendering über die GPU zu
> schicken.
Jup, die Linuxdesktops waren hier (wieder mal) Vorreiter, aber
man sieht ja an Android, dass es erst wirklich flutscht, wenn das
Durchgängig gemacht wird - hier hatte zumindest bis Android 4.0
Apple das glücklichere Händchen. Bei den Desktops ists mehr
Effekthascherei, auch bei den Linuxdesktops.
> DVD und CD rippen sind keine Minderheitenthemen, finde ich. Mal eben
> die Startreksammlung auf Platte ziehen beispielsweise.
Minderheiten-und Rentnerthema? :o)
Das mit den DVDs und CDs erledigt sich ja bei der neuesten
PC-Laptopgeneration von selber - die Dinger fliegen hochkant
raus. Bleibt noch die Festplatte als letztes echtes
Unterscheidungsmerkmal zu Mobil-OS.
> Nö, tut sie nicht - denn sie wird gar nicht abgefordert, also
> verpufft sie auch nicht.
Doch, sie verpufft, denn Prozessoren ötteln ja auch, wenn sie
nicht gefordert sind, auch wenn sie auch langsam Sparzustände
lernen - aber immer noch kein Vergleich zu SoCs. Dazu kommt noch
auf fetten Stromverbrauch, daher ineffizient arbeitende
Energieversorgung.
> von laut kann gar keine Rede sein.
Nimm ein Pad in die Hand und horche ;)
Kleines Goddie - kein Staub wird ins Gehäuse gesaugt.
> Ähhhmm.. nein. Wenn dem nämlich so wäre, dann hätte man diese
> desolate Updatesituation nicht,
Du verwechselst ein abstraktes Treiberinterface (das des
Linuxkerns) mit Treiberfummelei durch den Anwender also
das von Windows gewohnte Gefrickle. Das will niemand mehr -
nie wieder!
> Bei CAD, FEM usw.
gehts nicht um handelsübliche PCs sondern um Workstations. Warum
flüchten sich die PC-Freaks eigentlich immer in solche
Extrempositionen - keine Argumente bei den üblichen PC-Themen?
So nebenbei - ich kann dir Autos auf der Strasse zeigen, die
per CATIA mit R4000/R6000 gezeichnet wurden. Ja, das ist MIPS,
einer der Konkurrenten von ARM und schon ewig 64-bittig.
64Bit hängen also weder von der Leistung ab, noch von der
Arbeitsgeschwindigkeit - es ist und bleibt eine Frage des
adressierbaren Speichers.
> Nein, kann er nicht. Was er sehr gut kann, das ist beispielsweise
> Videodecodierung, aber der Unterschnitt zwischen Videobearbeitung und
> Videodecodierung ist hoffentlich offensichtlich.
So weit auseinander wie Batchjob und Echtzeit? Beim Abspielen
bedeutet geht nicht ruckeln und beim Batchjob etwas Wartezeit
die niemanden interessiert weil man eh dabei nicht vorm
Rechner sitzt - oder siehst du gerne Vortschrittsbalken zu?
> Und im Fernseher werden Videos eben nicht bearbeitet, sondern
> decodiert. Ein himmelweiter Unterschied.
Und aufzeichnen wäre das was? Und für Videoschnitt gibt's
AFAIK längst Apps.
> Hä? Nein, wollte ich nicht.
Nein, du wolltest nur nachweisen, dass kleine SoCs keine
64Bit haben, weil sie zu schwach sind, mehr als 4GB zu
schaufeln? Schade dass dir da Mips in die Quere gekommen ist.
> Das wird auch mit Neucompilierung und Open Source nicht besser.
Nein, aber damit das man sich nicht an uralten (Betonung liegt
nicht bei binaries sondern auf Uralt) Binaries bindet, sondern
neu entwickelt und z.B. APIs nutzt, über die Parallelisierung
nutzbar wird, z.B. bei iOS das Rendern per GPU.
> Da
> muß sich schon jemand dransetzen und überhaupt eine parellelisierte
> Version erstellen,
Da ist der Knackpunkt und beim x86 macht das so gut wie keiner,
denn die Progger wurde über viele Jahre instruiert, das ja nicht
zu tun, denn Speicher ist ja immer in Massen vorhanden und
Parallelisierung lohnt sich ja nicht denn der nächste GHtz-
Kracher wäre ja schon in der Pipeline. Deshalb auch der grosse
Unterschied zu den Servern, auch Windowsservern. Da rentiert sich
das parallelisieren und ein Server macht ebensowenig die
Lastverteilung vollautomatisch wie ein Decoder.
> Das ist Humbug - ganz im Gegenteil sind Multicores seit Jahren
> Standard
Und ebensolange liest man in den Testberichten, dass so gut
wie keine Desktop-SW darauf optimiert ist ... Gründe, siehe oben.
> Das ist das OS. Kannst Du Dich jetzt mal
> entscheiden, ob Du über das OS sprechen möchtest, über Anwendungen
> oder über Hardware?
Jetzt wäre es an dir zu kapieren, dass es genau um die Kombination
geht...
> Es gibt viele Dinge, wo es weitaus schwieriger ist, als es auf den
> ersten Blick aussieht.
Aber auch nicht so schwierig - ich machs, du acuch?
> Das ist doch sowieso üblich, so Sachen wie Rendering über die GPU zu
> schicken.
Jup, die Linuxdesktops waren hier (wieder mal) Vorreiter, aber
man sieht ja an Android, dass es erst wirklich flutscht, wenn das
Durchgängig gemacht wird - hier hatte zumindest bis Android 4.0
Apple das glücklichere Händchen. Bei den Desktops ists mehr
Effekthascherei, auch bei den Linuxdesktops.
> DVD und CD rippen sind keine Minderheitenthemen, finde ich. Mal eben
> die Startreksammlung auf Platte ziehen beispielsweise.
Minderheiten-und Rentnerthema? :o)
Das mit den DVDs und CDs erledigt sich ja bei der neuesten
PC-Laptopgeneration von selber - die Dinger fliegen hochkant
raus. Bleibt noch die Festplatte als letztes echtes
Unterscheidungsmerkmal zu Mobil-OS.
> Nö, tut sie nicht - denn sie wird gar nicht abgefordert, also
> verpufft sie auch nicht.
Doch, sie verpufft, denn Prozessoren ötteln ja auch, wenn sie
nicht gefordert sind, auch wenn sie auch langsam Sparzustände
lernen - aber immer noch kein Vergleich zu SoCs. Dazu kommt noch
auf fetten Stromverbrauch, daher ineffizient arbeitende
Energieversorgung.
> von laut kann gar keine Rede sein.
Nimm ein Pad in die Hand und horche ;)
Kleines Goddie - kein Staub wird ins Gehäuse gesaugt.
> Ähhhmm.. nein. Wenn dem nämlich so wäre, dann hätte man diese
> desolate Updatesituation nicht,
Du verwechselst ein abstraktes Treiberinterface (das des
Linuxkerns) mit Treiberfummelei durch den Anwender also
das von Windows gewohnte Gefrickle. Das will niemand mehr -
nie wieder!