Tablets: welche CPU-Architektur macht hier das Rennen: ARM, Atom, Fusion oder kommt es ganz anders?

BavarianRealist

Grand Admiral Special
Mitglied seit
06.02.2010
Beiträge
3.358
Renomée
80
Das iPad als auch sonstige Tablets basieren offenbar vor allem auf ARM. Braucht man überhaupt x86 in den Tablets? Wer will Windows auf Tablets? Könnten Tablets ARM und Android groß machen?

Welche Chance haben hier x86-Architekturen wie Fusion und Atom?

Sehe ich mir das iPad an, frage ich mich, wer würde hier überhaupt ein Windows wollen? Die Tablets dürften vor allem Microsoft Magenschmerzen bereiten, könnten diese doch dazu führen, Windows mehr und mehr aus dem Comsumer-Segment zu verdrängen und durch andere Systeme (Android) zu ersetzen. Braucht man aber kein Windows, braucht es auch keine x86. Wird ARM/Android auf den Tablets groß, könnte das Android/ARM auch in den Smart-Phones bald zu einem neuen Standard verhelfen. Das wird Apple, aber noch weniger MS gefalleln.

Am dümmsten würden hier aber Intel und AMD drein schauen, und der vermeintliche Verlierer Nvidia hätte tatsächlich alles richtig gemacht...erstens kommt es anders und zweitens als man denkt?:]

Vor diesem Hintergrund (als auch die niedrige Vergleichszahlung zwischen Intel und AMD) könnte womöglich ein Streit bei AMD ausgebrochen sein, wer dafür verantwortlich war/ist, dass AMD all seine Mobile-Technologie die letzen Jahre verkauft hat, wofür es wenig Geld gab, und was sich jetzt als der Mega-Fehler herauszustellen scheint...

Die TABLETS: können sie die aktuellen Standards (x86/Windows) ins Wanken bringen?
 
Zuletzt bearbeitet:
Ja, erst der Smartphone-Boom und nun machen Google und Android ARM groß.
Ich brauche an einem Tablet keine x86 CPU, ich möchte mit einem Tablet surfen, Musik hören, Videos schauen und kleine Spiele spielen. Diese Aufgaben kann eine ARM-CPU überwältigen. Tablets sollen leicht sein und eine lange Akkulaufzeit haben (ich bin der Meinung die sollten auch recht robust sein...) weshalb noch zur Zeit nur eine ARM-CPU in Frage kommt, doch ich persönlich brauche dort kein Windows.
In Zukunft wird es wahrscheinlich auch ARM Desktop-Prozessoren geben. Ab dann stelle ich mir schon die Frage, wer macht das Rennen. Wenn das Potenzial im Mobilen Sektor von ARM noch weiter ausgebaut wird, macht im Laufe der Zeit wahrscheinlich auch ARM allein wegen der Kompatibilität her im Desktop-Markt das Rennen.
Ich persönlich möchte einen x86 Prozessor in einem Gerät mit Tastatur - wozu auch Notebooks und Tablet-PCs zählen - in Moment noch nicht missen. Ich bin mit x86, und vor allem in meinem Alter auch mit dem entsprechenden spielen aufgewachsen, die im Laufe der Zeit keine hohe Hardwareanforderungen haben. Andere sehen es auch vielleicht wie ich, andere möchten einfach nicht umlernen und beim alten bleiben. Deshalb ist es in Zukunft sicherlich auch eine Abhängigkeit der kommenden Generation wie stark sich ARM-Prozessoren im Markt etablieren.

Als sich mein Bruder vor 8 Jahren sich sein PDA gekauft hat - ein Acer n10 - wollte ich gern ein ein größeres Gerät mit W-Lan haben um mehr zu konsumieren, also eben ein Tablet doch es hab so etwas nicht bzw. nicht wirklich für den Privaten Sektor und bezahlbar. Deshalb war ich recht interessiert wie sich der Markt rund um ARM entwickelt und ich hatte mir schon gedacht, dass es ein Fehler war, als Intel seine XScale Geschäftssparte und AMD seine Imageon-Sparte verkauft hatte. Doch ich wusste auch nicht, wie sich x86 entwickeln würde, deshalb habe ich mir keine großen Gedanken darüber gemacht.
 
