News Intel: Erster Prozessor mit acht Kernen

CHAOSMAYHEMSOAP schrieb:
Genau darum ist IBM aus dem Desktopmarkt ausgestiegen. :rolleyes:

Aber sicher ist es besser, wenn man mit Desktop CPUs für Blödkunden weniger Geld verdient als mit Server CPUs.

Dumpfbacken will weder AMD noch Intel mit Server CPUs ansprechen. Sun und IBM übrigens auch nicht. :rolleyes:

Du verdrehst irgendwie die Tatsachen.

Intel ist im Servermarkt bei Server Prozessoren momentan wesentlich stärker als AMD.

Intel ist in folgenden 3 Märkten extrem gut aufgestellt:

Mobile
Desktop (Core 2 Quad, Duo, Desktop Xeons)
Server/Workstation (Quadcore > Harpertown, 6 Kern CPU´s)

Selbst die großen Hersteller wie IBM, Dell und HP haben überwiegend Server mit Intel Prozessoren. Weil da zurzeit auch im Serverbereich die P/L und Zuverlässigkeit weitaus besser als bei AMD ist. Stichwort Green IT und Leistung pro Watt.

Es wird momentan im Mobile/Desktop Markt sehr viel Umsatz gemacht. IBM ist ja nicht direkt aus dem Desktop/Mobile Markt ausgestiegen sondern Lenovo entwickelt das genau nach IBM Vorgaben weiter da IBM bei Lenovo mit im Boot sitzt.

Auf dem Server Markt wird sicher auch sehr viel Geld verdient (keine Frage) dennoch wird auch verdammt viel mit Desktops und die letzten Jahre insbesondere mit Notebooks verdient.

Da du noch auf andere Dinge ausserhalb von x86 Aufmerksam machst z.B. IBM PowerPC sowas ist nur im HPC Bereich mit speziell darauf optimierten Anwendungen sinnvoll und leistungsfähig. Für wie sagt man so schön Mainstream Server Apps ist nach wie vor die x86 Architektur führend.
 
Zuletzt bearbeitet:
Chris_87 schrieb:
[ ] Hyperthreading ist dir bekannt :p

Meinem Atom Singlecore diagnostiziert der Taskmanager und dxdiag auch einen 2. Kern

aber auch unter der Beschreibung stand 8 CPUs ( also bei dieser Komponentenliste )
 
8 theoretische, ja. Sowas wird bei Blödmarktprospekten gern unterschlagen. Ebenso wie, ach so tolle GT130 mit 1536MB VRam....so eine Zahl muss ja schnell sein.
 
Azi schrieb:
Eigentlich ist es eher so dass die GPU sich immer mehr in Richtung CPU entwickelt.
Was sich in welche Richtung entwickelt spielt keine so große Geige, da massiv-parallele Aufgaben sich daheim eher nur auf Audio/Video beschränken. Und 3D-Grafik ;) Eine GPU kann nur Aufgaben beschleunigen die sich als gut "parallelisierbarer" Stream zerstückeln lassen.

Auch 2009 ist die Aufteilung von Integerberechnungen auf mehr als 2 Kerne extrem schwierig. Deswegen wird es zB. auch nie einen WinRAR & Co geben der auf GPUs läuft. usw. usw. Mit Gleitkoma sieht es oft nicht viel besser aus.

Die ganzen multithreaded Multicores, Multi hier Multi blah, bringen uns daheim kaum etwas, weil noch niemand einen blassen schimmer hat wie man dafür für einzelne Aufgaben verteilen/programmieren soll.

Schön wenn man mit Apache so einen Xeon auslasten kann, aber noch schöner ist ein UltraSPARC T2 mit 8 Cores, 64 Threads (!), multithreaded 2x 10 GB und pro Core eine zusätzliche SSL-Beschleunigung und FPU und für jedes Core-pärchen einen eigenen Memcontroller. Alles auf einem Chip. Mit max. 123W pro CPU und daher max. 2W pro Thread bei 1.4 Ghz. Im Schnitt sind es 95W und 1.5W pro Thread.
Klar wird damit der nächste Numbercruncher nicht gebaut, aber wenn ich mit einem Server aka Datenschleuder wuchern will, dann bestimmt nicht mit so einer Energieschleuder wie der Xeon.

