Larrabee - der Konsolenkiller? ;)

Den Konsolenkiller hast du heute schon, die 130 euro Karte Radeon HD 4850!
Konsolenkiller nicht im Sinne von billige GPU mit besserer Leistung als Konsolen, das gabe es schon früher. ;)
Eher im Sinne von:
* "Außenseiter" der eher nicht in den Konsolenmarkt einsteigen will
* Hardware die Spiele rendert aber auch für den PC allgemein einen nutzen hat
* Die darstellung von x-facher Poligonzal auf dem PC im Vergleich zur Konsole
* Durch Implementierung in anderen bereichen stärkere verbreitung wodurch die Anzahl spielfähige Systeme generell steigt.
usw.


Ich seh das jetzt erst 300 Watt für ne Grafikkarte, das ist der reinste Wahnsinn...
Naja, die 300Watt sind aber meines wissens nur eine Annahme über die Stecker einer Karte von einem Prototypen.
1. Kann sich dort noch einiges ändern
2. Wird angenommen das High end Grafikkarten von Ati/Nvidia zu jenem zeitpunkt ähnliche Leistungen verbraten.
 
K
* Hardware die Spiele rendert aber auch für den PC allgemein einen nutzen hat
Cuda.Mit Directx11 kommt mit dem Compute Shader sogar eine einheitliche Schnittstelle,um Grafikkarten auch für andere Aufgaben außer Spielen einsetzen zu können.
K

* Durch Implementierung in anderen bereichen stärkere verbreitung wodurch die Anzahl spielfähige Systeme generell steigt.
usw.

Die Aussage von Intel war,daß der Larrabee für den Highendmarkt gedacht ist.Also wird es den nicht oder nur zum vollkommen überteuerten Preis in den Saumärkten geben.Und der Larrabee kann/soll ja auch den üblichen Prozessor nicht ersetzen.Insgesamt für es für den Kunden auf das gleiche hinlaufen,ob er nun eine übliche leistungsfähige Grafikkarte oder den Larrabee kauft.
 
Zuletzt bearbeitet:
Cuda.Mit Directx11 kommt mit dem Compute Shader sogar eine einheitliche Schnittstelle,um Grafikkarten auch für andere Aufgaben außer Spielen einsetzen zu können.
Cuda hat aber eben seine Eigenheiten. Es besitzt keine echte x86 kompatibilität. Es hat zwar eine eingeschränkte C kompatibilität bzw. Nvidia hat einen Kompiler dafür, das ist jedoch nur aufgesetzt und von dem her sicher nicht performance mäßig optimal.
Als programmierer ist es ein "unding" wenn ich gezwungen werde auf C zu programmieren. ;)
Es herschen gewisse einschränkungen und spezialitäten mit welchen man sich tiefgehend beschäftigen muß um seinen code wirklich gut zu optimieren.

Die Aussage von Intel war,daß der Larrabee für den Highendmarkt gedacht ist.Also wird es den nicht oder nur zum vollkommen überteuerten Preis in den Saumärkten geben.Und der Larrabee kann/soll ja auch den üblichen Prozessor nicht ersetzen.Insgesamt für es für den Kunden auf das gleiche hinlaufen,ob er nun eine übliche leistungsfähige Grafikkarte oder den Larrabee kauft.
Intel will aber später den Larrabee mit dem CPU zumindest teilweise verschmelzen.
Das Problem welches Intel aktuell hat ist das sich x cores einfach schlecht verkaufen lassen. Für normale Anwender lohnt es sich kaum mehr als dual core zu kaufen.
Bei einem Larrabee welcher für Video codierung, encodierung, grafikbearbeitung, grafikbetrachtung, videobearbeitung, verschlüsselung, kompression, Spracherkennung, Audioverarbeitung, grafikeffekte (im betriebssystem) usw. verwenden läst, hat zumindest der Durchschnitsuser auch einen kleinen Vorteil.
Selbst Suchalgorithmen ließen sich eventuell optimieren.
Und ob ich eine Grafikkarte nur für das Spielen ist oder auch alle leistungsfordernden Aufgaben beschleunigt macht doch ein größerer Unterschied.
 