Persönlich erwarte ich mit der Zeit eine Zweispaltung der Betriebssysteme für Business und Consumer. Deren Erwartungen und Anforderungen driften mit steigender Komplexität langsam auseinander. Der Consumer will es easy-to-use, schön bunt und er braucht viele der Anwendungen von Business-Anwendern nicht, die stören oder machen alles nur unnötig unverständlich. Folge: leichter und einfacher.

Der Business-Kunde hat dagegen Anforderungen, die aus Standards entstanden, die sich so im Geschäftsleben etabliert haben, eben all die typischen Business-Anwendungen, die meist nur auf Windows laufen, weshalb auch Linux im klassischen Business-Alltag keine Chance hat (zumnindest nicht auf den Clients).

Zudem sehe ich eine (endlich) kommende Standardisierung von Schnittstellen zwischen Anwendungen entstehen (hoffentlich bin ich da jetzt nicht zu optimistisch...), was ebenfalls die Möglichkeit eröffnet, dass man auf dem einen Gerät (Smartphone, Tablet, Home-Multimedia-Server) eben Android oder Linux und auf anderen (Business-Notebook/Rechner) dann Windows laufen hat und sich beides mit der Zeit einigermaßen (v)erträgt. So eine Entwicklung würde zudem dazu führen, dass bald jeder mehrere solcher ARM/x86-based Geräte daheim hätte: Tablet, Smart-Phone(s), Notebooks (privat,geschäftl.), Home-Server und Desktop-Rechner...
.
EDIT :
.

Auch digitimes heute zu diesem Thema ARM/Android gegen Wintel:

"AMD heading in right direction on ARM but too slow, say Taiwan notebook maker...
...The global CPU market in 2011 will feature two important things: Wintel will no longer be the only platform and will be increasingly replaced by ARM which tends to dominate in tablet PCs... ...Nvidia's Tegra 2 has been widely adopted by vendors for mainstream notebooks expected to be launched in June 2011, the sources pointed out.
These vendors are satisfied at Tegra 2's lower costs and that it allows lighter and slimmer notebooks than Wintel as well as shorter boot times."
 
Persönlich erwarte ich mit der Zeit eine Zweispaltung der Betriebssysteme für Business und Consumer.
Da brauchst du auf nichts warten. Es ist schon Realität.
Schau dir iOS, Android, Blackberry Playbook oder auch Chrome Os an.

Zudem sehe ich eine (endlich) kommende Standardisierung von Schnittstellen zwischen Anwendungen entstehen (hoffentlich bin ich da jetzt nicht zu optimistisch...), was ebenfalls die Möglichkeit eröffnet, dass man auf dem einen Gerät (Smartphone, Tablet, Home-Multimedia-Server) eben Android oder Linux und auf anderen (Business-Notebook/Rechner) dann Windows laufen hat und sich beides mit der Zeit einigermaßen (v)erträgt. So eine Entwicklung würde zudem dazu führen, dass bald jeder mehrere solcher ARM/x86-based Geräte daheim hätte: Tablet, Smart-Phone(s), Notebooks (privat,geschäftl.), Home-Server und Desktop-Rechner...

Das Problem ist schon so alt wie die PC Geschichte.
Ich glaube du verwechselst Standards mit Marktdominanz.
 
Da brauchst du auf nichts warten. Es ist schon Realität.
Schau dir iOS, Android, Blackberry Playbook oder auch Chrome Os an.

So hart wollte ich das jetzt noch nicht formulieren...


Das Problem ist schon so alt wie die PC Geschichte.
Ich glaube du verwechselst Standards mit Marktdominanz.

Ich weiß, dass das ein fettes Problem schon immer ist, wird es doch gerade dazu missbraucht, eine Marktdominanz zu kreieren bzw. zu erhalten, indem man Schnittstellen nicht standardisiert, offenlegt oder gar mit Patenten "dicht" macht.

