Abo
  1. Foren
  2. Kommentare
  3. Handy
  4. Alle Kommentare zum Artikel
  5. › HTC Titan: Großes Smartphone mit 1,5-GHz…

Zweikernschwachsinn

  1. Thema

Neues Thema Ansicht wechseln


  1. Zweikernschwachsinn

    Autor: WinMo4tw 01.09.11 - 21:00

    Sowas braucht momentan noch kein Mensch. Windows Phone läuft selbst auf der ersten Generation Snapdragon butterweich. Die hier verbaute zweite Generation mit 2-3fach leistungsfähigerer Grafik und nochmal 50% mehr Takt reicht für diese Gerätegeneration allemal.

    MfG

  2. Re: Zweikernschwachsinnschwachsinn

    Autor: pwn2own 01.09.11 - 21:10

    Normalnutzer vllt. nicht. Aber mittlerweile gibt es auch Anwendungen, die nicht im App-Store/Market/Softwarekonsum zu finden sind und sehr wohl ein bisschen Rechenpower benötigen.

  3. Re: Zweikernschwachsinn

    Autor: Anonymer Nutzer 01.09.11 - 21:41

    is doch wurscht, hauptsache der schwanz ist länger als der von apple.

  4. Re: Zweikernschwachsinnschwachsinn

    Autor: Trollversteher 01.09.11 - 22:18

    Da WP7 aber zB gegenüber Android ein extrem performantes OS ist, reicht die Performance sehr wohl auch für komplexere Anwendungen aus.

  5. Re: Zweikernschwachsinnschwachsinn

    Autor: smurfy 01.09.11 - 22:46

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > Da WP7 aber zB gegenüber Android ein extrem performantes OS ist, reicht die
    > Performance sehr wohl auch für komplexere Anwendungen aus.

    Ich glaube du hast da nicht ganz zuende gedacht. Die Windows GUI ist sehr performant, jedenfalls performanter als die von Android (so lange Android nicht die GPU verwendet).

    Allerdings hat das nichts mit der Performance von Anwendungen und Spielen zu tun. Denn diese laufen unter Android nicht langsamer als unter WP7. Die performancekritischen Teile können auch unter Android unter C/C++ geschrieben werden, und laufen spätestens dann sehr flott. Gegen einen DualCore Android kommt da ein SingleCore WP7 auch nicht an.

  6. Re: Zweikernschwachsinnschwachsinn

    Autor: Trollversteher 01.09.11 - 22:56

    >Allerdings hat das nichts mit der Performance von Anwendungen und Spielen zu tun. Denn diese laufen unter Android nicht langsamer als unter WP7. Die performancekritischen Teile können auch unter Android unter C/C++ geschrieben werden, und laufen spätestens dann sehr flott. Gegen einen DualCore Android kommt da ein SingleCore WP7 auch nicht an.

    Naja, das geht aber wirklich nur bei Spezialanwendungen, die genau auf einem bestimmten Gerät laufen, mit Multiplattform ist dann Sense. Mag für eine firmeninterne Anwenung, oder ein Kundenprojekt funktionieren, bei dem die Hardware gleich mit ausgeliefert wird - für kommerzielle Projekte ist das aber nix. Und bei jedem späteren Modellwechsel ist dann fröhliches Portieren angesagt...

  7. Re: Zweikernschwachsinnschwachsinn

    Autor: JeanClaudeBaktiste 01.09.11 - 23:37

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > >Allerdings hat das nichts mit der Performance von Anwendungen und Spielen
    > zu tun. Denn diese laufen unter Android nicht langsamer als unter WP7. Die
    > performancekritischen Teile können auch unter Android unter C/C++
    > geschrieben werden, und laufen spätestens dann sehr flott. Gegen einen
    > DualCore Android kommt da ein SingleCore WP7 auch nicht an.
    >
    > Naja, das geht aber wirklich nur bei Spezialanwendungen, die genau auf
    > einem bestimmten Gerät laufen, mit Multiplattform ist dann Sense. Mag für
    > eine firmeninterne Anwenung, oder ein Kundenprojekt funktionieren, bei dem
    > die Hardware gleich mit ausgeliefert wird - für kommerzielle Projekte ist
    > das aber nix. Und bei jedem späteren Modellwechsel ist dann fröhliches
    > Portieren angesagt...

    auf kurz oder lang wird es wp7 oder 8 dann auch mit multicore geben,

    ich finde es auch recht vernünftig noch bei 800 x 480 zu bleiben auch wenn auf dem großen schirm vielleicht wieder pixel zu sehen sind.

    wenn man aber überlegt dass damals damit 15 zoll monitore gelaufen sind (800 c 600) ist noch ein bischen luft.

    retina halte ich für marketing. ich habe mal das iphone 4 mit meinem omnia verglichen. beim omnia sieht man wenn man genau hinschaut ein raster was wohl prinzipbedingt an amoled liegt. der auflösungsvorteil des iphone 4 kommt nicht zum vorschein, dafür büsst der screen wegen der geringeren größe und den trüben farben massiv ein.

    ---
    leer, weil keine Werbung bei Golem :(

  8. Re: Zweikernschwachsinn

    Autor: sparvar 02.09.11 - 00:00

    [ ] du hast ahnung
    [ x ] troll

  9. Re: Zweikernschwachsinnschwachsinn

    Autor: tomek 02.09.11 - 00:21

    JeanClaudeBaktiste schrieb:
    --------------------------------------------------------------------------------
    > ich finde es auch recht vernünftig noch bei 800 x 480 zu bleiben auch wenn
    > auf dem großen schirm vielleicht wieder pixel zu sehen sind.
    >
    > wenn man aber überlegt dass damals damit 15 zoll monitore gelaufen sind
    > (800 c 600) ist noch ein bischen luft.
    >
    > retina halte ich für marketing. ich habe mal das iphone 4 mit meinem omnia
    > verglichen. beim omnia sieht man wenn man genau hinschaut ein raster was
    > wohl prinzipbedingt an amoled liegt. der auflösungsvorteil des iphone 4
    > kommt nicht zum vorschein, dafür büsst der screen wegen der geringeren
    > größe und den trüben farben massiv ein.
    Denke ich auch. Es ist ein unterschied zwischen dem was möglich und dem was nötig ist. Und das Display meines HD7 ist alles andere als pixelig. Und das gehört mit zu den größeren Display (von der Diagonale her).

  10. Re: Zweikernschwachsinn

    Autor: EqPO 02.09.11 - 07:58

    Nein WP7-Besitzer. Schön reden ist wichtig.

  11. Re: Zweikernschwachsinnschwachsinn

    Autor: nate 02.09.11 - 08:59

    > > Die
    > > performancekritischen Teile können auch unter Android unter C/C++
    > > geschrieben werden, und laufen spätestens dann sehr flott.
    >
    > Naja, das geht aber wirklich nur bei Spezialanwendungen, die genau auf
    > einem bestimmten Gerät laufen, mit Multiplattform ist dann Sense.

    So ein Käse. Alle(*) Android-Smartphones haben einen ARMv6- oder ARMv7-Prozessor und wenn sie eine GPU haben (und die haben fast alle), dann eine, die über OpenGL|ES 2.0 angesprochen werden kann. Wieso sollte eine Anwendung dann nur "genau auf einem bestimmten Gerät" laufen?


    (*) Ausnahmen sind hierzulande so gut wie gar nicht verbreitete Ultra-Billig-China-Geräte, die gelegentlich noch ältere ARMe oder sogar vereinzelt MIPSe benutzen. Aber das sind wirklich nur die Billigstdinger, auch Huawei und ZTE spielen da in einer anderen Liga.

  12. Re: Zweikernschwachsinnschwachsinn

    Autor: Trollversteher 02.09.11 - 09:28

    >retina halte ich für marketing. ich habe mal das iphone 4 mit meinem omnia verglichen. beim omnia sieht man wenn man genau hinschaut ein raster was wohl prinzipbedingt an amoled liegt. der auflösungsvorteil des iphone 4 kommt nicht zum vorschein, dafür büsst der screen wegen der geringeren größe und den trüben farben massiv ein.

    Ich finde, besonders bei Desktop-Websites mit viel Schrift sieht man durchaus den Unterschied beim iPhone4. Besonders, weil das AMOLED (im Gegensatz zum neuen Super AMOLED) eine deutlich geringere tatsächlich Auflösung als die Nennauflösung hat. (weniger Sub-Pixel pro Pixel)

  13. Re: Zweikernschwachsinnschwachsinn

    Autor: Trollversteher 02.09.11 - 11:18

    >So ein Käse. Alle(*) Android-Smartphones haben einen ARMv6- oder ARMv7-Prozessor und wenn sie eine GPU haben (und die haben fast alle), dann eine, die über OpenGL|ES 2.0 angesprochen werden kann. Wieso sollte eine Anwendung dann nur "genau auf einem bestimmten Gerät" laufen?

    Weil es z.B. selbst zwischen den einzelnen ARM-Prozessoren Unterschiede gibt:
    http://www.riscosopen.org/wiki/documentation/show/ARMv7%20compatibility%20primer

    Weil die GUIs von den verschiedenen Herstellern z.T. angepaßt wurden - OK, vermutlich schlägst Du jetzt vor, Deine eigene GUI zu schreiben - viel Spaß mit unterschiedlichen Display Auflösungen und Formaten...

    Weil es mehr als CPU+GPU auf den SoCs gibt? Wie ist das mit Multithreaded Code? Wird der ohne Neucompilierung jeweils optimal auf Single-Core Geräten als auch auf Multicore-Geräten ausgeführt?

  14. Re: Zweikernschwachsinnschwachsinn

    Autor: nate 02.09.11 - 11:39

    > > Wieso sollte eine
    > > Anwendung dann nur "genau auf einem bestimmten Gerät" laufen?
    >
    > Weil es z.B. selbst zwischen den einzelnen ARM-Prozessoren Unterschiede
    > gibt:

    Das bezieht sich nicht auf einzelne ARM-Prozessoren, sondern auf Architekturversionen -- und die beiden für Smartphones relevanten (ARMv6 und ARMv7) habe ich ja bereits genannt. Davon abgesehen sind das, was der Artikel nennt, mehr oder weniger Peanuts: Anderes Verhalten bei falsch ausgerichteten Speicherzugriffen ("geht gar nicht"/"geht langsam"/"geht schnell"), anderes Verhalten bei sinnlosen Codesequenzen und solches Zeug. Alles Dinge, mit denen sich allenfalls der Compilerhersteller herumplagen muss und für einen Anwendungsentwickler in 99% aller Fälle komplett irrelevant sind.

    > Weil die GUIs von den verschiedenen Herstellern z.T. angepaßt wurden

    Und? Was interessiert deine Anwendung, wie der Launcher und die Statusleiste konkret aussieht?

    > vermutlich schlägst Du jetzt vor, Deine eigene GUI zu schreiben

    Was meinst du mit "eigene GUI schreiben"? Die allermeisten Android-, WebOS, WP7- und iOS-Anwendungen benutzen die Standard-Widgetsets des Betriebssystems. Ausnahmen sind Applikationen, die besondere Anforderungen haben und daher ein komplett eigenes User Interface brauchen, z.B. Spiele.

    > viel Spaß
    > mit unterschiedlichen Display Auflösungen und Formaten...

    Und? Mit unterschiedlichen Displayauflösungen muss man sich auf jedem Smartphone-Betriebssystem auseinandersetzen. Das einzige, wo das nicht so ist, ist WP7 -- bisher. Früher oder später wird aber auch Microsoft zur Erkenntnis gelangen, dass 480x800 keine Auflösung für die Ewigkeit ist :)

    > Weil es mehr als CPU+GPU auf den SoCs gibt?

    Und? Für so ziemlich jede Komponente gibt es APIs vom jeweiligen Betriebssystem.

    > Wie ist das mit Multithreaded
    > Code? Wird der ohne Neucompilierung jeweils optimal auf Single-Core Geräten
    > als auch auf Multicore-Geräten ausgeführt?

    Da gilt das gleiche wie für normale PC/Mac-Anwendungen: Wenn im System mehr Threads benutzt werden als die CPUs Threads hat (und das ist *immer* der Fall), kommt präemptives zeitscheiben-basiertes Multitasking zum Einsatz.

    In Anwendungen, die konkret auf Multithreading ausgerichtet sind, kommt übrigens meist eine Thread-Pool-Verwaltung zum Einsatz, die sich an die Anzahl der im System vorhandenen Cores/Threads anpasst -- zur Laufzeit, wohlgemerkt.

  15. Re: Zweikernschwachsinnschwachsinn

    Autor: Trollversteher 02.09.11 - 12:40

    >...anderes Verhalten bei sinnlosen Codesequenzen und solches Zeug. Alles Dinge, mit denen sich allenfalls der Compilerhersteller herumplagen muss und für einen Anwendungsentwickler in 99% aller Fälle komplett irrelevant sind.

    Ähem, exakt davon rede ich doch? Ich sagte nicht, daß Du Deine C++ Anwendung wegen der unterschiedlichen CPUs jedesmal Redesignen mußt, aber um ein Neucompilieren kommst Du nicht drumherum...

    >Und? Was interessiert deine Anwendung, wie der Launcher und die Statusleiste konkret aussieht?

    Wie ist das mit den GUI-Libs? Werden die nicht angefaßt und angepaßt?

    >Was meinst du mit "eigene GUI schreiben"? Die allermeisten Android-, WebOS, WP7- und iOS-Anwendungen benutzen die Standard-Widgetsets des Betriebssystems.

    Richtig, und wenn beim Betriebssystem oberhalb des Kernels jeder Hersteller sein eigenen Anpassungen, Erweiterungen und Änderungen machen kann, dann mußt Du auch Deine App anpassen, die diese nutzt.

    >Und? Mit unterschiedlichen Displayauflösungen muss man sich auf jedem Smartphone-Betriebssystem auseinandersetzen.

    Eigentlich nur bei Android... Apple hat das ja geschickt durch die Auflösungs-Verfierfachung umgangen.

    >Und? Für so ziemlich jede Komponente gibt es APIs vom jeweiligen Betriebssystem.

    Und gegen die muß man nicht compilieren? Und das sind bei jedem Hersteller immer die gleichen in der gleichen Version?

    >Da gilt das gleiche wie für normale PC/Mac-Anwendungen: Wenn im System mehr Threads benutzt werden als die CPUs Threads hat (und das ist *immer* der Fall), kommt präemptives zeitscheiben-basiertes Multitasking zum Einsatz.

    >In Anwendungen, die konkret auf Multithreading ausgerichtet sind, kommt übrigens meist eine Thread-Pool-Verwaltung zum Einsatz, die sich an die Anzahl der im System vorhandenen Cores/Threads anpasst -- zur Laufzeit, wohlgemerkt.

    Ist das so? Ich kenne die Implementierung unter Android nicht so en Detail, vor allem weiß ich nicht, was dort native ist und welcher Anteil Java basiert ist. Dürfte auch nicht so einfach sein, aus Assembler Code heraus eine Java API zu bedienen...

  16. Re: Zweikernschwachsinnschwachsinn

    Autor: nate 02.09.11 - 12:57

    > Ich sagte nicht, daß Du Deine C++
    > Anwendung wegen der unterschiedlichen CPUs jedesmal Redesignen mußt, aber
    > um ein Neucompilieren kommst Du nicht drumherum...

    Doch -- denn niemand zwingt den Entwickler, sowohl eine ARMv6- als auch eine ARMv7-Version vorzuhalten. Man kann auch einfach für ARMv6 compilieren und fertig (oder im Zweifelsfall gar ARMv5, das läuft dann *überall*, inklusive Billigst-Chinaware).

    > Wie ist das mit den GUI-Libs? Werden die nicht angefaßt und angepaßt?

    Soweit ich weiß nicht. Das wäre ja auch absolut dämlich, damit würde der Hersteller ja inkompatibel zu existierenden Anwendungen werden.

    > Richtig, und wenn beim Betriebssystem oberhalb des Kernels jeder Hersteller
    > sein eigenen Anpassungen, Erweiterungen und Änderungen machen kann, dann
    > mußt Du auch Deine App anpassen, die diese nutzt.

    Nein, außer man braucht wirklich herstellerspezifische Funktionen. Aber praktisch alles an Peripherie und Funktionen, die man in so einem Smartphone oder Tablet hat (Touchscreen, Telefon, SMS, Kontakte, Internet, Bluetooth, GPS, Beschleunigungs-/Lagesensoren, Kompass, Speicherkarten, Kameras, Audio- und Videoplayback, ...) kann man durch Standard-APIs in den jeweiligen Betriebssystemen erreichen. Herstellerspezifische APIs sind dadurch überflüssig (und auch generell nicht besonders erwünscht).

    > > Und? Mit unterschiedlichen Displayauflösungen muss man sich auf jedem
    > > Smartphone-Betriebssystem auseinandersetzen.
    >
    > Eigentlich nur bei Android... Apple hat das ja geschickt durch die
    > Auflösungs-Verfierfachung umgangen.

    Zwischen 320x480 (iPhone) und 768x1024 (iPad) vermag ich keine Vervierfachung zu erkennen.

    > >Und? Für so ziemlich jede Komponente gibt es APIs vom jeweiligen
    > > Betriebssystem.
    >
    > Und gegen die muß man nicht compilieren? Und das sind bei jedem Hersteller
    > immer die gleichen in der gleichen Version?

    Siehe oben: Es sind bei jedem Hersteller die gleichen, weil es Betriebssystem-APIs sind. Was die Versionen angeht, gilt das gleiche wie bei eigentlich jeder API: Rückwärtskompatibilität.

    > Dürfte auch nicht so einfach sein, aus Assembler Code heraus
    > eine Java API zu bedienen...

    Man muss sich dazu eine kleine Schicht aus prozeduralem Java-Code bauen, die man dann über Callbacks aus dem nativen Code aus aufruft. Nicht besonders schön, zugegeben -- das ist einer der wenigen Aspekte, wo iOS mit seinem konsequenten Native-Code-Konzept den Mittbewerbern klar überlegen ist.

  17. Re: Zweikernschwachsinnschwachsinn

    Autor: Trollversteher 02.09.11 - 13:04

    >Zwischen 320x480 (iPhone) und 768x1024 (iPad) vermag ich keine Vervierfachung zu erkennen.

    Du schriebst aber "Smartphone-Betriebssystem". Denn wenn wir das auf Tablets erweitern, wirst Du durch die Unterschiede zwischen Honeycomb und Ginger bread unter Android bei native Apps deutlich größere Probleme bekommen als nur die Auflösung...

    >Man muss sich dazu eine kleine Schicht aus prozeduralem Java-Code bauen, die man dann über Callbacks aus dem nativen Code aus aufruft. Nicht besonders schön, zugegeben -- das ist einer der wenigen Aspekte, wo iOS mit seinem konsequenten Native-Code-Konzept den Mittbewerbern klar überlegen ist.

    OK, das dachte ich mir - wird ja auch einen Grund dafür geben, daß es so weinige native Apps im Android MArket gibt.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. BWI GmbH, Bonn, Meckenheim
  2. BWI GmbH, bundesweit
  3. AOK - Die Gesundheitskasse in Hessen, Eschborn bei Frankfurt am Main
  4. ekom21 - KGRZ Hessen, Gießen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de
  2. (Samsung 970 EVO PLus 1 TB für 204,90€ oder Samsung 860 EVO 1 TB für 135,90€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Atari Portfolio im Retrotest: Endlich können wir unterwegs arbeiten!
Atari Portfolio im Retrotest
Endlich können wir unterwegs arbeiten!

Ende der 1980er Jahre waren tragbare PCs nicht gerade handlich, der Portfolio von Atari war eine willkommene Ausnahme: Der erste Palmtop-Computer der Welt war klein, leicht und weitestgehend DOS-kompatibel - ideal für Geschäftsreisende aus dem Jahr 1989 und Nerds aus dem Jahr 2019.
Ein Test von Tobias Költzsch

  1. Retrokonsole Hauptverantwortlicher des Atari VCS schmeißt hin

Alexa: Das allgegenwärtige Ohr Amazons
Alexa
Das allgegenwärtige Ohr Amazons

Die kürzlich angekündigten Echo-Produkte bringen Amazons Sprachassistentin Alexa auf die Straße und damit Datenschutzprobleme in die U-Bahn oder in bisher Alexa-freie Wohnzimmer. Mehrere Landesdatenschutzbeauftragte haben Golem.de erklärt, ob und wie die Geräte eingesetzt werden dürfen.
Von Moritz Tremmel

  1. Digitaler Assistent Amazon bringt neue Funktionen für Alexa
  2. Echo Frames und Echo Loop Amazon zeigt eine Brille und einen Ring mit Alexa
  3. Alexa Answers Nutzer smarter Lautsprecher sollen Alexa Wissen beibringen

SSD-Kompendium: AHCI, M.2, NVMe, PCIe, Sata, U.2 - ein Überblick
SSD-Kompendium
AHCI, M.2, NVMe, PCIe, Sata, U.2 - ein Überblick

Heutige SSDs gibt es in allerhand Formfaktoren mit diversen Anbindungen und Protokollen, selbst der verwendete Speicher ist längst nicht mehr zwingend NAND-Flash. Wir erläutern die Unterschiede und Gemeinsamkeiten der Solid State Drives.
Von Marc Sauter

  1. PM1733 Samsungs PCIe-Gen4-SSD macht die 8 GByte/s voll
  2. PS5018-E18 Phisons PCIe-Gen4-SSD-Controller liefert 7 GByte/s
  3. Ultrastar SN640 Western Digital bringt SSD mit 31 TByte im E1.L-Ruler-Format

  1. H2.City Gold: Caetanobus stellt Brennstoffzellenbus mit Toyota-Technik vor
    H2.City Gold
    Caetanobus stellt Brennstoffzellenbus mit Toyota-Technik vor

    Damit die Luft in Städten besser wird, sollen Busse sauberer werden. Ein neuer Bus aus Portugal mit Brennstoffzellenantrieb emititiert als Abgas nur Wasserdampf.

  2. Ceconomy: Offene Führungskrise bei Media Markt und Saturn
    Ceconomy
    Offene Führungskrise bei Media Markt und Saturn

    Die Diskussion um die mögliche Absetzung von Ceconomy-Chef Jörn Werner sollte eigentlich noch nicht öffentlich werden. Jetzt wissen es alle, und es gibt keinen Nachfolger.

  3. Polizei: Hunde, die nach Datenspeichern schnüffeln
    Polizei
    Hunde, die nach Datenspeichern schnüffeln

    Spürhunde können neben Sprengstoff und Drogen auch Datenspeicher oder Smartphones erschnüffeln. Die Polizei in Nordrhein-Westfalen hat kürzlich ihre frisch ausgebildeten Speicherschnüffler vorgestellt.


  1. 18:18

  2. 18:00

  3. 17:26

  4. 17:07

  5. 16:42

  6. 16:17

  7. 15:56

  8. 15:29