Cuda hat aber eben seine Eigenheiten. Es besitzt keine echte x86 kompatibilität. Es hat zwar eine eingeschränkte C kompatibilität bzw. Nvidia hat einen Kompiler dafür, das ist jedoch nur aufgesetzt und von dem her sicher nicht performance mäßig optimal.
Als programmierer ist es ein "unding" wenn ich gezwungen werde auf C zu programmieren. ;)
Was verwenden sie denn sonst(Sprache?)
Intel will aber später den Larrabee mit dem CPU zumindest teilweise verschmelzen.
Sicher nicht mit den Highendvarianten.
Das Problem welches Intel aktuell hat ist das sich x cores einfach schlecht verkaufen lassen. Für normale Anwender lohnt es sich kaum mehr als dual core zu kaufen.
Und das ändert sich doch nicht durch den Larrabee??
Ws hindert denn einen daran,sich einen günstigen Dualcore zu kaufen(nicht mal von Intel...) und den Larrabee zur Beschleunigung von Videoencoderierung/Bildbearbeitung etc. zu verwenden?Ich gehe mal stillschweigend davon aus,daß der Larrabee nicht das Preisniveau vom Quadextreme und co erreicht,sondern in den Preisgrenzen üblicher Gpus verkauft werden wird.Irgendwie würde sich da Intel sogar ins eigene Fleisch schneiden.

Und ob ich eine Grafikkarte nur für das Spielen ist oder auch alle leistungsfordernden Aufgaben beschleunigt macht doch ein größerer Unterschied.
Das wird sich aber ändern.Mit Dirext11 kommen dann die Compute Shaders,mit denen sich dann alle Grafikkarten am Markt für so was nutzen lassen.Ein Programmentwickler,der da nur auf den Larrabee und x86 setzt,wird da Probleme bekommen....
Je größer die Hardwarebasis für das eigene Programm,desto besser
 
Zuletzt bearbeitet:
Was verwenden sie denn sonst(Sprache?)
bevorzugt C#
gezwungener maßen teilweise Java
C++ vor einiger zeit, das ist noch diskutierbar in bestimmten Bereichen.
Bei C sträubt es einem aber einfach die Haare. ;)

Sicher nicht mit den Highendvarianten.
Nein, wohl abhägig von der Preisklasse. Jedoch laufen wir in eine Zeit hinein in welcher die Grafikunterschiede von Generation zu Generation immer weniger auffallen.

Und das ändert sich doch nicht durch den Larrabee??
Ws hindert denn einen daran,sich einen günstigen Dualcore zu kaufen(nicht mal von Intel...) und den Larrabee zur Beschleunigung von Videoencoderierung/Bildbearbeitung etc. zu verwenden?Ich gehe mal stillschweigend davon aus,daß der Larrabee nicht das Preisniveau vom Quadextreme und co erreicht,sondern in den Preisgrenzen üblicher Gpus verkauft werden wird.Irgendwie würde sich da Intel sogar ins eigene Fleisch schneiden.
Doch, es geht ja genau darum das man sich als Spieler dann zb ein günstigen x core kauft um vielleicht 60€. Dazu jedoch eine Grafikkarte um ~200€. -> Intel macht trotzdem guten Umsatz/Gewinn.
Eine CPU aufzurüsten ist jetzt bereits fraglich, bei der Grafikkarte hält der Bedarf noch etwas länger an. Und mit neuen Codec verfahren für videos und Blueray nachfolger und ähnlichem läßt sich das ganze für nachfolger gut weiter hinauszögern.

Das wird sich aber ändern.Mit Dirext11 kommen dann die Compute Shaders,mit denen sich dann alle Grafikkarten am Markt für so was nutzen lassen.Ein Programmentwickler,der da nur auf den Larrabee und x86 setzt,wird da Probleme bekommen....
Je größer die Hardwarebasis für das eigene Programm,desto besser
Compute Shaders ist aber "nur" für Grafikkarten. x86er code läßt sich beliebig zwischen cpu und larrabee-Grafikkarte verlagern (zumindest theoretisch). Nach der verschmelzung mit der cpu wäre die Kompatibilität auf jeden neueren pc ausgeweitet.
 