Andereseits enstehen immer mehr diverse Workaround-Alternativen, von denen mit der Zeit die eine oder andere angenommen werden dürfte, zumal die Komplexität der nötigen Hardware immer weniger das Problem darstellt. So setzt sich dann am Ende oft eine schlechte Schnittstelle durch, weil die besseren Varianten durch Patente geschützt und damit nicht allgemein verfügbar sind.
 
x86 hat im Ultramobilsektor, also in Tablets und Smartphones nichts zu melden.

Bitte, wer will denn ein Tablet oder gar ein Smartphone mit Lüfter? Außer LG traute sich zumindest bei den Smartphones keiner sowas zu fertigen. Bei ARM ist man seit der ersten Boomphase der Geräte erfolgreich dabei, da Preis/Leistung, sowie Performance/Watt immer stimmen. Bei x86 haben wir das Problem, viel architektonischen Ballast mitzuschleppen, den solche Geräte gar nicht brauchen, hier ist es wichtiger die Software anzupassen.

btw: ich finde das Android auch mal ein bissle überholt werden sollte, auch wenn es noch ganz gut ist. Habe aktuell zwei ANdroidgeräte, ein Pulse und ein Desire, und beide kmäpfen ständig mit RAM Mangel und übertüchtigen CPU Gouverneurs. Beides kostet Strom und nervt den User, hier sollte Google noch mal deutlich nachbessern, sonst könnte sogar x86 Fuß fassen, da mehr Rohpower vorhanden ist.
 
Ich glaube im Moment auch eher an ARM aber ein 22nm Atom könnte schon interessant werden.
Die Frage ist für mich aber noch die Software MS bekommt noch nicht viel hin mal sehen was Meego schafft ansonsten wird es Android und IOS.
 
x86 hat im Ultramobilsektor, also in Tablets und Smartphones nichts zu melden.

Bitte, wer will denn ein Tablet oder gar ein Smartphone mit Lüfter? Außer LG traute sich zumindest bei den Smartphones keiner sowas zu fertigen. Bei ARM ist man seit der ersten Boomphase der Geräte erfolgreich dabei, da Preis/Leistung, sowie Performance/Watt immer stimmen. Bei x86 haben wir das Problem, viel architektonischen Ballast mitzuschleppen, den solche Geräte gar nicht brauchen, hier ist es wichtiger die Software anzupassen.

btw: ich finde das Android auch mal ein bissle überholt werden sollte, auch wenn es noch ganz gut ist. Habe aktuell zwei ANdroidgeräte, ein Pulse und ein Desire, und beide kmäpfen ständig mit RAM Mangel und übertüchtigen CPU Gouverneurs. Beides kostet Strom und nervt den User, hier sollte Google noch mal deutlich nachbessern, sonst könnte sogar x86 Fuß fassen, da mehr Rohpower vorhanden ist.

Das scheint mir jetzt ein etwas einfacheres Modell der Smartphone-Welt zu sein. Ein paar Anmerkungen:

- ein Lüfter impliziert einen bestimmten Stromverbrauch, was aber kaum mit einer vernünftigen Nutzungszeit auf Batteriebetrieb korreliert, zumal der Lüfter selbst Strom verbraucht
- x86 muss nicht zwangsweise einen hohen Verbrauch haben
- Ontario C-50 mit 9W TDP (inkl, GPU u. IO) hat 2x 1.0 GHz x86-Cores (ca. 1-2W jeweils)
- Bobcat Cores haben viele Features, die für einen Mobileinsatz nutzfallabhängig reduziert werden können (architektonischer Ballast), wie:
- 64 Bit
- physikalischer Adressbereich
- Virtualisierung
- SIMD-Erweiterungen
- das Decoding von x86-Befehlen (eine der Hauptlasten der ISA) kann als Trade-Off zwischen direktem Decoding u. Microcode umgesetzt werden
- die CPU hat bei den Smartphones offenbar nur einen kleinen Anteil am Gesamtverbrauch, da selbst bei meinem Galaxy S das eigentlich sparsame Super-AMOLED-Display in meist abgedunkelter Stufe die Verbrauchsübersicht mit 90-97% anführt


