1. Foren
  2. Kommentare
  3. PC-Hardware
  4. Alle Kommentare zum Artikel
  5. › Intel Core i7-5960X im Test: Die…
  6. Thema

Mehr Kerne

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Re: Mehr Kerne

    Autor: blaub4r 31.08.14 - 11:40

    Kleines Beispiel: das Spiel "Rift" läuft mit 8 Kernen genauso beschissen wie mit 1 Kern CPU`s.

    Das Problem ist das die Software seit jahren selten mehr als 1 kern Effektiv nutzen tut.

    Solange sich das nicht ändert, sind mehr als 2-4 Kerne nutzlos.

  2. Re: Mehr Kerne

    Autor: Anonymer Nutzer 31.08.14 - 12:24

    siehst du, hier ist der Grund weshalb ich sage, dass du nicht verstehst wie HT funktioniert und dich einlesen sollst!

    HT macht nicht aus einem Kern zwei und teilt die Rechenleistung 50/50 auf, Windows zeigt es nur so an! HT nutzt übrige Rechenzeit, bzw. Wartezeit aus! Du hast deshalb nicht plötzlich einen Zugewinn von 1/8 zu 1/4!!

    Du hast hier einen großen Verständnisfehler von HT!

  3. Re: Mehr Kerne

    Autor: Anonymer Nutzer 31.08.14 - 12:34

    Anfang 2011 steht da! Wir leben im Jahr 2014! Zudem kommt es sehr stark auf das Spiel drauf an. Ich spiele zur Zeit die Prison Architect Alpha, die läuft auf einem Kern, da lohnt es sich tatsächlich das auzuschalten, das ist aber auch schon eine Ausnahme! Zugegeben, auf mehr als 4 Kerne ist kaum ein Spiel optimiert, einige Spiele haben vor einiger Zeit auch das Spielen unter mehr als 4 Kernen komplett verweigert, aber das wird sich zukünftig ändern, allein schon da die Single Core Performance kaum mehr zunehmen wird.

    Wenn du nen modernen i7 hast, der wirklich schnell ist, dann hast du in spiele natürlich eh keine Probleme, da der Prozessor da auch nicht der Flaschenhals sein sollte, je älter dein Proz ist, um so mehr profitieren moderne durch HT.
    Hier hab ich mal eine Analyse dazu gefunden:
    http://www.techbuyersguru.com/CPUgaming2.php

    Bedenke auch, dass dein System und andere Programme auch gleichzeitig immer Rechenzeit belegen. Bei mir laufen aktuell rund 200 Threads. Allein der Browser hat schon 26 Threads offen.

  4. Re: Mehr Kerne

    Autor: Ext3h 31.08.14 - 13:29

    Wirklich gut funktionieren tut das aber auch nicht, von wenigen Ausnahmen mal abgesehen.

    Der Windows-Scheduler hat einfach kein Verständnis dafür welche Threads unabhängig sind und welche nicht.

    Ein sinnvoller Scheduler für HT würde z.B. grundsätzlich versuchen Threads der selben Anwendung immer so weit wie irgendwie möglich NUR auf verschiedene physische Kerne zu verteilen. Egal ob 1. oder 2. Thread pro Kern!

    Und dann den jeweils anderen Thread pro Kern mit einem Thread aus einer anderen Anwendung zu befüllen, da nur damit sicher gestellt werden kann dass die Art der Workload variiert und auch nicht das Problem der versehentlichen Sequentialisierung auftritt - welches für den Performanceeinbruch verantwortlich ist.

    SMT Parking ist dabei nur ein dreckiger Hack. Es nutzt nicht die Vorteile von HT aus - es vermeidet nur HT überhaupt in die Scheduling-Entscheidung mit ein zu beziehen.

  5. Re: Mehr Kerne

    Autor: MarkusXXX 31.08.14 - 15:24

    Kann man das Verhalten des Windows-Schedulers irgendwo nachlesen oder hast Du das selbst ausgemessen? Falls letzteres, mit welchem Tool?

  6. Re: Mehr Kerne

    Autor: Satan 31.08.14 - 15:40

    Würde mich jetzt ehrlich gesagt auch mal interessieren, ob das wirklich stimmt.

    Ich meine, selbst der Standard-Scheduler von Linux ist afaik HT-aware, kann mir kaum vorstellen, dass da ausgerechnet Windows mehr als 10 Jahre nach den ersten HT-fähigen CPUs nicht drauf achten soll.

  7. Re: Mehr Kerne

    Autor: Ext3h 31.08.14 - 16:11

    http://i-web.i.u-tokyo.ac.jp/edu/training/ss/lecture/new-documents/Lectures/03-ThreadScheduling/ThreadScheduling.pdf
    Seite 18

    Das ist immer noch das Verhalten in Windows 8.
    Schritt "c" wurde erstmals in Windows 7 hinzu gefügt.

    Was AFAIK mit Windows 8 noch hinzu gekommen ist, ist dass der Windows-Scheduler AMDs Module ebenfalls wie eine CPU mit HT behandelt.

    Der Scheduler von Windows ist nicht sonderlich ausgereift oder flexibel, das ist nun wirklich kein großes Geheimnis.

    Was meint ihr denn warum es in den letzten Jahren immer wieder als Sensation gefeiert wurde wenn der Windows-Scheduler es überhaupt geschafft hat ein 100, 200 oder 500 CPU-Kernsystem mit trivialen Tasks vollständig aus zu lasten - für Linux gab es schon seit mittlerweile fast 2 Jahrzehnten passende HPC-Scheduler. Für die verschiedenen Unix-Derivate sogar noch länger.

    Defakto bringen auch CPUs mit HT unter Linux schon lange einen wesentlich konsequenteren Performance-Boost als unter Windows.

    Das SMT-Parking verhindert lediglich dass nebenläufige Anwendungen allgemein unter Windows langsamer laufen, aber das auch nur indem HT einfach nicht genutzt wird.



    4 mal bearbeitet, zuletzt am 31.08.14 16:30 durch Ext3h.

  8. Re: Mehr Kerne

    Autor: Coding4Money 31.08.14 - 16:23

    Die Einstiegsfrage bezog sich wohl eher auf den praktischen Nutzen. Gerade wenn man Spiele betrachtet, dann sind weniger Cores mit mehr GHz oft besser, da die aktuelle Software eher schlecht beim Ausreizen mehrerer Cores ist.

  9. Re: Mehr Kerne

    Autor: MarkusXXX 31.08.14 - 17:29

    Ext3h schrieb:
    --------------------------------------------------------------------------------
    > i-web.i.u-tokyo.ac.jp
    > Seite 18

    Danke für den Link.
    Allerdings kann ich das dort beschriebene Verhalten nicht ganz nachvollziehen. Ich habe noch nie beobachtet, dass ein Single-Thread-Prozess immer auf dem selben Kern läuft. Vielmehr läuft der immer abwechselnd auf alle echten Kernen. Laut diesem Dokument würde das bedeuten, dass mindestens 4 andere Threads Rechenzeit wollen, denn erst dann scheduled er den Thread auf einen anderen Kern. Das System war aber ansonsten Idle. Klar läuft da immer ein bisschen was im Hintergrund, aber das sollte nicht gleich vier ganze Kerne wollen.

    > Was meint ihr denn warum es in den letzten Jahren immer wieder als
    > Sensation gefeiert wurde wenn der Windows-Scheduler es überhaupt geschafft
    > hat ein 100, 200 oder 500 CPU-Kernsystem mit trivialen Tasks vollständig
    > aus zu lasten - für Linux gab es schon seit mittlerweile fast 2 Jahrzehnten
    > passende HPC-Scheduler. Für die verschiedenen Unix-Derivate sogar noch
    > länger.

    Die "Sensation" ist das Marketing von Microsoft. Auch das normale 64 CPU Limit von Windows Server liegt nicht am Scheduler, sondern am Test. Sie haben es einfach nicht mit größeren Rechnern getestet.

    > Defakto bringen auch CPUs mit HT unter Linux schon lange einen wesentlich
    > konsequenteren Performance-Boost als unter Windows.

    Kannst Du das näher erläutern? ich habe noch nie Benchmarks gesehen, bei denen Linux dank HT schneller als Windows war.

    > Das SMT-Parking verhindert lediglich dass nebenläufige Anwendungen
    > allgemein unter Windows langsamer laufen, aber das auch nur indem HT
    > einfach nicht genutzt wird.

    Natürlich wird HT unter Windows genutzt. Ich sehe folgendes Verhalten:
    Solange noch echte Kerne vorhanden sind werden diese genutzt. Wenn keine mehr übrig sind wird auch HT benutzt. Das klingt für mich sinnvoll.

  10. Re: Mehr Kerne

    Autor: Ext3h 31.08.14 - 20:57

    MarkusXXX schrieb:
    --------------------------------------------------------------------------------
    > > Das SMT-Parking verhindert lediglich dass nebenläufige Anwendungen
    > > allgemein unter Windows langsamer laufen, aber das auch nur indem HT
    > > einfach nicht genutzt wird.
    >
    > Natürlich wird HT unter Windows genutzt. Ich sehe folgendes Verhalten:
    > Solange noch echte Kerne vorhanden sind werden diese genutzt. Wenn keine
    > mehr übrig sind wird auch HT benutzt. Das klingt für mich sinnvoll.
    Nur bedingt. Bei <50% Last macht das Sinn. Bei >50% Last fängt der Scheduler an, falsche Entscheidungen zu treffen, da er darauf ausgelegt ist HT zu vermeiden - nicht es sinnvoll zu nutzen.

    Der CFQ-Scheduler für Linux ist SMT-aware und kommt von der Performance her bei den meisten Anwendungen auf einen optimalen Wert, sprich er ist genauso schnell als ob wenn man die Threads manuell pinnen würde, und zwar auch für mehr als die Anzahl der physischen Kerne, insofern man den zusätzlichen Overhead für L2 und L3 misses Aufgrund nun zu kleiner Caches sowie generellen Overhead für Semaphoren außen vor lässt:
    http://blog.stuffedcow.net/2011/08/linux-smt-aware-process-scheduling/

    Ist allerdings allgemein jetzt ein Problem da aussagekräftige Benchmarks zu zu finden, sowohl unter Windows als Linux, da die ganzen synthetischen Tests keine Workload produzieren die wirklich HT-freundlich wäre.
    Zudem werden gerade die HPC-Benchmarks unter Windows gerne mit manuell gepinnten Threads ausgeführt, was dann natürlich (ganz bewusst) keine Aussage über die Qualität des Schedulers erlaubt.
    Zuletzt dann natürlich dann noch das Problem dass die 12-25% die HT in der Praxis liefern kann verschwindend gering sind, im Vergleich zu anderen Problemen und hauptsächlich dann zum tragen können, wenn die Workload aus unterschiedlichen Anwendungen stammt.

    Wer sich dazu berufen fühlt, kann gerne mal Whetstone und Dhrystone jeweils mit der Anzahl der nativen Kerne parallel gleichzeitig auf einer HT-fähigen CPU ausführen, und schauen wie gut die Scheduler unter Windows und Linux (CFQ-Scheduler) jeweils skalieren. Das sollte eine für HT gut geeignete Workload sein. Kann ich selber leider nicht testen, mangels HT.
    Referenzwert ist manuelles Pinning der Threads wobei ein Benchmark die physischen und der andere die "virtuellen" bekommt. Egal in welcher Reihenfolge, im Prozessor sind die dann ja wieder gleichwertig.
    Der Scheduler hat versagt, sobald er zwei Threads mit gleicher Workload auf dem selben Kern platziert.



    2 mal bearbeitet, zuletzt am 31.08.14 21:07 durch Ext3h.

  11. Re: Mehr Kerne

    Autor: RobertFr 01.09.14 - 01:33

    Ext3h schrieb:
    > Ein sinnvoller Scheduler für HT würde z.B. grundsätzlich versuchen Threads
    > der selben Anwendung immer so weit wie irgendwie möglich NUR auf
    > verschiedene physische Kerne zu verteilen. Egal ob 1. oder 2. Thread pro
    > Kern!

    Tja, das würde der Dir so erscheinende "sinnvolle Scheduler" tun, wenn es denn dann wirklich das ultimative Performance-Kriterium wäre.

    Aber das ist es nunmal nicht, weil in der Praxis andere Kriterien sehr viel wichtiger sind als das optimale Reordering von Instruktionen (was halt die Grundlage von Hyperthreading ist).

    Wichtiger und sehr viel relevanter sind nunmal alle Spielarten von Zugriffen auf den Hauptspeicher.

    Deshalb wäre Deine Idee eines Hyperthreading-Aware Scheduler, der die Aufgaben-Scheibchen jeweils so verteilen würde, dass HT optimal gut funktionieren würde (also auf möglichst entfernte physische Kerne...), diese Idee wäre vielleicht einen Versuch wert, würde aber in einer äußerst lahmen Gesamtperformance enden, bei der das Bottleneck schlicht in extrem vielen unnötigen Cacheline-Fetches enden würde.

    Fazit: nette Idee, aber nachweislich Unfug.

    Mehr gibts dazu kaum zu sagen.

  12. Re: Mehr Kerne

    Autor: gaym0r 02.09.14 - 15:24

    Cerdo schrieb:
    --------------------------------------------------------------------------------
    > JouMxyzptlk schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Sharra schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Mal von 3D-Anwendungen, Videobearbeitung und ähnlichem abgesehen,
    > lohnen
    > > > sich so viele Kerne für den Normalanwender/Zocker? Oder sind 4 Kerne
    > mit
    > > > höherem Takt sinnvoller?
    > >
    > > Letzteres ist sinnvoller, mehr GHz statt mehr cores.
    > In fünf Jahren wird es deshalb Standard-Prozessoren mit 32 Kernen und mehr
    > geben. Mehr als 3,8 GHz wird aber keiner haben, normal sind wohl eher bis
    > zu 3,4 GHz, da der Energieverbrauch (und die Hitzeentwicklung) dann viel
    > niedriger ist.

    Ja natürlich. :-D Vor 8 Jahren sind die ersten DualCores auf den Markt gekommen, inzwischen sind wir bei 2-4 Kernen bei "Standard"-CPUs (was ist das überhaupt für ein Begriff?) und 12 Kernen bei professionellen CPUs.
    Und jetzt willst du in 5 Jahren zu 32 Kernen?

  13. Das ist absolut irrelevant...

    Autor: Crass Spektakel 02.09.14 - 18:18

    Ob ein OS die Prozesse mal neu verteilt ist aber sowas von total scheissegal dass mir dafür die Adjektive fehlen.

    Kleine Anektote, so zwischen 1995 und 2005 haben wir auf SMP-System mal getestet wie viel die anfallenden Kontext-Wechsel ausmachen, getestet vom Dual-Sparc 100Mhz System über Dual-Pentium 233Mhz, Quad-PPro-Systeme bis zuletzt ein Xeon-System mit 4x2400Mhz.

    Und nirgends brachte das manuelle Verteilen einen Vorteil. Dafür brachte es sehr oft einen geringen Nachteil.

    Gaaanz kurz gabs Probleme als asymetrische Threats aufkamen (z.B. Hyperthreading, NUMA) und zwar genau dann wenn man einen zu alten Kernel verwendete, egal ob Windows, Linux, BSD, Solaris oder sonstwas. Aber alles was nach Windows 2000 und Linux 2.2 kam kann damit einfach gut umgehen. Inzwischen ist es so dass KEIN MENSCH so effizient die Rechenleistung verteilen kann wie ein guter Processscheduler einfach weil unendlich viele Randeffekte reinspielen.

    Beispiel, ein Prozess läuft auf einer CPU welche Hyperthreading und NUMA unterstützt (z.B. Dual-Xeon oder Dual-Opteron). Ein bestimmter Prozess soll maximale Rechenleistung bekommen. Je nachdem ob der Prozess alleine läuft oder unter vielen läuft oder unregelmässig von anderen Prozessen gestört wird kann es vorteilhaft sein den Prozess zwischen CPU-Kernen aber auch Speicher-Segmenten durchzutauschen. Das kostet zwar ein paar Taktzyklen aber anschliessend bekommt die CPU eben wirklich mehr vom Kuchen. Einen Prozess auf einen Kern zu binden hingegen bedeutet im schlimmsten Fall dass ein anderer Prozess den Kern mittels Hyperthreading teilt und deutlich bremst und das RAM eigentlich an der anderen CPU hängt und mit deutlicher Verzögerung und Umwegen darauf zugegriffen werden muss. Unter Linux wird auf solchen recht komplexen Systemen mehrmals pro Sekunde Short-Penalty und Long-Profit für einen Context-Wechsel berechnet und wenn es sich lohnt wird der Prozess nicht nur auf eine andere CPU verschoben sondern auch auf einen anderen RAM-Bus oder einen komplett anderen Rechner über Ethernet.

    Daher reicht es heute IMMER einem Prozess einfach eine hohe Prioriät zu geben, den Rest kann das System besser.

  14. Re: Mehr Kerne

    Autor: Crass Spektakel 02.09.14 - 18:30

    HerrMannelig schrieb:
    --------------------------------------------------------------------------------
    > HT macht nicht aus einem Kern zwei und teilt die Rechenleistung 50/50 auf,
    > Windows zeigt es nur so an! HT nutzt übrige Rechenzeit, bzw. Wartezeit aus!

    Das ist gut formuliert, ich überspitze es mal, Hyperthreading nimmt einen Kern und teilt seine Leistung NICHT 50% zu 50% auf zwei virtuelle Kerne sondern 66% zu 66%, erreicht also 133% eines einzelnen Kerns.

    Und das aber auch nur wenn beide Kerne belastet werden, wird nur einer belastet bekommt er trotzdem 100%. Windows und Linux gehen dabei sehr geschickt vor und verschieben Prozesse im laufendem Betrieb so dass sie auf unbenutzten physikalischen Prozessoren laufen und dann mit 100% laufen. Erst wenn die physikalischen CPUs "ausgehen" werden die virtuellen genutzt und man bekommt 133%.

    > Du hast hier einen großen Verständnisfehler von HT!

    Ganz ehrlich, viele "Poweruser" haben keine Ahnung von HT, NUMA und Beowulf. Ist wohl der Unterschied der Overclocker-Guru (*1), Market-Droiden (*2) und Numbercruncher-Profi (*3) unterscheiden..

    (*1) "boah ey ich hab auf 5Ghz übertaktet" "aber unter welchen Rahmenbedingungen und zu welchem Zweck?" "flüssiger Stickstoff und CPU-Burn läuft 12 Minuten ohne Absturz!"

    (*2) "Multi-Core ist die Zukunft" "aber warum sollen 18 Kerne mit 1,33Ghz für 6500 Euro besser sein als 6 Kerne mit 4,00Ghz für 300 Euro?" "Sehen sie dafür habe ich eine Powerpoint-Präsentation vorbereitet..."

    (*3) "Wieviel Bang per Buck bekomme ich bei ihnen?" "12 Aberfantastillionen Specint pro Dollar" "Wie zuverlässig?" "10^-21 Errors pro Sekunde über die ersten fünf Jahre" "Ok nehme ich".

  15. Re: Mehr Kerne

    Autor: Crass Spektakel 02.09.14 - 18:36

    HerrMannelig schrieb:
    --------------------------------------------------------------------------------
    > Anfang 2011 steht da! Wir leben im Jahr 2014! Zudem kommt es sehr stark auf
    > das Spiel drauf an. Ich spiele zur Zeit die Prison Architect Alpha, die
    > läuft auf einem Kern, da lohnt es sich tatsächlich das auzuschalten

    Prision Architekt läuft sogar auf einem Atom-Netbook von Anno Tobak, welchen greifbaren Vorteil bringt Dir da die Deaktivierung von von Hyperthreading auf einem i7 mit 4000Mhz?

    >, das
    > ist aber auch schon eine Ausnahme! Zugegeben, auf mehr als 4 Kerne ist kaum
    > ein Spiel optimiert, einige Spiele haben vor einiger Zeit auch das Spielen
    > unter mehr als 4 Kernen komplett verweigert,

    Ich verwende seit vier Jahren Rechner mit acht Kernen zum Spielen und habe keine Ahnung wovon Du redest. Grobe Faustregel, wenn ein Spiel so alt ist dass es von vielen Kernen nicht profitiert dann braucht es nichteinmal einen Bruchteil der Leistung aktueller Kerne.

    > Wenn du nen modernen i7 hast, der wirklich schnell ist, dann hast du in
    > spiele natürlich eh keine Probleme, da der Prozessor da auch nicht der
    > Flaschenhals sein sollte, je älter dein Proz ist, um so mehr profitieren
    > moderne durch HT.

    EVE-Online hat schon vor 10 Jahren davon profitiert auf einem Hyperthreading-Rechner zu laufen.

    > Bedenke auch, dass dein System und andere Programme auch gleichzeitig immer
    > Rechenzeit belegen. Bei mir laufen aktuell rund 200 Threads. Allein der
    > Browser hat schon 26 Threads offen.

    Und wenn die zusammen 10% eines einzelnen Kerns belegen who cares?

  16. The first time you'll get a Microsoft product

    Autor: Crass Spektakel 02.09.14 - 18:38

    Auf 'ne Cola schrieb:
    --------------------------------------------------------------------------------
    > Wieso wird mein System bei einer sta nur zu 12,5% belastet?

    Weil der Windows-Taskmanager ein Microsoftprodukt ist und nur Mist anzeigt.

    The first time you'll get a Microsoft product, that doesn't suck will be the day they start producing vacuum cleaners.

  17. Worst-Case

    Autor: Crass Spektakel 02.09.14 - 18:47

    Ext3h schrieb:
    --------------------------------------------------------------------------------

    > Der CFQ-Scheduler für Linux ist SMT-aware und kommt von der Performance her
    > bei den meisten Anwendungen auf einen optimalen Wert

    Bei den Linux-Schedulern macht das vieleicht 5% in der Praxis auseinander, sogar wenn man den CFQ im Best-Case und Roundrobin im Worst-Case vergleicht :-)

    "Wunder" bringen Scheduler keine zustande aber zugegebenermassen geben sie dem ganzen den besten Schliff und dass Linux hier weit führt wagt niemand zu bestreiten.

    > sprich er ist genauso
    > schnell als ob wenn man die Threads manuell pinnen würde, und zwar auch für
    > mehr als die Anzahl der physischen Kerne, insofern man den zusätzlichen
    > Overhead für L2 und L3 misses Aufgrund nun zu kleiner Caches sowie
    > generellen Overhead für Semaphoren außen vor lässt:

    Richtig witzig ist der in Python implementierte Bloath-Scheduler für Beowulf-Systeme, der gewichtet sogar ein ob es lohnt einen Prozess per Ethernet auf einen anderen PC zu transferieren, abhängig von der gerade verfügbaren Ethernet-Bandbreite :-)

    > Der Scheduler hat versagt, sobald er zwei Threads mit gleicher Workload auf
    > dem selben Kern platziert.

    Nicht unbedingt. Threats mit ähnlichem Zugriffsmuster auf RAM und Cache können unter umständen sogar davon profitieren wenn sie per HT auf dem gleichen Kern laufen. Ist aber eher esotherisch, der Vorteil liegt wohl unter einem Promille und selbst CFQ gewichtet das nicht.

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. MEHR Datasystems GmbH, Düsseldorf
  2. Matthews Kodiersysteme GmbH, Estenfeld
  3. ix.mid Software Technologie GmbH, Köln
  4. Allianz Deutschland AG, Unterföhring, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Hisense 70-Zoll-LED (2020) für 669,99€, Beats Kopfhörer günstiger)
  2. Am Black Monday bis zu 20 Prozent Rabatt auf TV & Audio
  3. (u. a. Beats Studio3 Over Ear Bluetooth für 189€, Powerbeats Pro kabellose In-Ear-Bluetooth...
  4. (u. a. Crusader Kings III - Royal Edition für 42,99€, Mount & Blade II - Bannerlord für 27...


Haben wir etwas übersehen?

E-Mail an news@golem.de


iPhone 12 Pro Max im Test: Das Display macht den Hauptunterschied
iPhone 12 Pro Max im Test
Das Display macht den Hauptunterschied

Das iPhone 12 Pro Max ist größer als das 12 Pro und hat eine etwas bessere Kamera - grundsätzlich liegen die beiden Topmodelle von Apple aber nah beieinander, wie unser Test zeigt. Käufer des iPhone 12 Pro müssen keine Angst haben, etwas zu verpassen.
Ein Test von Tobias Költzsch

  1. Touchscreen und Hörgeräte iOS 14.2.1 beseitigt iPhone-12-Fehler
  2. iPhone Magsafe ist nicht gleich Magsafe
  3. Displayprobleme Grünstich beim iPhone 12 aufgetaucht

Elektrisches Carsharing: We Share bringt den ID.3 nach Berlin
Elektrisches Carsharing
We Share bringt den ID.3 nach Berlin

Während Share Now seine Elektroautos aus Berlin abgezogen hat, bringt We Share demnächst den ID.3 auf die Straße. Die Ladesituation bleibt angespannt.
Ein Bericht von Friedhelm Greis

  1. Verbraucherschützer Einige Elektroautos sind nicht zuverlässig genug
  2. Innovationsprämie Staatliche Förderung drückt Preise gebrauchter E-Autos
  3. Papamobil Vatikan will auf Elektroautos umstellen

Logitech G Pro Superlight im Kurztest: Weniger Gramm um jeden Preis
Logitech G Pro Superlight im Kurztest
Weniger Gramm um jeden Preis

Man nehme das Gehäuse der Logitech G Pro Wireless und spare Gewicht ein, wo es geht. Voilá, fertig ist die Superlight. Ist das sinnvoll?

  1. Ergo M575 im Test Logitechs preiswerter Ergo-Trackball überzeugt
  2. MX Anywhere 3 im Test Logitechs flache Maus bietet viel Komfort
  3. MK295 Logitech macht preisgünstige Tastatur-Maus-Kombo leiser