Doch, es geht ja genau darum das man sich als Spieler dann zb ein günstigen x core kauft um vielleicht 60€. Dazu jedoch eine Grafikkarte um ~200€. -> Intel macht trotzdem guten Umsatz/Gewinn.
Nie im Leben.Wäre ja verrückt.Was machen mit den Prozessoren der Extremeklasse?Und denen zwischen 100-200 Euro?Was,wenn manche Spieler/Anwender auf nen Amdmanycore/dualcore zurückgreifen?Die Gewinne würden schrumpfen und das kann irgendwie kaum im Sinne Intels sein.

Compute Shaders ist aber "nur" für Grafikkarten. x86er code läßt sich beliebig zwischen cpu und larrabee-Grafikkarte verlagern (zumindest theoretisch). Nach der verschmelzung mit der cpu wäre die Kompatibilität auf jeden neueren pc ausgeweitet.

Die Gpu ist doch bereits unter Cuda so schnell,daß die Transcodierung eines Viedeos mit 1080p gerade mal eine halbe Stunde dauert.Und natürlich hilft die Cpu hier auch mit,indem sie wenigstens die Aufgaben verteilt.Der Vorteil dürfte,wenn vorhanden,eher minimal sein.Vielleicht ein Zeitgewinn von ein paar Minuten.
 
Nie im Leben.Wäre ja verrückt.Was machen mit den Prozessoren der Extremeklasse?Und denen zwischen 100-200 Euro?Was,wenn manche Spieler/Anwender auf nen Amdmanycore/dualcore zurückgreifen?Die Gewinne würden schrumpfen und das kann irgendwie kaum im Sinne Intels sein.
Der CPU in der aktuellen Form ist einfach eine Sackgasse.
Und Nvidia ist in letzter Zeit/versucht immer stärker in Bereiche vorzudringen welche früher Hoheitsgebiet von Highend CPU's war.
Intel hat eigentlich garkeine andere wahl als Highend anwendungen auf einen Larrabee artigen number cruncher auszulagern und die CPU stärker auf mitelklasse auszurichten.

Die Gpu ist doch bereits unter Cuda so schnell,daß die Transcodierung eines Viedeos mit 1080p gerade mal eine halbe Stunde dauert.Und natürlich hilft die Cpu hier auch mit,indem sie wenigstens die Aufgaben verteilt.Der Vorteil dürfte,wenn vorhanden,eher minimal sein.Vielleicht ein Zeitgewinn von ein paar Minuten.
Es geht ja nicht nur um speed im Transcodieren.
Bessere kompatibilität -> einfachere Portierung von implementierungen
Stärkere Verbreitung -> größerer Markt
konkurenzfähiger Support von Rasterisierung + x86 -> Basis funktionen der Konkurenz inklusive zusätzlicher features
 
Es geht ja nicht nur um speed im Transcodieren.
Bessere kompatibilität -> einfachere Portierung von implementierungen
Stärkere Verbreitung -> größerer Markt
konkurenzfähiger Support von Rasterisierung + x86 -> Basis funktionen der Konkurenz inklusive zusätzlicher features
Die Kerne des Larrabee sind In-Order-Kerne.Um die Multicorearchtitekture effinzient zu nutzen,braucht man eine C-Sprache:
he traditional raster graphics pipeline used by companies such as Advanced Micro Devices Inc. and Nvidia Corp. needs to go in favour of using ray tracing for a new and better way to render graphics, said Justin Rattner, Intel's chief technology officer, speaking at an annual gathering of Intel researchers. Rattner also disclosed a separate effort to extend the C++ programming language for multi-core processors.

"We believe a new graphics architecture will deliver vastly better visual experiences because it will fundamentally break the barrier between today's raster-based pipelines and the best visual algorithms," said Rattner. "Our long term vision is to move beyond raster graphics which will make today's GPU technology outmoded," he said.

Ray tracing
Intel researchers will present a paper on its upcoming Larrabee chip at the Siggraph conference in August, Rattner said. The paper will provide examples of how to create superior images using ray tracing rather than a conventional raster graphics pipeline, he added.

To date Intel has described Larrabee only in general terms as a processor geared for graphics and technical applications made up from many x86 cores with a simplified, in-order pipeline. Larrabee will sport about 100 new x86 instructions including support for vector processing at a TFlop rate.

Although its x86 cores will be able to handle ray tracing jobs, the chip will also support more traditional graphics rendering models for APIs including OpenGL and Microsoft's DirectX.