Bei Android stehen doch sowohl 2.3 als auch 3.0 mit performanterem Filesystem u. anderen Neuerungen an. Und so etwas wie die Dalvik VM kann auch noch verbessert werden. Das Galaxy S hat 512 MB RAM, was meist noch Platz bietet, aber natürlich auch einen Trade-Off aus User Experience und Stromverbrauch (RAM muss refreshed werden) darstellt.
 
Wenn AMD mit Ontarion kaum Stiche bei den Tablets macht, steht anscheinend AMD auch nicht schlechter da als Intels Atom:

"Intels „Oak Trail“ entwickelt sich zum Flop...
...Die als „Tablet-CPU“ gepriesene „Oak Trail“-Plattform entwickelt sich zu einem Ladenhüter... ...So soll bislang außer Fujitsu, Samsung und Toshiba niemand an Tablets mit Intels neuer Plattform arbeiten, zudem würden alle drei Hersteller wenig Interesse an hohen Stückzahlen haben..."

(aus computerbase)

Hier macht wohl doch ARM/Android das Rennen....und damit auch Nvidia :]
 
Hier werden doch einige Oak-Trail Tablets genannt:

http://www.engadget.com/features/tablets-at-ces-2011/

Klar sind es noch nicht viel, aber die Oak Trails werden ja auch erst ab März ausgeliefert.
Bei der Cebit könnte es da nochmals mehr Geräte zu sehen geben.

Dann noch zu windows 8 - und wie will man den leuten sinnvoll erklären ,dass auf manchen tablets alte exes laufen und auf anderen nicht *noahnung*
 
ein Lüfter impliziert einen bestimmten Stromverbrauch, was aber kaum mit einer vernünftigen Nutzungszeit auf Batteriebetrieb korreliert, zumal der Lüfter selbst Strom verbraucht -x86 muss nicht zwangsweise einen hohen Verbrauch haben -Ontario C-50 mit 9W TDP (inkl, GPU u. IO) hat 2x 1.0 GHz x86-Cores (ca. 1-2W jeweils) -Bobcat Cores haben viele Features, die für einen Mobileinsatz nutzfallabhängig reduziert werden können (architektonischer Ballast), wie: -64 Bit -physikalischer Adressbereich -Virtualisierung -SIMD-Erweiterungen -das Decoding von x86-Befehlen

Ok, war vielleicht ein bisschen überspitzt formuliert, aber die Vorteile von 64 Bit und erweitertem Speicher bei einem Tablet musst du mir erklären, für mich macht das absolut null Sinn.
Zum Lüfter: dem empfinden dir meisten Menschen einfach mit als laut, egal ob das Gerät mit Lüfter besser läuft als das ohne, Hauptsache leise.

Dein Ontario Vergleich hinkt etwas: Es ist egal wie viel die einzelnen Kernel verbrauchen, wichtig ist der Gesamtverbrauch, und der liegt bei x86 höher als bei ARM. ich meine mal gelesen zu haben, das ein ganzes 1Ghz Singlecore SoC samt allen Dingen wie IO, Grafik etc nicht mehr als einen Watt verbraucht, da rangiert die Ontario APU weit höher.

Bei meinem Desire frisst der Screen etwa 65% des verbrauchten Stroms, warum also noch weniger Laufzeit für Leistung die ich nicht brauche? Softwareoptinierung seitens ARM dürfte die Sache vereinfachen, aber auch die Hersteller sind nicht unschuldig.

@ Tom
Saß sehr ich genauso. Steht das gleiche drauf, muss also auch das gleiche drauf laufen...
 
MS vebietet denen Hersteller die keine ARM kompatiblen Programme anbieten damit zu werben, das sie auch auf dem "Windows 8" laufen.
 
Bei Ontario müßte man auch noch den Hudson Hub hinzurechnen mit ~ 4 Watt. Vielleicht auch nur 2 Watt nach Abschalten aller nicht benötigter I/O Komponenten. Aber selbst das wär schon zuviel. Der ist in 65 nm gefertigt, viel zu groß und wenn er auf den Markt kommt schon veraltet für moderne Mobile Technik.
Oak-Trail ist zu schwach und benötigt zu viel Saft. Die Konkurrenz wird man an anderer Stelle suchen müssen.
Auf der alteingesessenen Seite (Intel/AMD) hat man leider nichts besseres zu tun, um notfalls auch mit Geld, solch innovativen Firmen (hier Nvidia) von deren Plattform zu vertreiben. Wenn jetzt der Tablet Boom kommen sollte, dann werden "die Alten" nochmals zahlen müssen. (Umsatzeinbrüche o. entgangener Gewinn)
 
