Archiv verlassen und diese Seite im Standarddesign anzeigen : FTC verklagt Intel
Tarkin
2009-12-16, 15:21:29
jetzt wirds eng bzw extrem ungemütlich für Intel ...
http://www.ftc.gov/opa/2009/12/intel.shtm
Klagen und Strafzahlungen so weit das Auge reicht... was für ein Sumpf!
Sephiroth
2009-12-16, 16:20:56
AMD-Aktieninhaber wird es freuen. Recht interessant finde ich die Berücksichtigung dieses Punkts hier:
In addition, allegedly, Intel secretly redesigned key software, known as a compiler, in a way that deliberately stunted the performance of competitors’ CPU chips. Intel told its customers and the public that software performed better on Intel CPUs than on competitors’ CPUs, but the company deceived them by failing to disclose that these differences were due largely or entirely to Intel’s compiler design.
Recht interessant finde ich die Berücksichtigung dieses Punkts hier:
Ich bin immer noch der Meinung das mit dem Intel compilierte Programme auf AMD-CPUs generell nicht lauffähig sein sollte. :D
Ich finde es seltsam das sie im Zusammenhang mit NV nur den GPU markt ansprechen aber nicht den Chipsatzmarkt. Imho nutzt da Intel die Monopolstellung aus.
AMD-Aktieninhaber wird es freuen. Recht interessant finde ich die Berücksichtigung dieses Punkts hier:
Ist doch irgendwie logisch, dass Intel die Compiler so designt, dass damit die eigenen CPUs möglichst schnell sind, was ist daran so interessant?
StefanV
2009-12-16, 17:39:56
Dass es einige Software da draußen gibt, die damit compiliert wurde und Intel das offen anbietet??
Und es nicht mit 'only for testing purposes' bewirbt...
][immy
2009-12-16, 18:02:57
AMD-Aktieninhaber wird es freuen. Recht interessant finde ich die Berücksichtigung dieses Punkts hier:
das dürfte wohl unter anderem auf die sache zurückzuführen sein die man damals zu SSE 4 einführung bemerkt hatte. SSE (x) lief damals (http://www.planet3dnow.de/vbulletin/showthread.php?t=336249) doch schneller auf AMD Prozessoren, aber der compiler verhinderte, dies überhaupt auf einer AMD CPU genutzt werden konnte. kaum wurde die CPU "umbenannt" ging es und die amd cpu legte gehörig zu.
aber abseits davon könnte man natürlich fragen, warum amd keinen eigenen compiler anbietet, wobei ich nur höchst ungern sehen würde, das es dann demnächst für jeden prozessor eine eigene exe gibt.
wobei ich da intel echt nicht verstehen kann warum die sowas immer wieder machen, denn AMD konnte sich mit den Opterons zwar einen besseren ruf erarbeiten, aber wirklich gut ist der ruf von AMD noch nicht (und wird es vermutlich in den nächsten jahren auch nicht werden). von daher wird schon in über 50% aller Fälle Intel bevorzugt. was wollen die den noch mehr?
das quasi-monopol tut denen echt nicht gut.
Black-Scorpion
2009-12-16, 18:05:03
Ist doch irgendwie logisch, dass Intel die Compiler so designt, dass damit die eigenen CPUs möglichst schnell sind, was ist daran so interessant?
Logisch ja, aber nicht wenn die damit compilierten Programme mit einer ID Abfrage die anderen absichtlich ausbremst.
Dass es einige Software da draußen gibt, die damit compiliert wurde und Intel das offen anbietet??
Und was ist dagegen einzuwenden?
Undertaker
2009-12-16, 18:11:24
Das ist wirklich die Frage, ist soetwas strafbar? :confused: Zumal Intels Compiler ja keine marktbeherrschende Stellung besitzt - man könnte, wenn man sich davon einen Vorteil versprechen würde, Produkte der Konkurrenz sogar komplett ausperren (das das vermutlich ein Schuss ins eigene Bein wäre, ist dabei gar nicht relevant)...
reunion
2009-12-16, 18:18:10
Das ist wirklich die Frage, ist soetwas strafbar? :confused:
Natürlich. Wenn ich eine marktbeherrschende Stellung inne habe darf ich meine Marktmacht nicht dazu missbrauchen Konkurrenten zu benachteiligen.
Undertaker
2009-12-16, 18:20:00
Nur hat Intel eine solche im Compilerbereich nicht.
reunion
2009-12-16, 18:22:45
Nur hat Intel eine solche im Compilerbereich nicht.
Darum geht es nicht. Sie pushen mit ihren Compiler ihre CPUs künstlich bzw. benachteiligen den Konkurrenten. Zumindest wird ihnen das vorgeworfen. Und seine wir doch mal ehrlich: Ohne eine entsprechende "Unterstützung" von Intel verwendet niemand ihren Compiler. Wer es tut der weiß worauf er sich einlässt.
StefanV
2009-12-16, 18:32:24
Und was ist dagegen einzuwenden?
Hm, mal überlegen:
Ein Hersteller hat 80-90% von einem Markt, baut dann etwas, das Programm compiliert, doch statt den selben Code für alles zu nutzen, gibt es eine Abfrage, die verhindert, dass der 'bessere Code' auf Konkurenzprodukten ausgeführt wird.
Dieses Programm wird auch nicht als 'only for testing' oder ähnlichem beworben, ergo als ganz normales Programm...
(ganz grob) Vergleichbar wäre dass, wenn M$ jetzt in Windows mechanismen einbauen würde, die das Verwenden von OpenOffice verhindern oder erschweren würde...
dieser Compiler lässt Intel CPUs besser dastehen als sie eigentlich sind!
Nur hat Intel eine solche im Compilerbereich nicht.
Unabhängig davon müssen potenzielle Kunden auf Einschränkungen, insbeondere in diesem Ausmaß, hingewiesen werden. Schließlich wird ein Compiler für eine bestimmte Umgebung (x86) angeboten und nicht nur "für Intel Prozessoren only". Außerdem gelang der Nachweis der gezielten Einflussnahme auf das Produkt eines Konkurrenten.
Übertrag das Thema einfach auf andere Bereiche, z.B. eine Tabellenkalkulation, welche nur dann richtige Ergebnisse liefert wenn diese einen Prozessor aus dem Hause AMD vorfindet. Oder ein Betriebssystem, welches nur vernünftig läuft, wenn es mehr Ressourcen vorfindet als 10 sinnvolle Softwarepakete zusammen benötigen.... ups, anderes Thema....
Hm, mal überlegen:
Ein Hersteller hat 80-90% von einem Markt, baut dann etwas, das Programm compiliert, doch statt den selben Code für alles zu nutzen, gibt es eine Abfrage, die verhindert, dass der 'bessere Code' auf Konkurenzprodukten ausgeführt wird.
Dieses Programm wird auch nicht als 'only for testing' oder ähnlichem beworben, ergo als ganz normales Programm...
(ganz grob) Vergleichbar wäre dass, wenn M$ jetzt in Windows mechanismen einbauen würde, die das Verwenden von OpenOffice verhindern oder erschweren würde...
dieser Compiler lässt Intel CPUs besser dastehen als sie eigentlich sind!
Nö! Es müßte heißen: dieser Compiler lässt AMDs CPUs schlechter dastehen als sie eigentlich sind.
Allerdings kann ich Intel verstehen, da es nicht ihr Job ist, Befehlssatzerweiterungen sämtlicher CPU-Hersteller zu validieren.
Sie implementieren z.B. SSE2, validieren es auf 1000 Intel-CPUs, läuft. Und bei AMD? Geht es oder geht es nicht? Wer zahlt ihnen den Validierungssaufwand, welcher beweist das AMDs SSE2 zu 100,000000000% gleich zur Intels Implementation ist?!
(Hatten wir nicht erst so einen Fall in Batman AA mit NV und ATI?)
Nö! Es müßte heißen: dieser Compiler lässt AMDs CPUs schlechter dastehen als sie eigentlich sind.
Allerdings kann ich Intel verstehen, da es nicht ihr Job ist, Befehlssatzerweiterungen sämtlicher CPU-Hersteller zu validieren.
Sie implementieren z.B. SSE2, validieren es auf 1000 Intel-CPUs, läuft. Und bei AMD? Geht es oder geht es nicht? Wer zahlt ihnen den Validierungssaufwand, welcher beweist das AMDs SSE2 zu 100,000000000% gleich zur Intels Implementation ist?!
(Hatten wir nicht erst so einen Fall in Batman AA mit NV und ATI?)
SSE2 ist ein Standard der im Zuge eines Patenttausches zwischen AMD und Intel getauscht wurde (SSE 3 auch) also ist es zu 100,000000000% gleich.
Es geht auch überhaupt nicht darum, dass Sachen die AMD exklusiv sind vom Intelcompiler nicht unterstützt wird, sondern dass Intel AMD selbst bei identischen Voraussetzungen ausbremst. Ist aber wie schon erwähnt wurde keine brandneue Erkenntnis...
Exxtreme
2009-12-16, 19:48:55
Das Klügste wäre wohl Intel zu zerschlagen. Dieses Unternehmen ist ein riesiger Moloch, den man wohl nciht wirklich kontrollieren kann.
Darum geht es nicht. Sie pushen mit ihren Compiler ihre CPUs künstlich bzw. benachteiligen den Konkurrenten.
Nein, sie bevorzugen ihre eigene CPU, was auch verständlich ist.
Natürlich werden sie die Befehle so anordnen, dass es ihren eigenen CPUs am besten schmeckt.
Es steht ja AMD frei das selbe zu tun.
StefanV
2009-12-16, 19:59:01
Nö! Es müßte heißen: dieser Compiler lässt AMDs CPUs schlechter dastehen als sie eigentlich sind.nein, denn es gibt(/gab) noch andere CPU Hersteller...
Allerdings kann ich Intel verstehen, da es nicht ihr Job ist, Befehlssatzerweiterungen sämtlicher CPU-Hersteller zu validieren.
Dann sollen die den Compiler nicht verkaufen bzw entsprechend markieren!
Es spricht ja nichts dagegen, ihn nur für die SPEC zu verwenden...
Sie implementieren z.B. SSE2, validieren es auf 1000 Intel-CPUs, läuft. Und bei AMD? Geht es oder geht es nicht? Wer zahlt ihnen den Validierungssaufwand, welcher beweist das AMDs SSE2 zu 100,000000000% gleich zur Intels Implementation ist?!
(Hatten wir nicht erst so einen Fall in Batman AA mit NV und ATI?)
Dann dürfen sie keine compiler entwickeln, PUNKT!
Und CPUs sind eine andere Baustelle, die sind binärkompatibel.
Was beim einen läuft, läuft beim anderen auch.
Nein, sie bevorzugen ihre eigene CPU, was auch verständlich ist.
Natürlich werden sie die Befehle so anordnen, dass es ihren eigenen CPUs am besten schmeckt.
Es steht ja AMD frei das selbe zu tun.
Nein eben nicht. Es wird keine CPU beschleunigt sondern die von AMD verlangsamt.
Und überhaupt wer außer geisteskranken Fanboys will eigentlich so einen BS überhaupt.
SSE2 ist ein Standard der im Zuge eines Patenttausches zwischen AMD und Intel getauscht wurde (SSE 3 auch) also ist es zu 100,000000000% gleich.
Es geht auch überhaupt nicht darum, dass Sachen die AMD exklusiv sind vom Intelcompiler nicht unterstützt wird, sondern dass Intel AMD selbst bei identischen Voraussetzungen ausbremst. Ist aber wie schon erwähnt wurde keine brandneue Erkenntnis...
BullShit!
Wer garantiert das das IntelPatent 1:1 von AMD implementiert worden ist? DU?
Das kann nur AMD oder INTEL.
Kannst du dich noch an die AMD64 - EMT64 Geschichte beim P4 erinnern? Da gab es auch Unterschied, nix mit 100,0% gleich.
Und noch einmal, AMD wird nicht ausgebremst! Es werden nur nicht sämtliche Erweiterungen (SSE z.B.) vollständig verwendet. Oder meinst du etwa das, wenn ein AMD Chip erkannt wurde, 1000 Do-Nothing-Loop, oder NOPs ausgeführt werden? Mach dich nicht lächerlich.
Weiters, wibt Intel bei ihrem Compiler das sie vollstädnig AMD-CPUs unterstützen oder steht das was von Intel-CPUs? Das andere CPU-Hersteller dennoch laufen ist nur ein Nebenprodukt ;D
StefanV
2009-12-16, 21:00:40
Doch, AMD wird ausgebremst!
Es wird z.B. sehr schlecht optimierter Code verwendet, wenn kein Intel Prozessor im System ist.
Exxtreme
2009-12-16, 21:05:05
BullShit!
Wer garantiert das das IntelPatent 1:1 von AMD implementiert worden ist? DU?
Das kann nur AMD oder INTEL.
Kannst du dich noch an die AMD64 - EMT64 Geschichte beim P4 erinnern? Da gab es auch Unterschied, nix mit 100,0% gleich.
Und noch einmal, AMD wird nicht ausgebremst! Es werden nur nicht sämtliche Erweiterungen (SSE z.B.) vollständig verwendet. Oder meinst du etwa das, wenn ein AMD Chip erkannt wurde, 1000 Do-Nothing-Loop, oder NOPs ausgeführt werden? Mach dich nicht lächerlich.
Weiters, wibt Intel bei ihrem Compiler das sie vollstädnig AMD-CPUs unterstützen oder steht das was von Intel-CPUs? Das andere CPU-Hersteller dennoch laufen ist nur ein Nebenprodukt ;D
Naja, Fakt ist sobald der Compiler keine Genuine Intel-CPU vorfindet, nutzt er nicht mehr sein volles Potential. Fakt ist auch, daß wenn man dem Compiler eine mit Genuine Intel-umgelabelte AMD-CPU vorsetzt, daß dann der Compiler sein volles Potential nutzt und die Programme dann auch auf AMD-CPUs schneller laufen.
Schwer wiegt wohl, daß Microsoft wegen einer vergleichbaren Sache verurteilt wurde. Die haben ins Windows 3.0 eine Erkennungsroutine eingebaut, die ermitteln sollte ob Windows von einem DOS von Microsoft gestartet wurde. Wenn nein dann verweigerte Windows mit einer künstlichen Fehlermeldung den Start obwohl es rein technisch keinerlei Gründe gab warum es nicht starten konnte.
Doch, AMD wird ausgebremst!
Es wird z.B. sehr schlecht optimierter Code verwendet, wenn kein Intel Prozessor im System ist.
Kannst du das belegen?!
Mir scheint als hättest du keine Ahnung, bzw. verstehst den Unterschied im Programmieren zwischen "Bremsen" und "Optimieren".
Kannst du garantieren das Intels Optimieren, welche auf allen Intels korrekt funktionieren, auch auf allen AMDs zu 100% funktionieren?
Wer hat das Validiert? Niemand! Deshalb werben sie auch nicht damit. Ich sehe da keinen rechtlichen Konflikt.
Naja, Fakt ist sobald der Compiler keine Genuine Intel-CPU vorfindet, nutzt er nicht mehr sein volles Potential. Fakt ist auch, daß wenn man dem Compiler eine mit Genuine Intel-umgelabelte AMD-CPU vorsetzt, daß dann der Compiler sein volles Potential nutzt und die Programme dann auch auf AMD-CPUs schneller laufen.
Wo widerspreche ich dir da?
Wer garantiert dir das durch das Umgelabeln sämtliche Funktionen in jeder Hinsicht zu 100% funktionieren wie auf Intel-CPUs? Es mag ja in diesem sowie auch in 99,99% aller anderen Fälle der Fall sein das es läuft, doch ein Restrisiko besteht wohl dennoch......
Schwer wiegt wohl, daß Microsoft wegen einer vergleichbaren Sache verurteilt wurde. Die haben ins Windows 3.0 eine Erkennungsroutine eingebaut, die ermitteln sollte ob Windows von einem DOS von Microsoft gestartet wurde. Wenn nein dann verweigerte Windows mit einer künstlichen Fehlermeldung den Start obwohl es rein technisch keinerlei Gründe gab warum es nicht starten konnte.
Sehe ich keinen Zusammenhang, würde es als Vergleich zulassen, wenn Windows auf dem nicht (MS)DOS nur eingeschränkt liefe.
Exxtreme
2009-12-16, 21:18:09
Wo widerspreche ich dir da?
Wer garantiert dir das durch das Umgelabeln sämtliche Funktionen in jeder Hinsicht zu 100% funktionieren wie auf Intel-CPUs? Es mag ja in diesem sowie auch in 99,99% aller anderen Fälle der Fall sein das es läuft, doch ein Restrisiko besteht wohl dennoch......
Selbst mit der Bremse gibt es keine Garantie, daß der erzeugte Code auf Nicht-Intel-CPUs läuft. Sprich, die Bremse macht so gesehen keinen Sinn. Denn daß der Code 100%ig läuft ist in keinem Fall garantiert.
Sehe ich keinen Zusammenhang, würde es als Vergleich zulassen, wenn Windows auf dem nicht (MS)DOS nur eingeschränkt liefe.
Naja, eine gekünstelte Fehlermeldung bringen und dann den Start verweigern sehe ich schon als Einschränkung an.
BullShit!
Wer garantiert das das IntelPatent 1:1 von AMD implementiert worden ist? DU?
Das kann nur AMD oder INTEL.
Kannst du dich noch an die AMD64 - EMT64 Geschichte beim P4 erinnern? Da gab es auch Unterschied, nix mit 100,0% gleich.
Und noch einmal, AMD wird nicht ausgebremst! Es werden nur nicht sämtliche Erweiterungen (SSE z.B.) vollständig verwendet. Oder meinst du etwa das, wenn ein AMD Chip erkannt wurde, 1000 Do-Nothing-Loop, oder NOPs ausgeführt werden? Mach dich nicht lächerlich.
Weiters, wibt Intel bei ihrem Compiler das sie vollstädnig AMD-CPUs unterstützen oder steht das was von Intel-CPUs? Das andere CPU-Hersteller dennoch laufen ist nur ein Nebenprodukt ;D
Nein du hast natürlich Recht die Intel CPUID fehlt zur Gleichheit ;)
Hast du eigentlich die geringste Ahnung wie wenig SSE Befehle durchschnittlich überhaupt in Software Verwendung finden? Würde es nur daran liegen, dann gäbe es diese Diskussion gar nicht.
Selbst mit der Bremse gibt es keine Garantie, daß der erzeugte Code auf Nicht-Intel-CPUs läuft. Sprich, die Bremse macht so gesehen keinen Sinn. Denn daß der Code 100%ig läuft ist in keinem Fall garantiert.
Belege?
Naja, eine gekünstelte Fehlermeldung bringen und dann den Start verweigern sehe ich schon als Einschränkung an.
Dir ist der Unterschied zwischen Einschränkung und Nicht-Funktionsfähig schon klar, oder?
Nein du hast natürlich Recht die Intel CPUID fehlt zur Gleichheit ;)
Hast du eigentlich die geringste Ahnung wie wenig SSE Befehle durchschnittlich überhaupt in Software Verwendung finden? Würde es nur daran liegen, dann gäbe es diese Diskussion gar nicht.
Ich glaube du hast keine Ahnung!
1. schrieb ich "SSE z.B.", das bezieht sich nicht ausschliech lauf SSE.
2. Wo fällt es denn am meisten aus? Bei Synthetischen Benchmarks, welche SSE beschleunigte Routinen hauptbestandteil ist, oder bei Mem-Transfer geschichten. für memcpy hat intel eigens eine routine für ihre CPU geschrieben, etc...
3. Programme, welche mit IntelCompiler versaut wurden, laufen auf AMDs immer noch schneller als mit AMD-freundlichen Compilern. Schon komisch diese Bremse, nicht wahr?
Exxtreme
2009-12-16, 21:40:22
Belege?
Die Abwesenheit einer Garantie kann man durchaus als Beleg werten. Oder hat Intel jemals garantiert, daß deren Compiler zu 100% zu anderen CPUs kompatibel ist? Wenn nein dann kann man sich die Bremse unter diesem Aspekt gleich sparen. Denn sie hat hier keinerlei Nutzen.
Da die Bremse wohl nicht unter diesem Aspekt eingeführt wurde, ist das ein weiterer Punkt, der bald vor Gericht verhandelt wird.
Dir ist der Unterschied zwischen Einschränkung und Nicht-Funktionsfähig schon klar, oder?
Sobald es ums Professionelle geht, gibt es hier keinen Unterschied ob nicht funktionsfähig oder eingeschränkt funktionsfähig.
Botcruscher
2009-12-16, 21:53:09
Belege?
Subtiler ist hingegen die Tatsache, dass Intel laut FTC Compiler so programmiert hat, dass Prozessoren der Konkurrenz beim SPEC-CPU-Benchmark den eigenen Produkten unterlegen waren. Über diese Compiler-Animositäten hatte c't bereits im Jahr 2005 berichtet und später auch einen Patch entwickelt, der Nicht-Intelianern zu einer spürbaren Performance-Steigerung verhalf. Intels Vorgehen sei Teil einer systematischen Kampagne, "überlegene Produkte von Wettbewerbern auszubremsen", die eine Bedrohung für den Marktanteil des Unternehmens darstellten, formuliert die FTC scharf.
http://www.heise.de/newsticker/meldung/US-Wettbewerbsbehoerde-eroeffnet-Verfahren-gegen-Intel-887834.html
Black-Scorpion
2009-12-16, 22:00:34
Schreib doch sowas nicht.
Das wurde auch schon auf Seite 1 geschrieben.
Das reicht aber als Beleg nicht.
Doch, AMD wird ausgebremst!
Es wird z.B. sehr schlecht optimierter Code verwendet, wenn kein Intel Prozessor im System ist.
Payne mach's halblang.
Der Intel-Compiler wird eh so gut wie nirgends verwendet. Deine Aufregerei kannst du dir sparen.
Ich weis auch nicht wo das große Diskussionspotential liegt. Wenn man durch das Ändern der CPUID bessere Ergebnisse erzielt sind doch die "Optimierungen" offensichtlich.
http://www.heise.de/newsticker/meldung/US-Wettbewerbsbehoerde-eroeffnet-Verfahren-gegen-Intel-887834.html
Beweis durch Behauptung? Trollig!
Nochmal: Bremse != nicht genutzte Optimierung
mit Beleg meinte ich den Beweis, welche es Aufzeigt, das Intel im Compiler bei Erkennen einer nicht-Intel-CPU unzählige NOPs ausführt!
Tut er nicht. Es wird dann nur der generische x87-Pfad statt jeglicher SSE-Optimierung verwendet.
Programme, welche mit IntelCompiler versaut wurden, laufen auf AMDs immer noch schneller als mit AMD-freundlichen Compilern. Schon komisch diese Bremse, nicht wahr?
Komische Argumentation. Nur weil andere Compiler schlecht sind ist es gut wenn Intel AMD-CPUs bewusst ausbremst? Das ist ein Fakt. Da brauchen wir nicht drüber streiten. Auf AMD-CPUs würde der SSE2-Pfad laufen und das auch deutlich schneller.
Ich bezweifle nur die allgemeine Relevanz. Intel C++ ist eher unbeliebt.
Undertaker
2009-12-16, 22:12:29
Darum geht es nicht. Sie pushen mit ihren Compiler ihre CPUs künstlich bzw. benachteiligen den Konkurrenten.
Und genau daran kann ich noch keinen Gesetzesverstoß erkennen (über Moral reden wir hier nicht). Keiner verlangt, dass AMDs Overdrive auf einer Intel-CPU überhaupt läuft.
Und seine wir doch mal ehrlich: Ohne eine entsprechende "Unterstützung" von Intel verwendet niemand ihren Compiler. Wer es tut der weiß worauf er sich einlässt.
Zum Teil ist Intels Compiler auch auf CPUs der Konkurrenz der schnellste verfügbare. Der Vorteil des MS-Compiler soll angeblich eher im weitaus besseren Support liegen, darum auch der erdrückende Marktanteil desselben.
Es ist sowieso sehr verwunderlich, dass ein Compiler, der mit einem so großen Budget entwickelt wird, einen derart niedrigen Marktanteil hat. Die Optimierungen abseits von SSE können da nicht wahnsinnig effektiv sein.
Tut er nicht. Es wird dann nur der generische x87-Pfad statt jeglicher SSE-Optimierung verwendet.
Nicht genutzte Optimieren != Bremse
Komische Argumentation. Nur weil andere Compiler schlecht sind ist es gut wenn Intel AMD-CPUs bewusst ausbremst? Das ist ein Fakt. Da brauchen wir nicht drüber streiten. Auf AMD-CPUs würde der SSE2-Pfad laufen und das auch deutlich schneller.
Dein Faktum nützt dir nicht, da du nicht zu 100% garantieren kannst das es auf allen erhältlichen AMD-CPUs absolut korrekt laufen wird.
Ich bezweifle nur die allgemeine Relevanz. Intel C++ ist eher unbeliebt.
Täusch dich da mal nicht, dieser wird häufiger eingesetzt als man denkt.
reunion
2009-12-16, 22:20:17
Und genau daran kann ich noch keinen Gesetzesverstoß erkennen (über Moral reden wir hier nicht). Keiner verlangt, dass AMDs Overdrive auf einer Intel-CPU überhaupt läuft.
Der Vergleich hinkt ja wohl gewaltig. Erstens hat AMD keine marktbeherrschende Stellung wodurch es schon legal wäre und zweitens benachteiligt Overdrive niemanden.
Zum Teil ist Intels Compiler auch auf CPUs der Konkurrenz der schnellste verfügbare. Der Vorteil des MS-Compiler soll angeblich eher im weitaus besseren Support liegen, darum auch der erdrückende Marktanteil desselben.
Da auf AMD-CPUs AFAIK keine ISA-Erweiterungen verwendet werden, kann ich mir bei besten Willen nicht vorstellen, dass der Intel-Compiler auf AMD-CPUs irgendwo der schnellste sein soll. Und selbst wenn wird AMD trotzdem benachteiligt.
Black-Scorpion
2009-12-16, 22:24:11
@Gast
Dann Beweise du doch mal das es so ist.
Alle sind Blöde und wissen nicht was sie erzählen.
Nur du weißt natürlich wie es läuft
Wie verblendet muss man eigentlich sein..
Nicht genutzte Optimieren != Bremse
Doch. Sie bremsen AMD-CPUs mutwillig aus, weil sie ihnen Code vorenthalten der auf ihnen garantiert lauffähig ist. Dafür gibt es das CPUID-Flag für SSE2 und nicht die Vendor-ID.
Dein Faktum nützt dir nicht, da du nicht zu 100% garantieren kannst das es auf allen erhältlichen AMD-CPUs absolut korrekt laufen wird.
NATÜRLICH kann man das garantieren.
AMD hält sich exakt an die SSE2-Spezifikation. Ich werd echt sauer wenn ich so einen Hirnfick les.
Mit dem gleichen dämlichen Argument würde jeglicher x86-Code nicht "garantiert" auf AMD-CPUs laufen. Was logischerweise kompletter Schwachsinn ist.
Undertaker
2009-12-16, 22:29:15
Der Vergleich hinkt ja wohl gewaltig. Erstens hat AMD keine marktbeherrschende Stellung wodurch es schon legal wäre und zweitens benachteiligt Overdrive niemanden.
Und nochmal, eine solche hat Intels Compiler auch nicht. Und ist eine vollständige Inkompatibilität besser als eine eingeschränkte Nutzbarkeit?
Ich wüsste nicht wo ein grundlegender Rechtsanspruch bestünde, dass der Compiler überhaupt mit anderen CPUs als Intel-Modellen nutzbar ist. Und wenn es doch läuft, wird es sehr schwierig sein, ein bewusstes Ausbremsen von einer fehlenden Optimierung zu trennen. Mit dem Argument "nur auf unseren CPU-Modellen getestet" kann man sich da aus praktisch allem herauswinden. Ob man das kritisch sehen möchte oder nicht.
Da auf AMD-CPUs AFAIK keine ISA-Erweiterungen verwendet werden, kann ich mir bei besten Willen nicht vorstellen, dass der Intel-Compiler auf AMD-CPUs irgendwo der schnellste sein soll.
Das ist aber so, definitiv schon mehrfach auch in der Fachpresse gelesen. Es findet sich bestimmt jemand hier, der dazu auch einen Link auftreiben kann.
Exxtreme
2009-12-16, 22:43:47
Und nochmal, eine solche hat Intels Compiler auch nicht. Und ist eine vollständige Inkompatibilität besser als eine eingeschränkte Nutzbarkeit?
Der Compiler ist auch nur ein Punkt unter vielen, die zur Anklage geführt haben. Seine Relevanz ist kaum vorhanden. Ich nenne das Teil deshalb gerne "SPEC-Compiler".
Hier noch ein netter Artikel zum Thema:
http://techreport.com/discussions.x/8547
Tut er nicht. Es wird dann nur der generische x87-Pfad statt jeglicher SSE-Optimierung verwendet.
Ich bezweifle nur die allgemeine Relevanz. Intel C++ ist eher unbeliebt.
SSE ist keine Optimierung sonder eine Erweiterung der ISA.
Der Compiler wird allerdings bei einigen werbewirksamen Anwendungen verwendet und dann gibts noch Spec.
SSE ist keine Optimierung sonder eine Erweiterung der ISA.
Vektorisierten SSE- statt skalaren x87-Code zu emittieren IST eine Optimierung im Rahmen der Gegebenheiten. Es kann im Peak-Fall bis zu vierfacher Durchsatz erreicht werden.
Intels Compiler nimmt diese Gegebenheiten mutwillig nicht zur Kenntnis und sorgt dadurch für eine vermeidbar schlechtere Performance auf Konkurrenzprodukten. Ich weiß nicht wie man sowas noch schönreden kann.
Eine ganz andere Diskussion ist aber wie gesagt die Relevanz, die ich nach wie vor extrem stark in Frage stelle.
Unter Linux & Mac ist überspitzt 99,9% der C/C++-Software mit GCC/LLVM kompiliert und unter Windows sieht man das genau gleiche mit MSVC.
reunion
2009-12-17, 07:26:32
Eine ganz andere Diskussion ist aber wie gesagt die Relevanz, die ich nach wie vor extrem stark in Frage stelle.
Unter Linux & Mac ist überspitzt 99,9% der C/C++-Software mit GCC/LLVM kompiliert und unter Windows sieht man das genau gleiche mit MSVC.
Wieviele Programme müssen es denn sein damit es für dich relevant ist? Reicht eh schon wenn auch nur eine Anwendung dadurch Intel-CPUs ungerechtfertigt bevorteilt. Der von vielen Testern genutzte Cinebench ist zB so ein Kandidat.
Wieviele Programme müssen es denn sein damit es für dich relevant ist?
Deutlich im zweistelligen Prozentbereich. So liegt das ganze doch nur unter "ferner liefen".
reunion
2009-12-17, 08:00:45
Deutlich im zweistelligen Prozentbereich. So liegt das ganze doch nur unter "ferner liefen".
Das bestreitet ja auch niemand. Vor dem Gesetz ist das aber gleichgültig da es um den CPU-Markt geht.
Das musst du mir jetzt erklären. Kaum ein Richter würde dem irgendwelche Bedeutung zumessen.
Du kannst jemanden nur mit Kartellrecht drohen, wenn er eine Monopolstellung auf irgend einem Gebiet hat. Bei Compilern hat Intel die sicher nicht. Intel kann es auch nicht ausnutzen um seine marktbeherrschende Stellung bei Prozessoren zu stärken, da der Compiler einfach keine Relevanz hat.
Der von vielen Testern genutzte Cinebench ist zB so ein Kandidat.
Quelle? Das Ding linkt gegen die Microsoft-Runtime. Hab gerade extra nachgeschaut. Man kann auch ohne Intel-Compiler die SSE-Abfrage von GenuineIntel abhängig machen.
Und selbst wenn. Es würden wohl in einem großen Feld von Tests wenn AMD sonst überall schneller wäre kaum jemand wegen Cinebench Intel kaufen.
reunion
2009-12-17, 09:02:52
Das musst du mir jetzt erklären. Kaum ein Richter würde dem irgendwelche Bedeutung zumessen.
Du kannst jemanden nur mit Kartellrecht drohen, wenn er eine Monopolstellung auf irgend einem Gebiet hat. Bei Compilern hat Intel die sicher nicht. Intel kann es auch nicht ausnutzen um seine marktbeherrschende Stellung bei Prozessoren zu stärken, da der Compiler einfach keine Relevanz hat.
Das ist eben dann eine Frage der Gerichte ob der Compiler bedeutend genug ist um die marktbeherrschende Stellung zu stärken. Man kann hier dem Urteil ohnehin nicht vorgreifen, der Standpunkt der Komission ist eben offensichtlich das auch eine geringe Stärkung eine Stärkung ist. Nicht das Ausmaß ist hier relevant, sondern die Intention. Als Unternehmen mit einer marktbeherrschende Stellung darf ist solche Dinge eben nicht machen um den Wettbewerb nicht zu gefährden.
Quelle? Das Ding linkt gegen die Microsoft-Runtime. Hab gerade extra nachgeschaut. Man kann auch ohne Intel-Compiler die SSE-Abfrage von GenuineIntel abhängig machen.
Und selbst wenn. Es würden wohl in einem großen Feld von Tests wenn AMD sonst überall schneller wäre kaum jemand wegen Cinebench Intel kaufen.
Moment da muss ich schauen. Ich bin jedenfalls fest davon überzeugt das gelesen zu haben. Und zu deinem zweiten Absatz: Da sind wir wieder beim Thema ab wann man etwas als relevant ansieht. Auch ein Bench verzerrt das Bild.
Exxtreme
2009-12-17, 09:04:14
Jetzt sind wir wieder sachlich und unterlassen die persönlichen Anmachen.
StefanV
2009-12-17, 11:56:32
Das musst du mir jetzt erklären. Kaum ein Richter würde dem irgendwelche Bedeutung zumessen.
Du kannst jemanden nur mit Kartellrecht drohen, wenn er eine Monopolstellung auf irgend einem Gebiet hat. Bei Compilern hat Intel die sicher nicht. Intel kann es auch nicht ausnutzen um seine marktbeherrschende Stellung bei Prozessoren zu stärken, da der Compiler einfach keine Relevanz hat.
Nun, hier gibts noch die Möglichkeit, diverse Benchmarks mit diesem Compiler zu schönigen (SPEC), was sicherlich auch relevant ist.
Gab doch vor einiger Zeit diese Ungereimtheit bei Futuremark Benchmarks (http://forum.chip.de/szenegefluester/futuremark-bevorzugt-intel-cpus-1056239.html), wo der VIA Prozessor als maskierter Intel deutlich schneller ward...
Nun, hier gibts noch die Möglichkeit, diverse Benchmarks mit diesem Compiler zu schönigen (SPEC), was sicherlich auch relevant ist.
Bei der Spec verwendet doch eh jeder Hersteller/Partner seinen bestmöglichen Compiler, um das meiste heraus zu holen. Wenn ein AMD-Partner die Spec-Werte seiner Kisten mit dem per ICC optimierten Kram angibt, hat er selber schuld :D
Exxtreme
2009-12-17, 16:38:22
Nun, hier gibts noch die Möglichkeit, diverse Benchmarks mit diesem Compiler zu schönigen (SPEC), was sicherlich auch relevant ist.
SPEC ist ein reiner Schwanzvergleich. Aufgrund der SPEC-Ergebnisse werden keine Entscheidungen gefällt. Die Sache mit dem Compiler ist schon recht aufgebauscht.
Armaq
2009-12-17, 19:25:04
SPEC ist ein reiner Schwanzvergleich. Aufgrund der SPEC-Ergebnisse werden keine Entscheidungen gefällt. Die Sache mit dem Compiler ist schon recht aufgebauscht.
Du irrst in diesem Punkt. Es gibt nicht sowas wie Unrelevanz bei derartigen Positionen. Wäre es tatsächlich so, wäre niemand daran interessiert. Da aber Kräfte darauf verwandt werden, ist es interessant.
roidal
2009-12-17, 19:35:41
SPEC ist ein reiner Schwanzvergleich. Aufgrund der SPEC-Ergebnisse werden keine Entscheidungen gefällt. Die Sache mit dem Compiler ist schon recht aufgebauscht.
Das mit SPEC mag zwar stimmen, aber ob eine Anwendung nun SSE verwendet oder nicht macht doch zum teil einen beträchtlichen Unterschied.
Exxtreme
2009-12-17, 19:47:02
Du irrst in diesem Punkt. Es gibt nicht sowas wie Unrelevanz bei derartigen Positionen. Wäre es tatsächlich so, wäre niemand daran interessiert. Da aber Kräfte darauf verwandt werden, ist es interessant.
Soviele Kräfte werden darauf nicht verwendet. AMD macht z.B. gar nix in Richtung eigener Compiler & SPEC. Lohnt sich für sie wohl nicht.
Das mit SPEC mag zwar stimmen, aber ob eine Anwendung nun SSE verwendet oder nicht macht doch zum teil einen beträchtlichen Unterschied.
Das mag schon sein. Der Punkt ist aber, fast niemand verwendet den Compiler von Intel. Somit hat diese Bremse nahezu keine realen Auswirkungen auf die Softwarewelt.
Normalerweise nimmt man den Compiler, der bei der Entwicklungsumgebung dabei ist. Microsoft hat viele eigene Compiler bei VS, Borland/Inprise hat eigene Compiler, Java sowieso, Mono auch etc. Und unter Linux verwendet auch fast niemand diesen Compiler von Intel. Da gibt es die GNU Compiler Suite. Ich glaube, Gentoo Linux ist das einzige Linux, welches eine Übersetzung mit dem Intel Compiler als Option anbietet.
Armaq
2009-12-17, 19:51:44
Soviele Kräfte werden darauf nicht verwendet. AMD macht z.B. gar nix in Richtung eigener Compiler & SPEC. Lohnt sich für sie wohl nicht.
Das mag schon sein. Der Punkt ist aber, fast niemand verwendet den Compiler von Intel. Somit hat diese Bremse nahezu keine realen Auswirkungen auf die Softwarewelt.
Normalerweise nimmt man den Compiler, der bei der Entwicklungsumgebung dabei ist. Microsoft hat viele eigene Compiler bei VS, Borland/Inprise hat eigene Compiler, Java sowieso, Mono auch etc. Und unter Linux verwendet auch fast niemand diesen Compiler von Intel. Da gibt es die GNU Compiler Suite. Ich glaube, Gentoo Linux ist das einzige Linux, welches eine Übersetzung mit dem Intel Compiler als Option anbietet.
Es geht aber um Intel. Sie sind so marktstark und machen zusätzlich solche Mätzchen. Intel hat sicher genug Geld fließen lassen, damit die FTC nicht aktiv wird, aber inzwischen reicht wohl nicht mal mehr das. Ich denke, dass die FTC aufgrund ihrer Struktur die Strafe von der Europ. Kommission locker verdreifachen wird.
reunion
2009-12-17, 19:53:20
SPEC ist ein reiner Schwanzvergleich. Aufgrund der SPEC-Ergebnisse werden keine Entscheidungen gefällt. Die Sache mit dem Compiler ist schon recht aufgebauscht.
In dem Punkt irrst du gewaltig. SPEC ist der Bench im Serverbereich schlechthin. Bestelle mal Server bei Dell, IBM und wie sie alle heißen, dann wirst du staunen was dort als Leistungseinteilung verwendet wird. Für jede neue Bestmarke in irgend einem SPEC Unterpunkt gibt es eine fette Pressemitteilung. etc. pp.
StefanV
2009-12-17, 20:08:12
Öhm, Armaq, ich denke nicht, dass man hier nur eine Geldstrafe verhängen wird, ganz im Gegenteil.
Ich denke eher, dass gerade das nicht passieren wird, siehe auch Wikipedia zum Sherman Act (http://en.wikipedia.org/wiki/Sherman_Act).
Ich würd eher vermuten, dass man Intel einige Patente aberkennt und z.B. das Busprotokoll für jeden öffnet, so dass auch nVidia Chipsätze dafür bauen kann/darf.
Alles weitere werden wir dann sehen...
Gibt auch einen Artikel auf Spiegel Online (http://www.spiegel.de/wirtschaft/0,1518,667649,00.html) zu der Sache.
Armaq
2009-12-17, 20:57:07
Öhm, Armaq, ich denke nicht, dass man hier nur eine Geldstrafe verhängen wird, ganz im Gegenteil.
Ich denke eher, dass gerade das nicht passieren wird, siehe auch Wikipedia zum Sherman Act (http://en.wikipedia.org/wiki/Sherman_Act).
Ich würd eher vermuten, dass man Intel einige Patente aberkennt und z.B. das Busprotokoll für jeden öffnet, so dass auch nVidia Chipsätze dafür bauen kann/darf.
Alles weitere werden wir dann sehen...
Gibt auch einen Artikel auf Spiegel Online (http://www.spiegel.de/wirtschaft/0,1518,667649,00.html) zu der Sache.
Ich meinte auch keine konkrete Geldstrafe, sondern eher die "Summe". Die FTC ist halt anders aufgebaut und hat auch andere Ansprüche als die Europ. Kommission, die ja aus dem EGV heraus dem Art. 5 so zu lesen ist: "Die Maßnahmen der Gemeinschaft gehen nicht über das für die Erreichung der Ziele dieses Vertrags erforderliche Maß hinaus."
Daher ist die Restriktion für die Kom. auch enger geknüpft. Die Amis kümmert das überhaupt nicht. Ansonsten haben sie die gleichen juristischen Probleme wie wir auch. Sie haben nur die dickeren Eier.
Edit: Ich habe gerade eine nette Passage im FTC-Act gefunden.
(3) This subsection shall not apply to unfair methods of competition involving commerce with foreign nations (other than import commerce) unless—
Die stellen Auslandsexportsachverhalte echt nicht unter Strafe, krass.
Stimmt so nicht.
Exxtreme
2009-12-17, 21:44:20
In dem Punkt irrst du gewaltig. SPEC ist der Bench im Serverbereich schlechthin. Bestelle mal Server bei Dell, IBM und wie sie alle heißen, dann wirst du staunen was dort als Leistungseinteilung verwendet wird. Für jede neue Bestmarke in irgend einem SPEC Unterpunkt gibt es eine fette Pressemitteilung. etc. pp.
Wenn der Benchmark soooo wichtig ist, warum macht AMD nichts in dieser Richtung? Die verkaufen doch auch Server und Opterons haben einen guten Ruf.
StefanV
2009-12-17, 22:14:18
Wenn der Benchmark soooo wichtig ist, warum macht AMD nichts in dieser Richtung? Die verkaufen doch auch Server und Opterons haben einen guten Ruf.
Weil man schlicht dafür keine Resourcen hat bzw man drauf acht geben muss, wie man was einsetzt?
Exxtreme
2009-12-17, 22:17:10
Weil man schlicht dafür keine Resourcen hat bzw man drauf acht geben muss, wie man was einsetzt?
Sprich, der Aufwand sich Resourcen zu besorgen und einen Compiler zu entwickeln ist höher als der Gewinn, den man mit höheren SPEC-Werten erzielen würde oder?
Sprich, der Aufwand sich Resourcen zu besorgen und einen Compiler zu entwickeln ist höher als der Gewinn, den man mit höheren SPEC-Werten erzielen würde oder?
Der tatsächliche wirtschaftliche Gewinn lässt sich wohl schwer abschätzen. So oder so können sich nur Monopolisten leisten so etwas Teures wie Compilerbau nur um den besseren Werten in manchen Benchmarks wegen zu betreiben.
reunion
2009-12-17, 22:28:46
Sprich, der Aufwand sich Resourcen zu besorgen und einen Compiler zu entwickeln ist höher als der Gewinn, den man mit höheren SPEC-Werten erzielen würde oder?
Einen guten Compiler schüttelt man nicht aus dem Ärmel. Das bedarf verdammt viel Man-Power, know-how, und Erfahrung. Und dann erzielt man vielleicht ein paar Prozent mehr Leistung. Diesen Luxus kann sich vielleicht Intel leisten, aber sicherlich nicht AMD.
Armaq
2009-12-17, 22:38:13
Sprich, der Aufwand sich Resourcen zu besorgen und einen Compiler zu entwickeln ist höher als der Gewinn, den man mit höheren SPEC-Werten erzielen würde oder?
Darum gehts ja. Es macht nur Sinn, wenn man schon Geld sch***.
StefanV
2009-12-17, 22:40:08
Sprich, der Aufwand sich Resourcen zu besorgen und einen Compiler zu entwickeln ist höher als der Gewinn, den man mit höheren SPEC-Werten erzielen würde oder?
Nein, man hat einfach kein Geld, einen eigenen Compiler zu entwickeln, man braucht es, um Chips zu entwickeln, there is no space in the budget...
roidal
2009-12-18, 08:46:27
Sprich, der Aufwand sich Resourcen zu besorgen und einen Compiler zu entwickeln ist höher als der Gewinn, den man mit höheren SPEC-Werten erzielen würde oder?
Entwickelt AMD nicht beim Gnu-C(++)-Compiler mit?
Dieser kann ja auch den Code auf den AMD-K10-Kern optimieren, ich weiß zwar nicht ob dieser im Endeffekt so gut optimieren würde als ein AMD eigener Compiler, aber ich denke mal dass der das ziemlich gut kann.
Der Compiler wird bei Intel-Partnern gerne eingesetzt. Es gibt zwar nur weniger Hersteller, die sich dermaßen "benutzen" lassen, die sind aber in Schlüsselpositionen, Massive z.B. ERs ist kein Zufall, dass in Intel-Reviews immer dieselben Spiele auftauchen, selbst wenn die keine Sau mehr spielt (z.B. WiC eben). Anderes berühmtes Beispiel ist ja die Cinebench10. Obwohl es neue Versionen von Maxon und mittlerweile Opteron x3xx Optimierungen offiziell gibt, ist eine Version 11 bis heute nicht erschienen. Warum wohl? Es ist nicht der Compiler als solcher der vor Gericht steht, er dient Intel als Machtinstrument, deshalb steht diese Thema in der Liste. Es geht darum, Intel die Mittel zur Monopolbildung wegzunehmen, um nichts anderes. Intel hat nur eine Chance: Die Auflagen der FTC zu erfüllen (Vergleich mit der FTC). Passiert das nicht und kämpft Intel bis zum letzten, endet Intel in der Zerschlagung, die Amis sind da rabiat.
Ich bin der Meinung, dass eine sinnvoll durchdachte Zerschlagung von Intel heute wirklich keine schlechte Lösung wäre. Der Laden ist so gross und mächtig geworden, das wird langsam gefährlich.
Bei einem Duopol eine der beiden Firmen zu zerschlagen, auch wenn es die größere ist, wäre das dümmste was man machen kann. Dazu wird es ganz sicher nicht kommen.
reunion
2009-12-19, 14:01:58
Bei einem Duopol eine der beiden Firmen zu zerschlagen, auch wenn es die größere ist, wäre das dümmste was man machen kann. Dazu wird es ganz sicher nicht kommen.
Begründung? Wenn die eine Firma 80% des Marktes hält ist das eher eine Notwendigkeit um eine freie Marktwirtschaft zu gewährleisten als "dumm".
Wenn du damit den 20%-Mitbewerber zum Monopolisten machst, bist du hinterher dümmer als zuvor.
reunion
2009-12-19, 14:22:12
Wenn du damit den 20%-Mitbewerber zum Monopolisten machst, bist du hinterher dümmer als zuvor.
Und warum sollte das geschehen? Wenn ich Intel "fair" teile wäre jeder Teil noch immer größer als AMD.
StefanV
2009-12-19, 14:23:37
Bei einem Duopol eine der beiden Firmen zu zerschlagen, auch wenn es die größere ist, wäre das dümmste was man machen kann. Dazu wird es ganz sicher nicht kommen.
Warum ists verkehrt, die Größe von Intel etwas zusammenzustutzen und einige (Teilbereiche) wegzunehmen??
Wenn man an sinnvollen Punkten ansetzt, z.B. CPUs, restliche Halbleiter und Fabriken, wäre das nicht allzu schlecht.
Wenn der Markt sich erholt hat (ie 50:50 oder sogar noch ein 3. mitspielt), kann man Intel ja auch wieder erlauben, die Chipsatzsparte einzukaufen.
Weil du die CPU-Sparte kaum so gezielt zerschlagen kannst, dass der Marktanteil genau auf ein gewünschtes Maß sinkt. Die Synergien der einzelnen Sparten sind zu groß. Wer hier dennoch den Hebel ansetzt, zerstört die Substanz. Die Gefahr, dass der Schuss dann nach hinten losgeht und AMD als einziges Unternehmen mit einem Angebot "aus einer Hand" den Markt an sich bindet, ist zu groß.
Weiterhin fehlen essentielle Voraussetzungen für eine Zerschlagung. 80% des CPU-Marktes sind ein erwähntes Duopol, in welchem Produkte von AMD wie Intel gemeinsam um Marktanteile ringen. Müsste ATI zerschlagen werden, wenn sich Fermi weiter verspätet und der Markt diskreter GPUs zu 80% an ATI geht - nur weil Nvidia keine gleichwertigen Produkte anbieten kann?
Armaq
2009-12-19, 14:52:26
Intel dominiert den Markt seit Jahrzehnten und das mit unlauteren Mitteln. Ich sehe hier kaum Probleme. Wenn man Intel zerschlägt sind genug lebensfähige Teilbereiche übrig. Allerdings wird das nicht passieren.
Lebensfähig womöglich schon. Das ist AMD allerdings auch. Einen Vorteil hätte man allerdings nur, wenn sich die Marktanteile angleichen und nicht nur vertauschen. Das ist von außen kaum steuerbar, noch wird eine Zerschlagung bei einem Duopol rechtlich machbar sein. Die klappt ja nicht einmal bei einem stark ausgeprägten Monopol wie bei Microsoft.
StefanV
2009-12-19, 15:03:15
M$ sollte zerschlagen werden bzw man war dabei das vorzubereiten.
"Dank" GWB wurde es dann aber nicht getan.
Die FTC hat jetzt also 4 Jahre Zeit, die Zerschlagung von Intel vorzubereiten und durchzuführen.
Ob Obama eine 2. Amtszeit schafft, weiß niemand, entsprechend muss man hier die Hacken nachziehen.
Lebensfähig womöglich schon. Das ist AMD allerdings auch. Einen Vorteil hätte man allerdings nur, wenn sich die Marktanteile angleichen und nicht nur vertauschen. Das ist von außen kaum steuerbar, noch wird eine Zerschlagung bei einem Duopol rechtlich machbar sein. Die klappt ja nicht einmal bei einem stark ausgeprägten Monopol wie bei Microsoft.
Warum sollten sich Marktanteile umdrehen wenn ein Konzern nach Sparten zerschlagen wird?
Die FTC hat jetzt also 4 Jahre Zeit, die Zerschlagung von Intel vorzubereiten und durchzuführen.
Du hast verkannt, worum es hier geht. Das ist nicht eine Zerschlagung.
StefanV
2009-12-19, 16:03:54
Du hast verkannt, worum es hier geht. Das ist nicht eine Zerschlagung.
Bisher geht es (noch) nicht um eine Zerschlagung.
Das kann sich aber ganz schnell ändern, wenn Intel sich nicht einsichtig zeigt und weiter macht wie bisher...
Bzw bisher wurd erst ein Verfahren eingeleitet, da ist noch nicht abzusehen, wie das Enden wird...
Fest steht nur, dass Intel nicht freigesprchen wird und es einige Konsequenzen für sie haben wird.
Fest steht nur, dass Intel nicht freigesprchen wird und es einige Konsequenzen für sie haben wird.
Auf Grund der schwierigen Beweisführung steht selbst das noch nicht wirklich fest. Sicher ist nur, dass sich der Prozess über Jahre ziehen wird, mit Revision noch länger.
Ihren Ursprung haben alle Anschuldigungen aus jener Zeit, wo Intel auf Grund unterlegener oder "nur" gleichwertiger Produkte ernsthaft unter Druck stand und sich womöglich genötigt sah, Maßnahmen zur Sicherung des Marktanteils ergreifen zu müssen. Spätestens seit Mitte 2006 und der Core 2 Generation besteht dazu kaum noch ein Anlass: Ohne Mühe könnten aktuelle Prozessoren um mehrere Speedgrades aufgebohrt werden und das gesamte AMD-Lineup selbst aus dem Mainstream-Bereich bis auf unterstes Low-Cost Niveau gedrückt werden - letztendlich lebt AMDs CPU-Sparte nur "von Intels Gnaden", die aus monopolrechtlichen Gründen beibehalten werden muss (ansonsten stünde in der Tat eine Zerschlagung im Raum).
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.