Ray tracing is a computational intensive method of drawing images based on following rays of light and their collisions with objects. Rasterisation is a traditional method of breaking a scene into many tiny polygons, then drawing and colouring in each shape to give the scene lighting and texture effects.

Larabee promise
Intel said Larrabee will not ship until at least late 2009. Nevertheless it has generated plenty of interest in the graphics community.

"We haven't seen a new discrete graphics chip player in about a decade," said Dean McCarron, principal of Mercury Research who tracks graphics.

Unofficial reports have said Larabee will use 16 cores running up to four threads each and sport a 1024-bit wide memory bus.

Just as Intel is promising a deeper incursion into computer graphics, AMD and Nvidia are already making inroads into high end technical computing applications.

The two companies already ship graphics chips using more than 100 very simple processing cores. The cores can handle either raster graphics jobs or more general-purpose computing tasks for technical applications ranging from astrophysics calculations to medical imaging.

Both AMD and Nvidia are expected to roll out their next generation parts later this month. They will likely pack even more cores into their chips and expand their efforts in technical computing.

For its part, Nvidia already has a "few dozen" technical apps written for its Cuda environment released a year ago that supports high-end general purpose computing on its chips. "This is a time of generating new code," said Dan Vivoli, a senior vice president of marketing for the technical computing effort at Nvidia.

Beyond C++
Nvidia's Cuda provides extensions to the C language to help programmers show what parts of their code could use multiple cores running in parallel. Intel's Rattner disclosed a similar effort based on C++.


Called Ct for "throughput," the Intel effort provides a range of extensions for the C++ language and a runtime compiler that can ease the process of optimising serial code to run on a multi-core CPU. The extensions help identify the data types and operations on them that a program is using so the compiler can automatically spread the jobs across multiple cores.

"We've linked up with a small group of partners to give us feedback on these extensions from different application domains," said Rattner. "Our next step is to take this to being a commercial product, something which seems highly probable," he added.

The project was co-developed with Intel researchers in China and at its Santa Clara, Calif., headquarters. The code also handles vector processing tasks, using Intel's SSE extended instruction set.

- Rick Merritt
EE Times

Ist C soviel "schlimmer" als C++??
Und wie geschrieben,breite Kompabilität wird mit Directx11 gegeben sein.
Auch interessant,C# und Cuda:
http://forums.nvidia.com/index.php?showtopic=37899
 
Zuletzt bearbeitet:
Die Kerne des Larrabee sind In-Order-Kerne.Um die Multicorearchtitekture effinzient zu nutzen,braucht man eine C-Sprache:
Aber C++ oder C# laufen natürlich auch auf Multicoresystemen.
C++ ist ja nur eine Erweiterung von C.

Ist C soviel "schlimmer" als C++??
C++ Unterstützt einem beim Programmieren einfach besser. So kann man zb typen angeben wodurch sich fehler verhindern lassen.
In C++ werden viele datencontainer bereits in der library mitgeliefert wodurch sortierfunktionen usw. zum Kinderspiel werden...

Natürlich hat man sich auch an eine Sprache gewöhnt. Und C# unterstützt einen einfach ungemein beim Programmieren. zb kenne ich in C# soetwas wie die berüchtigten Speicherlöcher garnicht. Ältere Sprachen wie C beinhalten einfach unannehmlichkeiten welche eigentlich nicht die Aufgaben des Programmierers wären zb:

Zuerst muß eine funktion deklariert werden:
void hallo();

Um sie einige zeilen später zu implementieren:
void hallo(){
foo();
}


Das bedeutet es ist doppelte Schreibarbeit notwendig nur weil der Compiler nicht schlau genug ist um sich die implementierung selbst heraus zu suchen.

Und wie geschrieben,breite Kompabilität wird mit Directx11 gegeben sein.
Ich bezweifle aber das dies eine alzu freie Programmierung erlauben wird.

Hmm, aber soweit wie ich das gesehen habe wird die Implementierung trotzdem noch in C erstellt, nur das Anspreichen erfolgt über C#
 