Ok, war vielleicht ein bisschen überspitzt formuliert, aber die Vorteile von 64 Bit und erweitertem Speicher bei einem Tablet musst du mir erklären, für mich macht das absolut null Sinn.

Ich glaube du hast den Post nicht richtig gelesen. Dresdenboy sagte, man könnte all diese Features für ein Tablet entfernen.
 
Das scheint mir jetzt ein etwas einfacheres Modell der Smartphone-Welt zu sein. Ein paar Anmerkungen:

- ein Lüfter impliziert einen bestimmten Stromverbrauch, was aber kaum mit einer vernünftigen Nutzungszeit auf Batteriebetrieb korreliert, zumal der Lüfter selbst Strom verbraucht
- x86 muss nicht zwangsweise einen hohen Verbrauch haben
- Ontario C-50 mit 9W TDP (inkl, GPU u. IO) hat 2x 1.0 GHz x86-Cores (ca. 1-2W jeweils)
- Bobcat Cores haben viele Features, die für einen Mobileinsatz nutzfallabhängig reduziert werden können (architektonischer Ballast), wie:
- 64 Bit
- physikalischer Adressbereich
- Virtualisierung
- SIMD-Erweiterungen
- das Decoding von x86-Befehlen (eine der Hauptlasten der ISA) kann als Trade-Off zwischen direktem Decoding u. Microcode umgesetzt werden
- die CPU hat bei den Smartphones offenbar nur einen kleinen Anteil am Gesamtverbrauch, da selbst bei meinem Galaxy S das eigentlich sparsame Super-AMOLED-Display in meist abgedunkelter Stufe die Verbrauchsübersicht mit 90-97% anführt


Bei Android stehen doch sowohl 2.3 als auch 3.0 mit performanterem Filesystem u. anderen Neuerungen an. Und so etwas wie die Dalvik VM kann auch noch verbessert werden. Das Galaxy S hat 512 MB RAM, was meist noch Platz bietet, aber natürlich auch einen Trade-Off aus User Experience und Stromverbrauch (RAM muss refreshed werden) darstellt.


Es hängt so viel gar nicht am Kern(CPU-Core), sondern am drumherum.

Z. B. Ein Intel Atom Z600 und Intel Atom N270 sind beide in 45nm gefertigt haben beide den selben kern, haben aber ganz andere Chipsätze. Oak Trail und Moorestown sind aufgrund deren Chipsätze sehr viel sparsamer. Am ehesten sieht man das in diesen Slides:

Schaut euch die beiden Bilder mal gemeinsam an:
Aktive Units Menlow-Plattform und Moorestown-Plattform in Idle:
http://www.computerbase.de/bildstrecke/25877/8/
Stromverbrauchsunterschied Menlow-Plattform und Moorestown-Plattform in Idle:
http://www.computerbase.de/bildstrecke/25877/14/

Und nun zur schwierigen Fleißaufgabe - bitte steuert Windows 7 so feingranular, wie es ein Android oder Symbian kann.

Das Villiv X70 ist mit seinen (Hardware-)Eckdaten absolut konkurrenzfähig.
http://www.engadget.com/2011/01/07/viliv-x70-windows-7-slate-with-oak-trail-hands-on/
1.5 GHz Oak Trail processor
7-inch 1024 x 600-resolution capacitive multitouch display
420 gramm schwer ( Quelle hier )
they claim 6.5 hours, which is better than the Galaxy Tab

Man kann also ein Gerät bauen, das etwas schwerer als das Galaxy Tab (380g vs 420g) ist, dafür etwas länger läuft(lassen wir uns mal überraschen). Aber mit Windows 7 betrieben werden kann. Ansonsten sind die Eckdaten identisch (1024x600 & 7-inch display).

