Új hozzászólás Aktív témák

• #53 vicze félisten namaste #52

  Új Válasz 2012-06-18 14:52:14 #53

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  vicze

  félisten

  válasz namaste #52 üzenetére

  Telefonok hiányában, innen néztem az adatokat. (Képek épp nem mennek karbantartás miatt, de majd jó lesz valamikor akkor látszik.)

  Snapdragon S4 106,794/218,197=2,04
  Snapdargon S3 53,228/90,052=1,69
  Exynos 4210 57,499/84,376=1,46
  OMAP 4430 52,792/74,963=1,41
  Tegra 2 38,848/64,822=1,66

  Ebből következtettem arra amit írtam. (Tegra 2 dög lassú NEON nélkül, de legalább jól skálázódik.)

• #51 vicze félisten namaste #50

  Új Válasz 2012-06-16 18:34:50 #51

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  vicze

  félisten

  válasz namaste #50 üzenetére

  Értem, a problémám akkor még az, hogy a Scorpion is jól skálázódik, nem olyan jól mint a Karit, de sokkal jobban mint a többi kétmagos. Pedig csak 512k az L2, tehát előbb üríti, mint az Exynos(2magos), amiben 1MB-van 32k L1-el, és mégis 20-30%-kal jobban skálázódik Linpackban. Valamint az Exynosnak, amennyire tudom, a legerősebb a memória alrendszere, és tapasztalatom szerint a Snapdrgonokban elég gyenge (Azaz HTC gyengét rak alá. ).

• #49 vicze félisten namaste #46

  Új Válasz 2012-06-14 15:03:10 #49

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  vicze

  félisten

  válasz namaste #46 üzenetére

  Memória alatt a L2-t érted? Ebből a szempontból mindegyik azonos. 32k L1 és 1MB L2 van az összesben. A régi 2 magosokban is (Tegra2, Exynos 4210/12) pontosan ilyen a memória alrendszer, és ugyan olyan rosszul skálázódnak. A sávszélessége a Exynos 4412-nek és a Karitnak is 128bit belsőleg.
  Nem egészen értem tehát mi miatt nem tudnak a régi kétmagosok skálázódni? Meg azt se hogy miért nem az új 4 magosok, és miért tud a Karit? Sőt miért tud az S3-as Scorpion majdnem tökéletesen skálázódni?

• #34 vicze félisten namaste #33

  Új Válasz 2012-06-12 20:39:15 #34

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  vicze

  félisten

  válasz namaste #33 üzenetére

  Nézd meg a single és multi thread eredményeket, S4-nél pontosan duplája, tehát S4-nél működne rendesen a skálázódás a többinél pedig nem? Akkor vagy az Intelenk van valamennyire igaza, mivel a többi gyártó képtelen értelmesen skálázódó SoC-ot csinálni. Azt viszont nem hiszem, hogy SW oldalon van a probléma (csak majd ha mutat valódi tesztet az Intel), hanem inkább a szarabbnál szarabb SoC implementációk okozzák, és valósan mókusvakítás a sok mag... lásd Tegra 3 multi thread eredményei.

  "Az aktív magok számának meghatározása, azok órajelének dinamikus szabályozása, illetve a párhuzamos szálak aktív magok közötti leghatékonyabb elosztása egyáltalán nem triviális feladat, ráadásul ez igencsak processzor és chipset függő lehet."
  Ezt mind a SoC vezérli és pontosan ebben erős a Qualcomm, jelenleg az ő megoldásul a legjobb ARM-en, és még jó ideig az is marad.

• #23 vicze félisten pauldenton #17

  Új Válasz 2012-06-12 15:49:17 #23

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  vicze

  félisten

  válasz pauldenton #17 üzenetére

  Hát, ez elég ködös ez nekem...

  Intel outlines this in a number of slides which have made their way online, and the process is virtually completely transparent to end users and Dalvik applications. The x86 compatible Dalvik VM is a part of the OS, as are the ARM to Atom BT phase for JNI libraries. ARM native NDK apps on the other hand are translated by Intel in the cloud, validated against Intel's Android x86 emulator and pushed to the Play Store. The point is the bulk of binary translation happens away from the device itself and running on much faster Xeons in the cloud. As binary translation requires more cycles than natively running the code, which in turn consumes additional power, this was the only route for Intel to ensure that Atom would remain power efficient (and high performance) even on non-native NDK apps. Update: Intel has clarified and informed us there is no cloud aspect to binary translation, it is 100% done on the device for ARM NDK applications.

  It's still unclear just how long this process takes after a developer has uploaded a non-x86 NDK app to the Play Store, or what happens if the process fails to validate for whatever reason (Does Intel get in touch with the developer? Is the app forever excluded?). Intel is being unusually vague about how all of this works unfortunately.

  The combination of all of these efforts should result in over 90% of the apps in the Play Store working right away. What about in our experience? We discuss that next.

  A sebességgel tisztában vagyok. Amúgy ha megnézed a Linpack eredményeket, az Intelnek igaza van, csak a Qualcomm oldotta meg értelmesen a skálázódást, meg majd az OMAP5. A Tegra egy katasztrófa marad ezen a téren továbbra is.

• #11 vicze félisten tjb007 #5

  Új Válasz 2012-06-12 15:18:16 #11

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  vicze

  félisten

  válasz tjb007 #5 üzenetére

  De most komolyan miért venne bárki is Intelest, mikor a natív appok nem futnak rajta?
  Valahogy halott elképzelésnek tűnik alapból.

Új hozzászólás Aktív témák