Zuletzt bearbeitet:
c kann auch auf multicore systemen laufen das hat damit garnix zu tun... bei c fehlen nur dinge die das leben einfacher machen stichwort klassen... c ist nicht 'schlimmer' nur älter. ++c ist einfach nur jünger und baut auf c auf sozusagen eine erweiterung von c, liefert somit auch mehr. Und das mit der deklaration vs definition hat auch imense vorteile in der strukturierung gerade weil dem programmierer nicht unbedingt (auch hier gibts compiler die das können) alles abgenommen wird kann man viel effektiver in der speicherverwaltung und der rechenzeit tweaken. je mehr abgenommen wird desto inneffektiver wird der code auch meistens. hinzufügen von x klassen nur weil man eine vorgefertigte funktion braucht ist auch wieder ein speicherfüller. c# kennt sehr wohl memmoryleaks auch ist c# nicht open auch wieder ein nachteil. so einfach wie c > ++c > c# ist das eben nicht.
 
Zuletzt bearbeitet:
Aber C++ oder C# laufen natürlich auch auf Multicoresystemen.
C++ ist ja nur eine Erweiterung von C.

C++ Unterstützt einem beim Programmieren einfach besser. So kann man zb typen angeben wodurch sich fehler verhindern lassen.
In C++ werden viele datencontainer bereits in der library mitgeliefert wodurch sortierfunktionen usw. zum Kinderspiel werden...

Natürlich hat man sich auch an eine Sprache gewöhnt. Und C# unterstützt einen einfach ungemein beim Programmieren. zb kenne ich in C# soetwas wie die berüchtigten Speicherlöcher garnicht. Ältere Sprachen wie C beinhalten einfach unannehmlichkeiten welche eigentlich nicht die Aufgaben des Programmierers wären zb:

Zuerst muß eine funktion deklariert werden:
void hallo();

Um sie einige zeilen später zu implementieren:
void hallo(){
foo();
}


Das bedeutet es ist doppelte Schreibarbeit notwendig nur weil der Compiler nicht schlau genug ist um sich die implementierung selbst heraus zu suchen.

Ich bezweifle aber das dies eine alzu freie Programmierung erlauben wird.

Hmm, aber soweit wie ich das gesehen habe wird die Implementierung trotzdem noch in C erstellt, nur das Anspreichen erfolgt über C#

C++ ist eine Erweiterung von C
C# ist im Kern eine Interpreter-Sprache wie z.B. Java. wenn man böse ist könnte man sagen, dass C# Basic mit C++ Syntax ist.

Aber tatsächlich lassen sich manche Konstrukte in der Objektorientierung mit Interpreter-Sprachen besser abbilden, daher ist C# nicht grundsätzlich verkehrt. Nur sollte man anhängig vom Ziel überlegen, welche Programmiersprache besser passt...

Das Thema mit den Speicherlöchern, die man mit Interpreter-Sprachen angeblich nicht machen können soll, ist eines der Mythen unserer Zeit, wie der Yeti im Himmalya. Leider ist es umgekehrt, aufgrund dieses Mythos programmieren viele Ihre Java-Applikation schlampig und heraus kommen Applikationen, die dann immerhin 2 Stunden am Stück laufen...
:shakehead:

Das Thema mit der Deklaration von Funktionen solltest Du Dir noch mal überlegen, denn der GRund für die Deklaration ist nicht der, dass der Compiler nicht schlau genug wäre sich eine rauszusuchen, sondern der dass Du in der Objektorientierung eine Funktion mehrfach überladen kannst...

...und Du dann nicht schlau genug wärst zu wissen, welche verwendet wird ;-)
 
Das Thema mit den Speicherlöchern, die man mit Interpreter-Sprachen angeblich nicht machen können soll, ist eines der Mythen unserer Zeit, wie der Yeti im Himmalya. Leider ist es umgekehrt, aufgrund dieses Mythos programmieren viele Ihre Java-Applikation schlampig und heraus kommen Applikationen, die dann immerhin 2 Stunden am Stück laufen...
:shakehead:

Das jemand schlampig programmiert hängt aber weniger mit der Programmiersprache zusammen. Oder willst du sagen das ohne GC generell sauberer programmiert wird?

Das Thema mit der Deklaration von Funktionen solltest Du Dir noch mal überlegen, denn der GRund für die Deklaration ist nicht der, dass der Compiler nicht schlau genug wäre sich eine rauszusuchen, sondern der dass Du in der Objektorientierung eine Funktion mehrfach überladen kannst...

