News Intels Quad-Core-SoC „Moorefield“ verbraucht zu viel

[iGameKudan]

Das mag zwar sein, das wichtigste, die Apps müssen auch für x86 kompiliert werden. Das kann nicht jedes SDK. Daher sind im Playstore recht wenig Apps verfügbar, die auf x86 laufen.

Insbesondere Apps die näher an der Hardware laufen, müssen ersteinmal auf x86 angepasst werden.

Mal davon abgesehen das kein Hersteller bis auf Asus Bock auf Intel hat.Wer will sich schon freiwillig die Konditionen vorschreiben lassen, so wie es im Markt für geschehen ist?

Komisch, bei meinen Experimenten mit Android x86 lief so ziemlich jede App....

Gab es vor einiger Zeit nicht mal die News dass im ARM-Bereich bezüglich Benchmarks auch ziemlich gepfuscht wird? Das geht über die schnellen ARM-Chips werden bei anhaltender Leistung zu warm und drosseln bis kurzzeitiges selbstständiges Übertakten wenn eine Benchmark-App erkannt wird?

http://www.macerkopf.de/2013/07/30/samsung-trickst-bei-benchmark-tests/

Vermutlich wäre der Leistungsvorsprung von Intel hinterher genau so groß.

 

[AMINDIA]

iGameKudan
Was wurde denn gepfuscht? Und nein, es ist nicht eine ARM typische Manipulation bei Benches. Es ist nicht eine Intel Compiler Manipulation im ARM Sektor vorhanden. Samsung soll hier und da bei ihren Produkten mit ARM CPUs getrickst haben. Wenn das SAMSUNG Gerät mit ARM CPU ein Benchmark Programm erkannte, wurde dafür automatisch die Leistung erhöht.

 

[Diablokiller999]

Das ist aber auch wohl eher um unter der eigenen Konkurrenz aus dem ARM Lager etwas besser in Benches dar zu stehen, die Detection ist aber simpel zu umgehen und ich hoffe das jedes ernst zu nehmende Review das auch tut!

Und das auf Android jede App läuft, egal ob x86 oder ARM, sollte wohl klar sein (java*hust*).
Das ist imo auch das größte Problem bei Android, Objective-C würde hier wahre Wunder bewirken was die Leistung angeht.

Finde es aber auch bedenklich wie Intel hier in den Markt rein prescht, das "schlechtere" Produkt unter Wert verramschen um Konkurrenz aus dem Markt zu drängen hat aber schon seit dem 8086 Tradition in der Firma, der MC68000 hat damit doch den Boden gewischt...

 

[Dese]

Das ist aber auch wohl eher um unter der eigenen Konkurrenz aus dem ARM Lager etwas besser in Benches dar zu stehen, die Detection ist aber simpel zu umgehen und ich hoffe das jedes ernst zu nehmende Review das auch tut!

Und das auf Android jede App läuft, egal ob x86 oder ARM, sollte wohl klar sein (java*hust*).

Falsch! viele apps, insbesondere games, aber auch eingige andere nutzen die möglichkeit von nativen code. und hier gibt es probleme. intel bietet da zwar eine art compatibility layer, was aber a) nciht immer funktioniert und b) oft wenn, dann nur sehr langsam.

EDIT: allerdings ist es ein leichtes für entwickler ihre apps mit nativen code auch für x86 performant lauffähig zu machen. dazu muss man einfach beim bauen der app die x86 plattform mit angeben und zack werden alle nativen libs für beides erzeugt.
machen tuen das aber noch lange nicht alle.

Das ist imo auch das größte Problem bei Android, Objective-C würde hier wahre Wunder bewirken was die Leistung angeht.

noch mehr quatsch. ob java oder objectiv-c hat ABSOLUT KEINEN einfluss auf performance! das sind beides lediglich programmiersprachen. was einfluss auf die eprformance hat, ist die dalvik VM und die VM, die auf iphones eingesetzt wird.

 

[riDDi]