Der nächste überragende Numbercruncher wird überigens auch mit dem nicht gebaut. Man nimmt dafür momentan am besten einen durchschnittlichen X2 Opteron der jeweils als Sklave für 2x PowerXCell 8i fungiert. So wird man Nummer 1 in der Top500 und braucht dafür die Hälfte der Energie als der zweitplatzierte.

Geilt euch also an dem Text von Wolfgang (?) nicht so auf. Die einzige Daseinberechtigung für so eine CPU ist WindowsServer. Fortschrittliche Servertechnik interessiert sich weder für so einen Xeon noch für WindowsServer.

Gute Nacht, Stammtisch.
 
Zuletzt bearbeitet:
@ Crycher

Genau wegen Leuten wie dir schreiben sie das mit den 8 CPUs auch darunter... 8 Cores wäre schon nicht richtig, aber 8 CPUs ist komplett falsch, das ist von Saturn eine bewusste Täuschung der Kunden. Ein Core i7 hat 4 Kerne und kann auf jedem dieser Kerne noch einen weiteren, zusätzlichen Thread ausführen --> Hyperthreading. Deshalb werden auch 8 Kerne angezeigt, von denen sind 4 physikalisch und 4 logisch. Aber er ist damit meistens nicht viel schneller als ein normaler QC ohne Hyperthreading und auf jeden Fall langsamer als ein echter Octacore. Und nebenbei bemerkt: Dieses Teil hier is auch nicht für den MacPro geeignet, da der eine DualProzessor-Workstation ist. Dieser Xeon entspringt allerdings der 7000er Serie, ist also für Multi-CPU-Systeme gedacht.
 
BeeHaa schrieb:
Auch 2009 ist die Aufteilung von Integerberechnungen auf mehr als 2 Kerne extrem schwierig. Deswegen wird es zB. auch nie einen WinRAR & Co geben der auf GPUs läuft. usw. usw. Mit Gleitkoma sieht es oft nicht viel besser aus.

In warte schon lange auf eine Art EPU - eine Encryption & Compression Unit.

Dieses Teil kann entweder gängige Algorithmen per Hardware durchlaufen oder vorab mit einem custom Algorithmus initialisiert werden und macht dann nichts anderes als einen Datenstream von A nach B zu schleifen.

Am besten direkt und analog zur FPU in die CPU integriert und mit direktem Speicherzugriff.

Können gerne zusammen mal ein Patent aufsetzen :)
 
IntelFreak87 schrieb:
Du verdrehst irgendwie die Tatsachen.
Oh really?
IntelFreak87 schrieb:
Intel ist im Servermarkt bei Server Prozessoren momentan wesentlich stärker als AMD.
Sorry, mir ist scheinbar entgangen, daß das hier ein Intel vs. AMD Thread werden soll.

Aber da ich ja nur auf:
Versteh ich trotzdem nicht, da man doch gerade im Desktopmarkt Geld machen kann...
und auf
Ganz ehrlich. Was hat man davon? ... Mir ist es nicht aufgefallen, dass z.B. Spiele Quad-Core-CPUs unterstützen. ...
geantwortet habe, muß ich die Intel vs. AMD Geschichte wohl übersehen haben. :rolleyes:

IntelFreak87 schrieb:
Weil da zurzeit auch im Serverbereich die P/L und Zuverlässigkeit weitaus besser als bei AMD ist. Stichwort Green IT und Leistung pro Watt.
Wenn es um Zuverlässigkeit geht, liegen Welten zwischen Mainframes und x86 Schrott.
Bei der Leistung/Watt soll AMD übrigens ganz gut mithalten können, aber Suns UltraSPARC T2 dürfte da auch recht gut abschneiden.