...und Du dann nicht schlau genug wärst zu wissen, welche verwendet wird ;-)
Wie das jetzt?
Ich kann doch in C# genau so Funktionen überladen. :-?
 
Das jemand schlampig programmiert hängt aber weniger mit der Programmiersprache zusammen. Oder willst du sagen das ohne GC generell sauberer programmiert wird?

Wie das jetzt?
Ich kann doch in C# genau so Funktionen überladen. :-?

Nein, aber ich bin ein Programmierer "Alter Schule" mir ist es lieber ein Programm knallt nach 10 min mit einer "Assertion failed" als dass es 2 Stunden vor sich hindümpelt und schließlich den ganzen Rechner lahmlegt. Natürlich hat das etwas mit schlampiger Programmierung zu tun und die ist unabhängig von der Programmierspache, nur verführt dieses "Es gibt keine Memory Leaks unter Java oder C#..." in meinen Augen zu schlampigen Memorymanagement...

Den 2. Punkt habe ich nicht verstanden gerade auch in C# solltest Du Funktionen deklarieren, ansonsten kann es böse Überraschungen geben.
 
Nein, aber ich bin ein Programmierer "Alter Schule" mir ist es lieber ein Programm knallt nach 10 min mit einer "Assertion failed" als dass es 2 Stunden vor sich hindümpelt und schließlich den ganzen Rechner lahmlegt. Natürlich hat das etwas mit schlampiger Programmierung zu tun und die ist unabhängig von der Programmierspache, nur verführt dieses "Es gibt keine Memory Leaks unter Java oder C#..." in meinen Augen zu schlampigen Memorymanagement...
So kann man aber auch argumentieren das ESP zum schnellfahren verleitet. Sicher stimmen solche sachen teilweise, aber trotzdem trift das für den größeren Teil eher nicht zu.

Den 2. Punkt habe ich nicht verstanden gerade auch in C# solltest Du Funktionen deklarieren, ansonsten kann es böse Überraschungen geben.
Und was für eine böse Überraschung? Ein konkretes Beispiel würde eventuell helfen.
 
So kann man aber auch argumentieren das ESP zum schnellfahren verleitet. Sicher stimmen solche sachen teilweise, aber trotzdem trift das für den größeren Teil eher nicht zu.

Und was für eine böse Überraschung? Ein konkretes Beispiel würde eventuell helfen.

Hmm, ich habe ein ESB und es verleitet zum schnell fahren ;-)
Mit meiner Karre aus Studienzeiten bin ich nicht mit 200 km/h um die Kurve xD

Der Klassiker wäre:

class Base{

public int ergebnis (int a, int b) {
return(a+b);
}
}


class Nonsens : Base {
public double ergebnis (double a, double b) {
return(a-b);
}
}

Nonsens n = new Nonsens();
double test;
test = n.ergebnis(5,4);

Der Klassiker mit überladenen Funktionen ist jetzt, welchen Wert hat Test ?

Aufgrund vielfältiger Erfahrungen in meinem Leben habe ich gelernt Deklarationen zu schätzen, denn alles andere bedeutet, dass man sich über die Rangfolge von Konvertierungen etc. im klaren sein muss, die meist bei weitem nicht so einfach sind, wie da oben...

Einmal hat mich ein im Prinzip ähnlich gelagertes Problem wie das da ca. 250.000 € gekostet, na gut nicht mich, aber das Projekt das ich geleitet habe...
 
Tja,braucht Intels Larrabee den Einzug in eine Konsole,um zum Erfolg zu werden?
http://www.theinquirer.net/gb/inquirer/news/2008/09/03/potential-console-deal-intel
Abwegig wäre es nicht und die Argumente sind durchaus schlüssig.

Macht eigentlich mehr Sinn in der PS4, hat mehr Ähnlichkeit mit dem Cell als mit einem klassischen Graphikchip.
Ich kann das Zögern der Hersteller verstehen, um die Power von Larrabee zu nutzen muss man sich wie beim Cell neue Algorithmen ausdenken. Vorteil dürfte allerdings sein, dass der Kern an sich besser ist, wie beim Cell...
 
müsste die grafik nicht auf die 32 kerne optimiert sein?
 
Zurück
Top Bottom