Grüße,
Tom
 
Diese Soft-/Hardware Kombination (Win7/Touchscreen 7"@1024x600) ist ein Rohrkrepierer.
 
Zuletzt bearbeitet:
Ich tippe mal auf ARM.

Geringe Verlustleistung bei im Grunde schon heute ausreichender Leistung. Dazu dann mit iOS und Android sehr viel versprechende Betriebssysteme die schon heute verfügbar sind. Windows wird es nicht leicht haben und gute Argumente für eine x86 CPU im Tablet fallen mir eigentlich nicht ein. Intel und vorallem AMD haben einfach gepennt. *wegpenn*
 
Zuletzt bearbeitet:
Ok, war vielleicht ein bisschen überspitzt formuliert, aber die Vorteile von 64 Bit und erweitertem Speicher bei einem Tablet musst du mir erklären, für mich macht das absolut null Sinn.
Zum Lüfter: dem empfinden dir meisten Menschen einfach mit als laut, egal ob das Gerät mit Lüfter besser läuft als das ohne, Hauptsache leise.
Wie Limit64 schon schrieb, lies bitte nochmal richtig bzgl. der Bobcat-Anpassung.

Jedenfalls ist ein Lüfter Quatsch, nicht nur wegen laut, sondern 1. das schon einen viel zu hohen SoC-Verbrauch bedeutet u. 2. der Lüfterverbrauch noch oben drauf kommt. Dann lieber Throttling.

Dein Ontario Vergleich hinkt etwas: Es ist egal wie viel die einzelnen Kernel verbrauchen, wichtig ist der Gesamtverbrauch, und der liegt bei x86 höher als bei ARM. ich meine mal gelesen zu haben, das ein ganzes 1Ghz Singlecore SoC samt allen Dingen wie IO, Grafik etc nicht mehr als einen Watt verbraucht, da rangiert die Ontario APU weit höher.
Im Mobilbereich sind u.a. (neben Größe) wichtig: Verbrauchswerte bei Idle/Standby u. EPI (Energy per Instruction) - eine "knee of the curve"-Optimierung. Sozusagen die meiste Leistung für's mW. Da müsste man die Systeme mal vergleichen. Allein die Bobcat-Performance, der Memory Controller Throughput, der L2, die GPU, das PCIe-Interface dürften alle überdimensioniert sein. Kennst du brauchbare Vergleichswerte? Dann könnten wir versuchen, den Verbrauch von Ontario nach Anpassung der Leistung u. Fähigkeiten zu schätzen.

Bei meinem Desire frisst der Screen etwa 65% des verbrauchten Stroms, warum also noch weniger Laufzeit für Leistung die ich nicht brauche? Softwareoptinierung seitens ARM dürfte die Sache vereinfachen, aber auch die Hersteller sind nicht unschuldig.
Evtl. auch ein Effekt von 65nm-SoC vs 45nm-SoC? Verbrauchswerte sind schwer zu finden.
 
ich meine mal gelesen zu haben, das ein ganzes 1Ghz Singlecore SoC samt allen Dingen wie IO, Grafik etc nicht mehr als einen Watt verbraucht, da rangiert die Ontario APU weit höher.

Das sind aber Kisten die In-Order arbeiten, kaum Cache haben, sehr schmale Speicherbusse (16 Bit) haben, etc. pp.. Und dann wundert man sich wie langsam doch 1 Ghz sein kann.

Hier mal ein Q&D Vergleich:

Code:
# cat /proc/cpuinfo 
Processor	: Feroceon 88FR131 rev 1 (v5l)
BogoMIPS	: 1192.75
Features	: swp half thumb fastmult edsp 
CPU implementer	: 0x56
CPU architecture: 5TE
CPU variant	: 0x2
CPU part	: 0x131
CPU revision	: 1

Hardware	: Marvell SheevaPlug Reference Board
Revision	: 0000
Serial		: 0000000000000000

# openssl speed

OpenSSL 0.9.8o 01 Jun 2010
built on: Thu Aug 26 18:56:26 UTC 2010
options:bn(64,32) md2(int) rc4(ptr,int) des(idx,risc1,4,long) aes(partial) blowfish(idx) 
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wa,--noexecstack -g -Wall
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md2                647.09k     1438.43k     2057.83k     2313.74k     2382.87k
mdc2                 0.00         0.00         0.00         0.00         0.00 
md4               4129.91k    14906.34k    43950.24k    96963.45k   134426.51k
md5               3454.36k    11840.68k    34058.81k    64283.47k    86281.69k
hmac(md5)         4244.03k    14425.18k    39062.90k    69264.14k    87893.81k
sha1              2966.70k     9416.55k    22636.87k    34962.29k    41440.02k
rmd160            2499.48k     7725.61k    18117.52k    27300.62k    32041.10k
rc4              36720.68k    41269.89k    42669.39k    43189.72k    43301.38k
des cbc           7966.73k     8631.96k     8806.76k     8873.37k     8878.04k
des ede3          3401.36k     3540.97k     3181.25k     3142.51k     3154.79k
idea cbc             0.00         0.00         0.00         0.00         0.00 
seed cbc             0.00         0.00         0.00         0.00         0.00 
rc2 cbc           9100.80k     9769.01k     9955.65k     9977.15k    10003.31k
rc5-32/12 cbc        0.00         0.00         0.00         0.00         0.00 
blowfish cbc     15394.12k    18886.26k    21470.04k    21176.94k    19294.47k
cast cbc         15394.31k    18463.07k    19241.10k    19439.06k    19547.91k
aes-128 cbc       8990.85k     9926.08k    10124.18k    10168.50k    10197.63k
aes-192 cbc       7799.86k     8512.78k     8679.75k     8718.48k     8706.52k
aes-256 cbc       6934.62k     7436.58k     7588.81k     7628.09k     7632.41k
camellia-128 cbc        0.00         0.00         0.00         0.00         0.00 
camellia-192 cbc        0.00         0.00         0.00         0.00         0.00 
camellia-256 cbc        0.00         0.00         0.00         0.00         0.00 
sha256            2555.41k     6035.29k    10817.20k    13466.50k    14527.34k
sha512             313.99k     1257.84k     1781.90k     2439.24k     2795.09k
aes-128 ige       8967.52k    10285.81k    10758.82k    10899.99k    10720.22k
aes-192 ige       7752.09k     8575.89k     8879.68k     8959.47k     8830.75k
aes-256 ige       6900.87k     7627.40k     7926.84k     8001.73k     7906.43k
                  sign    verify    sign/s verify/s
rsa  512 bits 0.002820s 0.000225s    354.6   4447.1
rsa 1024 bits 0.012779s 0.000582s     78.3   1718.5
rsa 2048 bits 0.069783s 0.001786s     14.3    559.8
rsa 4096 bits 0.432609s 0.005996s      2.3    166.8
                  sign    verify    sign/s verify/s
dsa  512 bits 0.002290s 0.002482s    436.7    403.0
dsa 1024 bits 0.005425s 0.006826s    184.3    146.5
dsa 2048 bits 0.017774s 0.021053s     56.3     47.5

# wget [url]http://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf[/url]

# time for i in 1 2 3 4 5 6 7 8 9 0; do gzip -9 <rfc2616.pdf > /dev/null; echo $i; done
1
2
3
4
5
6
7
8
9
0

real	0m3.697s
user	0m3.470s
sys	0m0.160s

-------------------------------------------------------------------------------------------------------

$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X3 720 Processor
stepping	: 2
cpu MHz		: 800.000
cache size	: 512 KB
physical id	: 0
siblings	: 3
core id		: 0
cpu cores	: 3
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt
bogomips	: 5625.57
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

$ openssl speed

OpenSSL 0.9.8k 25 Mar 2009
built on: Fri Dec  3 22:53:56 UTC 2010
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2) 
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md2               1806.82k     3693.23k     5018.54k     5508.37k     5665.91k
mdc2                 0.00         0.00         0.00         0.00         0.00 
md4              48958.23k   158503.88k   411222.90k   681977.84k   844095.49k
md5              37319.64k   119965.93k   292196.35k   455811.17k   546142.50k
hmac(md5)        39949.00k   126770.26k   302941.41k   460871.23k   545562.54k
sha1             38923.00k   114174.69k   255807.31k   366812.55k   422008.55k
rmd160           27753.62k    71215.79k   138138.11k   180382.38k   198309.21k
rc4             207181.58k   223130.24k   226689.45k   228384.43k   229466.41k
des cbc          57618.64k    59791.13k    60088.15k    60289.37k    60342.27k
des ede3         22545.19k    22892.44k    23018.33k    23050.92k    23060.48k
idea cbc             0.00         0.00         0.00         0.00         0.00 
seed cbc             0.00         0.00         0.00         0.00         0.00 
rc2 cbc          33079.43k    34046.40k    34303.23k    34364.76k    34381.82k
rc5-32/12 cbc        0.00         0.00         0.00         0.00         0.00 
blowfish cbc    101812.17k   108855.79k   110450.43k   111152.13k   111351.13k
cast cbc         75774.60k    79642.71k    80436.06k    80806.61k    80917.23k
aes-128 cbc     113574.69k   179932.80k   217813.59k   229909.50k   233641.30k
aes-192 cbc      99873.93k   158212.26k   186014.89k   194990.42k   197667.50k
aes-256 cbc      95287.23k   138118.44k   156852.31k   162367.15k   164012.03k
camellia-128 cbc        0.00         0.00         0.00         0.00         0.00 
camellia-192 cbc        0.00         0.00         0.00         0.00         0.00 
camellia-256 cbc        0.00         0.00         0.00         0.00         0.00 
sha256           29027.95k    69789.58k   127862.75k   161169.38k   174291.67k
sha512           20653.33k    83236.71k   152804.61k   233267.88k   276081.32k
aes-128 ige     177302.71k   192447.21k   200695.18k   202806.11k   203325.99k
aes-192 ige     156005.65k   167038.89k   173217.11k   174725.12k   175180.46k
aes-256 ige     138766.57k   143504.55k   146492.84k   147488.43k   147939.33k
                  sign    verify    sign/s verify/s