IntelFreak87 schrieb:
Es wird momentan im Mobile/Desktop Markt sehr viel Umsatz gemacht.
Umsatz ist nicht Gewinn.
IntelFreak87 schrieb:
Auf dem Server Markt wird sicher auch sehr viel Geld verdient (keine Frage) dennoch wird auch verdammt viel mit Desktops und die letzten Jahre insbesondere mit Notebooks verdient.
Darum hat sich IBM auch vom PC-Geschäft getrennt und machte im letzten Quartal 2008 mehr Gewinn als Intel und AMD zusammen.
IntelFreak87 schrieb:
Da du noch auf andere Dinge ausserhalb von x86 Aufmerksam machst z.B. IBM PowerPC sowas ist nur im HPC Bereich mit speziell darauf optimierten Anwendungen sinnvoll und leistungsfähig. Für wie sagt man so schön Mainstream Server Apps ist nach wie vor die x86 Architektur führend.
Solange die wichtigsten Programme auch auf POWER und SPARC laufen, braucht man kein x86 + Windows. Wenn es um Zuverlässigkeit geht, zieht x86 + Windows eh den Kürzeren.
Im Übrigen muß man die Software auch bei x86 Servern optimieren, wenn man 4 CPUs (wohlmöglich noch mit je 4 Cores à 2 Threads) voll ausnutzen will.
RISC Systeme haben da zumindest den Vorteil, daß sie schon seit längerem mehrere CPUs mit SMT unterstützen und die Hardware z.T. einen höheren Durchsatz ermöglicht.
waRhawK schrieb:
Am besten direkt und analog zur FPU in die CPU integriert und mit direktem Speicherzugriff.
Siehe UltraSPARC T2 oder IBM z10
 
Irgendwer meinte, die CPU wäre teuer... dabei denke ich das man den Gesamtpreis und die erhaltene Leistung betrachten muss. Der Kostenaufwand mehrere CPU zu verbauen um die Leistung um einer 8kern cpu zu erreichen sollte auch nicht vernachlässigt werden.

Würde man sich z.b. ein server zusammen setzen mit 16 Kernen, bräuchte man ein mainboard mit 2 Sockel, was oft noch relativ einfach zu bekommen ist.
Mit welchen die "nur" 4 beinhalten wäre der technische Aufwand nun auch viel höher, ein Board herzustellen, auf dem 4 CPU passen und allem anderen was bedarf... aufwand hoch -> kosten hoch.

An sich ist das eine feine Sache.
 
192.168.1.1 schrieb:
Aber er ist damit meistens nicht viel schneller als ein normaler QC ohne Hyperthreading und auf jeden Fall langsamer als ein echter Octacore.

Ich dachte auch die vier HT-Kerne + die vier echten des i7 können einem echten 8-Kerner nicht das Wasser reichen. Naja, hier mal WPrime mit meinem Dual-Xeon X5460 System (3,166GHz * 8 Kerne):

wprime.jpg


Im Vergleich nen WPrime von einem i920 @ 3,5GHz, also vier Kerne + vier HT-"Kerne":

17297wPrime200_i7_3500JPG


Man sieht, der i920 ist fast dran! :freak:
 
Zuletzt bearbeitet:
Huh, die Vorboten von Prozessoren mit verschiedenen Bestückungen (Core´s und GPU´s auf einem Die) die dann auf Ihre tatsächlichen Aufgabenbereiche zugeschnitten werden können.
Je nach nach Bedarf oder Aufgabenbereiche wird es dann mal Die´s geben die entweder mehr Core´s oder mehr GPU´s aufweisen um z.b. Videobearbeitung, Wissenschaftliche Berechnungen oder schlimmstenfalls dazu benutzt werden können um Passwörter schneller zu knacken.

AMD und auch Intel haben für die nächsten Jahre noch so einiges vor was das betrifft, aber der eigentliche Vorreiter ist der Cellprozessor der u.a. schon in PSP 3 seinen Dienst tut.

Desweiteren tragen diesen neuen Die´s dann auch dazu bei die Miniaturisierung weiter voran zu treiben, für Anwendungen in Notebook´s und andere Mobile Gerätschaften. Darüber wurde auch schon in mehreren Publikationen berichtet. Leute lest einfach mal wieder ein bißchen mehr. ( Ironie)
 
Vitec schrieb:
Für mich als pc gamer höchstens in 3 jahren interessant ;)

:lol:
Das nenn' ich Zweckoptimismus!
Träumt ruhig alle weiter... In 3-4 Jahren müssen wir froh sein, wenn sich der Quadcore
überhaupt als Standard bei der gängigen Software etabliert hat.
Denn sofern sich beim Thread-Handling der aktuellen CPUs nicht demnächst erhebliche Verbesserungen einstellen hat sich das Thema vorerst sowieso erledigt. Da können wir noch 10 Jahre auf den "Octa-Core" warten. Auch bei Spielen! Wer ist schon so bekloppt und programmiert für 8 oder gar 16 Kerne die jeweils noch 2 "simultane" Threads beherrschen?
Ernsthaft Leute, ihr spinnt. :freak:
Nix für ungut - aber der Boden der Realtität sollte bei all dem Überschwang nicht verlassen werden. Unbestritten - für die Server ist das genau die richtige Entwicklung.
-> Genial! Super! Toll! Bombastisch!
Beim Privatanwender oder im Büreinsatz habe ich jedoch - nicht grundlos - ganz erhebliche Zweifel.
 