@Diablokiller999:
Objective-C ist nicht C/C++. Objective-C ist langsamer als C/C++. Wenn du auf dem iPhone schnell sein willst musst du C/C++ schreiben, nicht Objective-C. Das geht aber nur wenn man nicht mit Cocoa Kommunizieren muss.
Java ist eine Programmiersprache und kann nicht langsam sein. Die Sun/Oracle Hotspot JVM hat nichts mit der Dalvik JVM zu tun. Jede moderne JVM hat einen JIT-Compiler, führt also Machinencode aus. JIT-Compiler analysieren den Code während der läuft und können prinzipiell bessere Ergebnisse liefern als AOT-Compiler. Wenn man es unbedingt braucht kann man über Android NDK nativen Code einbinden.
In Android 4.4 gibt es die Android Runtime (ART) als Alternative zur Dalvik JVM. ART bringt einen AOT-Compiler mit.

 

[Diablokiller999]

Oh, wusste nicht dass es das NDK gibt....und wieder etwas schlauer
Das Android einen JIT-Compiler nutzt weiß ich zwar, nur sind die imo halt langsamer als stets fertig ausführbarer Bytecode der direkt in den RAM geknallt wird. Bis jetzt dachte ich immer, auf iPhones wird durch Objektive C direkt fertig kompilierter Bytecode ausgeführt, während sich Android alles JIT zurecht legen muss. Also nutzt iOS auch 'ne VM im Hintergrund?

Habe noch nicht wirklich für beide Systeme programmiert, Java ist nicht mein Ding und Iphones sowieso nicht. Komme aus der Systemprogrammierer-Welt und huldige stets meinem C/C++ und ASM Code

 

[riDDi]

Der JIT-Vorgang verlangsamt (in den allermeisten Fällen) nur den Start der App. Danach ist es egal. Nur wenn Dalvik merkt, dass etwas neu kompiliert werden muss dauert es länger, aber das ist extrem selten. Mit ART starten Apps deshalb spürbar schneller. Es macht fast keinen Unterschied ob eine App neu gestartet wird oder im Hintergrund noch aktiv ist.
Objective-C wird nicht interpretiert sondern kompiliert. Beim Methodenaufruf muss aber zur Laufzeit der Typ der Argumente festgestellt werden und welche Methode genau gebraucht wird. Das ist AFAIK bis heute so und macht Objective-C langsam.
C/C++ ist auch nur wirklich bedeutend schneller, wenn den Code stark optimiert (was die wenigsten Leute tun) und Compiler-Flags setzen kann, die extrem auf die Rechnerarchitektur optimiert sind. Sprich alles inkl. SSE 4.2 und AVX anschalten. Das ist am Telefon/Tablet nicht relevant.

 

[Krautmaster]

der wäre auch bei 4x 2,3 Ghz fast zu schnell für die Konkurrenz bei der CPU Leistung. Ein guter Turbo und geringerer Basistakt wäre wohl für reaktionsfreudige Smartphones wichtiger als hoher Takt auf 4 Kernen.

Was der Artikel ohnehin vollkommen offen lässt.... wie schaut es beim Standby und Idle Verbrauch aus - wie der bei Teillast? Das ist doch 100x wichtiger als ob der eine SOC bei Maximal Last vielleicht nur 80% der Perf / W des anderen erreicht...
Wenn der Intel SOC vielleicht schneller von C-State zu C-State wechseln kann und idle eine mW sparen kann ist das unterm Strich wichtiger als ob 4x1,7 oder 4x2,3 Ghz. Selbst schnelle 2 Kerne wären wohl von Vorteil.

Ich denke der X86 Overhead den Intel beim SOC bei hat is einfach recht groß. Interessant wäre ein Intel ARM bei intelschen 14nm

@ Benches.

Silvermont X86 @ Android

Der Intel Moorefield dürfte sich was Kernarchitektur angeht - so denk ich, nicht wesentlich unterscheiden - oder?