rsa  512 bits 0.000093s 0.000009s  10754.2 114942.7
rsa 1024 bits 0.000443s 0.000025s   2258.6  40391.6
rsa 2048 bits 0.002804s 0.000080s    356.7  12505.6
rsa 4096 bits 0.018692s 0.000289s     53.5   3456.3
                  sign    verify    sign/s verify/s
dsa  512 bits 0.000093s 0.000093s  10749.3  10716.4
dsa 1024 bits 0.000241s 0.000271s   4141.6   3690.3
dsa 2048 bits 0.000771s 0.000907s   1296.5   1102.3


$ wget [url]http://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf[/url]

$ time for i in 1 2 3 4 5 6 7 8 9 0; do gzip -9 <rfc2616.pdf > /dev/null; echo $i; done
1
2
3
4
5
6
7
8
9
0

real	0m0.370s
user	0m0.400s
sys	0m0.010s
 
Hier wurde bereits das Streak 7 von Dell zerlegt, obwohl es noch gar nicht erhältlich ist. (Tegra2)
Man achte auf das Kühlkonzept..
Aus der NV Webseite geht hervor: Audio abspielen = 30 mW, Rendern v. Full Screen Flash Animationen = 150 mW, 1080p Video Playback = unter 400 mW,
VCore und Frequenz sind immer auslastungsbezogen. Nach dem Laden einer Webseite wird die CPU abgeschaltet auch bei Seiten mit Flash Inhalten.
 
Zuletzt bearbeitet:
und wie sollen dann die Animationen weiterlaufen? ich meine, gibt doch viele Flashelemente auf Interaktion regieren.

Oder ist damit eine Art DeeperSleep gemeint, in den die CPU verfällt? Bin aktuell nur mobil unterwegs...

Insgesamt finde ich das Tegra Konzept aber sehr gut, auf Golem habe ein Video in dem Audi über den Tegra sprach, dort war der Kühler auch recht interessant, vorallem in der Größe.
 
Zurück
Oben Unten