CHAOSMAYHEMSOAP schrieb:
Darum hat sich IBM auch vom PC-Geschäft getrennt und machte im letzten Quartal 2008 mehr Gewinn als Intel und AMD zusammen.

Das ist jetzt nicht dein ernst, oder? Du kennst dich vielleicht mit Computern aus aber da geht es um Betriebswirtschaft. IBM verdient nach wie vor am Lenovo PC Geschäft mit weil IBM sehr große Firmenanteile an Lenovo hält. IBM hat das Geschäft mehr oder weniger nur mit den eigenen Produktnamen in eine andere Firma ausgelagert die zu IBM gehört und wo IBM mitverdient.

IBM ist einer der weltweit größen Dienstleister und schon fast eine Unternehmensberatung. Mit dem Verkauf von Servern selbst macht IBM nicht den größten Teil seines Umsatzes und Gewinn.

So wie du es schreibst kann man das nicht sehen.


CHAOSMAYHEMSOAP schrieb:
Solange die wichtigsten Programme auch auf POWER und SPARC laufen, braucht man kein x86 + Windows. Wenn es um Zuverlässigkeit geht, zieht x86 + Windows eh den Kürzeren.
Im Übrigen muß man die Software auch bei x86 Servern optimieren, wenn man 4 CPUs (wohlmöglich noch mit je 4 Cores à 2 Threads) voll ausnutzen will.
RISC Systeme haben da zumindest den Vorteil, daß sie schon seit längerem mehrere CPUs mit SMT unterstützen und die Hardware z.T. einen höheren Durchsatz ermöglicht.

Siehe UltraSPARC T2 oder IBM z10

Seltsam. Seit die x86 Architektur 64 Bit hat, Quadcores und sogar schon 6 Kerner wird Sparc, Power usw. viel weniger verkauft.

Mittlerweile ist es Tatsache, dass x86 Systeme oft weitaus leistungsfähiger sind als Sparc oder Power Systeme. Früher war das mal anders aber mittlerweile ist x86 so stark wie noch nie zuvor.

Bezüglich Zuverlässigkeit: Wir haben einige IBM Server (5000P oder 5400 Chipsatz) mit Xeon Quadcores, FB-DIMM und Probleme bezüglich Zuverlässigkeit hatten wir mit den Teilen nie und das seit Jahren. Die laufen 24/7 mit Windows Server und manche RHEL 4 und 5 und keinerlei Probleme was die Zuverlässigkeit betrifft.

Das zum größten Teil in der x86 Welt Desktop kram zum Teil wirklich der allerletzte Mist ist.. da muss man zum Teil leider zustimmen aber nicht im Serverbereich.

Und um da mal Sun als Beispiel zu nennen: Die machen momentan nur Verluste und Sun ist zu 70-80% nur im Serverbereich tätig. Da läuft mit SPARC nicht mehr viel oder was meinst du warum Sun auf einmal so viele x86 Server im Angebot hat? Weil sie mit Sparc so viel verdienen das es reicht?
 
Zuletzt bearbeitet:
Ich bin ja immernoch der meinung dass man langfristig das threadhandling nicht in der software sondern direkt im OS regeln muss, auch wenn ich aus heutiger sicht nicht weiß wie genau man das realisieren kann.
Aber dann wäre man endlich so weit dass das OS wirklich die volle vorhandene rechenpower optimal zuteilen kann und das völlig unabhängig von der verwendeten software.
 
Den gibts aber schon lange, habe den in meinem Mac Pro drinen .. :)
3D Modelling, Maya und Mudbox profitieren davon einfach genial ...

weiter so intel.. :cool_alt:
 
@ NoD.sunrise

Das wird es nie geben. Und Wenn es so ein Betriebssystem gibt, dann wird da kaum Software drauf laufen.

Oder es würde dann auf dem OS so gut wie keine Software laufen.

Heutzutage stellt das OS eigentlich nur die Plattform da. Der Scheduler von Linux oder Windows arbeitet schon sehr effektiv und sinnvoll.

Aber multithreaded Code müssen die Programm Hersteller schon selber schreiben.

Da kann das OS überhaupt nichts machen.
 
@ tommy_v6

Das Problem dürfte darin bestehem das 2 CPUs gegen 1 CPU antreten, wärend die 2 CPUs sind untereinander verständigen müssen muss das die Core i7 nicht und kann alleine ihr ding durchziehen. Zudem is ne i7 sowieso ne völlige Ultra-CPU [BSP. Core i7 965 XE von EVGA @ 4025 MHZ das sind 4 Kerne mit HT (3DVantage Score ~ 36000)] ich weis nicht ob meine Q9300 besser ist als die 920 i7 ich wage es zu bezweifeln ... (Selbt wenn ich meien Q9300 auf 3Ghz hochziehe)
 
@ NoD.sunrise & IntelFreak87
Boah, herrlich! Es gibt offensichtlich 2 Menschen, die das Grundproblem begriffen haben!

Die Lösung dieses Problems ist in der Tat eine heikle Sache.
Ich bin nämlich genauso ratlos - würde aber wie NoD.sunrise zu einer Betriebssystemoreintierten
Lösung tendieren. Das OS in seiner Funktion als "große Klammer" ist die einzig sinnvolle Ebene um ein
effizientes Thread-Management zu intallieren. Wie das allerdings auf absehbare Zeit realisiert werden kann...
naja... ?

Die heutigen Sheduler von Win./ Linux sind alles andere als effektiv und sinnvoll.
Je höher die Kernzahl, desto stärker fallen die Schwächen ins Gewicht. Aktuell sind
wir mit dieser Technik mitnichten in der Lage ins große "Multicore-Zeitalter", das hier alle
ständig ausrufen, vorzustoßen!
Es müssen also neue Ansätze her. Denn wenn es tatsächlich dabei bleiben sollte
Aber multithreaded Code müssen die Programm Hersteller schon selber schreiben.
dann geht es definitiv nicht vorwärts!

Dann dürften nämlich viele CBler bis an ihr Lebensende völlig umsonst von ihrem tollen 128-Core Heim-PC weiterträumen. :evillol:
[Die stumpfsinnige Pseudoargumentation von Parallelbearbeitung durch den User (wie z. B. von den unzähligen Verfechtern des Quad-Core) könnt ihr euch in dem Fall nämlich auch schenken.]

Viel sinnvoller wäre es zur Zeit, sich endlich auf die 64-Bit Technologie zu konzentrieren
und diese vollumfänglich in Hard- und Software umzustezen!
 
Zuletzt bearbeitet:
skcusBC <- schrieb:
@ NoD.sunrise & IntelFreak87
Boah, herrlich! Es gibt offensichtlich 2 Menschen, die das Grundproblem begriffen haben!

Die Lösung dieses Problems ist in der Tat eine heikle Sache.
Ich bin nämlich genauso ratlos - würde aber wie NoD.sunrise zu einer Betriebssystemoreintierten
Lösung tendieren. Das OS in seiner Funktion als "große Klammer" ist die einzig sinnvolle Ebene um ein
effizientes Thread-Management zu intallieren. Wie das allerdings auf absehbare Zeit realisiert werden kann...
naja... ?
[...]

man könnte ja einfach ganz stupide die assembler befehle auf alle kerne veteilen und zum schluss das ergebniss auf anderenkernen zusammensetzen lassen (logisch gesehn) aber dazu wäre eine enorme bandbreite unter den cpus vonnöten ... also skalierung wäre dann nich das problem >128 cores usw.

also vorstellen kann ichs mir aber zwischen vorstellung und realität liegen meist welten :)
 
Haha genau laufzeitgebunden reassamblieren und wieder x-Kern optimiert assemblieren. :evillol:

Nur weil die Softwarehersteller es nicht gleich selber multithreaded programmieren können.. :lol:

Aber die Idee an sich ist gut! Kann das keine GPU übernehmen? Gibt doch schon WLAN-Knack-Tools für GPU's.. :rolleyes:
 

Ähnliche Themen

Zurück
Oben