Indigo
raub_UrhG_vergewaltiger
|
Ich glaub wir sollten mal unterscheiden obs Kommerziell oder Technisch ein Reinfall war.
Technisch war z.B. BeOS eines der Fortschrittlichsten Systeme. Wie gut es sich verkauft hat dürfte ja bekannt sein.
Der P4 is Technisch am Sand (hat intel mittlerweile zugegeben). Dafür hat er sich gut verkauft. der p4 is technisch absolut ned am sand, nur is intel draufgekommen das, wenn die entwicklung so weitergeht, sie ziemlich bald anstehen in punkto prozesseigenschaften/handlebarkeit wegen zu hoher abwärme. nur weil sie einen anderen weg gehen als andere hersteller heisst das nicht das sie schlechte technologie entwickeln oder würdest du tecs ala Hyperthreading als am sand bezeichnen? ich jedenfalls nicht...
|
smashIt
master of disaster
|
oder würdest du tecs ala Hyperthreading als am sand bezeichnen? ich jedenfalls nicht... Genau das. Frei nach dem Motto: "Unser Prozi is zu schrottig um echtes Multithreading zu unterstützen, geben wir ihnen so ne emulierte kacke" Und bei Fehlschlägen in der Chip-Industrie fällt mir grad noch MMX ein.
|
Ringding
Pilot
|
Hallo? Wie geht's dir denn?
Welche CPU hat in einer nur irgendwie vergleichbaren Preisklasse MultiThreading? Was meinst du überhaupt? Multi-Core?
MMX wird eigentlich von jedem Codec, von PhotoShop und jedem Spiel intensiv verwendet und bringt auch einiges. Wo ist da der Fehlschlag?
|
smashIt
master of disaster
|
Sicher mein ich multicore.
Wenn dann schon richtig, und keine Husch-Pfusch Lösung.
Ich weis nicht wies bei dir steht, aber ich hab die einführung von MMX damals live miterlebt.
Das Teil war sogar so schrottig das man meistens Leistung verloren hat.
Schuld drann war das man beim P1 entweder MMX oder die FPU verwenden konnte. nochdazu dauerte das Umschalten zwischen beiden extrem lange.
Da hat AMD mit 3DNow weit bessere arbeit geleistet.
(schon mal wer die Q2-Version mit 3DNow-Support verwendet? )
|
HaBa
LegendDr. Funkenstein
|
ursprünglich war der grund für die 2-stelligen Jahreszahlen, das man nur wenig Arbeitsspeicher zur Verfügung hatte und der war so teuer, das es auf jedes Byte angekommen ist. In den 1960ern hat 1kB RAM soviel gekostet wie ein ganzes Haus. Die Programmierer haben sowieso nicht gedacht, das ihr Code im y2k noch verendet wird.
Danach war das Problem, das die Programmierer zu Faul waren und diesen Cpode einfach nur übernommen haben, bis sie mitte/ende der neunziger draufgekommen sind, das ihr Code Probleme machen könnte und sie endlich was unternehmen müssen... Und auch das war keine Faulheit  Coden kostet Geld (ich rede nich von CD-Verwaltungen im Access ..) Alles was extra gemacht werden muss muss auch bezahlt werden => we rmacht das? Bsp aus meiner alten Firma: Code entstand Anfang der 90iger => HDDs und RAM kosteten Masse Geld => wurde aus Platzersparnisgründen (und somit Geldersparnis) nur 2 Stellen hergenommen. Bei jeder Programmevolution wurde die für den Kunden billigste Lösung hergenommen (ja, arbeit kostet Geld) => dabei wurde imemr alles gleich gelassen, war dadurch auch performanter (wir reden von 486er als Server, 386er als WS und 10MBit) => ich hatte Kunden denen der Audruck eines Rezeptes (7s) zu lange dauerte, da sind 1% Performance die durch eigentlich sinnlose "19"er verlorengehen oft schon zu viel gewesen ... 1999 haben wir zu 2t das Programm Y2K-fest gemacht => Sichtung von Jänner bis Ende Februar, ab März bis Ende August gecoded, ganzen September Test, Rollout dann ab Mitte Oktober ca. ... => 25MB Quellcode schaut man nicht "auf die Gache" durch, noch dazu wenn es sich um Cobol handelt ... Gab keine Abstürze oder Datenverluste etc., aber auch kein extra Geld der Kunden für die Hacke (bei der Konkurrenz mussten die Kunden bezahlen und standen dann alle bis zu 14 Tagen, war damals ein Genuss denen beim Schwitzen zuzusehen  ) => ich würde empfehlen deine Heimuser-Erkenntnisse nicht auf diese Themengebiete anzuwenden ...
|
grassi3000
radeon gefrierer
|
Sicher mein ich multicore.
Wenn dann schon richtig, und keine Husch-Pfusch Lösung. Ich würde Hyperthreading nicht als Husch-Pfusch bezeichnen. Immerhin schafft Intel dadurch eine bessere ausnutzung der Prozessorleistung, bei fast gleichbleibenden Hardwarefertigungsaufwand. Würden die Multicores machen, so wäre der Fertigungsaufwand bei der HW um einiges höher, aber beide/mehrere Prozessoren wären nicht optimal ausgelastet. Drum die schritte: Prozessor auslasten und dann erst multicore.
|
Indigo
raub_UrhG_vergewaltiger
|
Sicher mein ich multicore.
Wenn dann schon richtig, und keine Husch-Pfusch Lösung. alter, weist duzu wieviel prozent der core des p4 in der regel unter "vollast" ausgelastet ist? wennst 25% reale auslastung zambringst kannst scho froh sein, und von dem her gesehen is hyperthreading eine SEHR EFFIZIENTE lösung zur steigerung der effizienz des cores, ich bin mir sicher das sich das bei einer p4 cpu problemlos noch auf 4 virtuelle cpus erweitern lassen würde... die einführung von mmx war damals eigentlich auch nur deswegen so schlecht von der performance her, weil die compiler das noich nicht richtig optimieren konnten. btw. is die implementation von mmx auch heute noch so, das entweder FPU oder MMX aktiv sein können...
|
GNU
Friedensbringer
|
Ab SuSE 8.0
Palm Os
MFG
|
daisho
SHODAN
|
Ich weis nicht, irgendwie scheint hier jeder einfach sachn reinzuschreiben die er für blöd hält oder einfach mal grad nicht so gut kennt  
|
smashIt
master of disaster
|
Mit deinen 25% Auslastung brauchst weder Multicore noch Hyperthreading.
Das ganze fällt erst ins gewicht wennst den Chip voll ausreitzt,
Und da bietet Multicore den vorteil dast mehrere getrennte Programme gleichzeitig ausführen kannst.
Und wenn ich mir die 125 Millionen Transistoren vom Prescott anschau bin ich mir sicher da hätt man schon 4-8 ordentliche Cores mit ner kurzen Pipeline draufgebracht.
|
SYSMATRIX
Legend
Legend
|
naja shared L2 und shared L3 is halt so eine sache.
der power4 hat ja nur zwei getrennte execution units, aber rest is überlappend, sprich geshared.
das erste echte dual core device wird wohle der Mentecino werden mit 256kb I L2 cache und 512kb D L2 cache pro core und je 12MB L3 je core, der die wird auf ~ 600 mm² geschätzt und ist so ziemlich die _grenze_ des physikalisch machbaren bei den aktuellen lithographieprozessen.
|
smashIt
master of disaster
|
Das kommt ganz auf den aufbau an.
Das Cache-Problem hast ja nur wenn die CPU Daten schneller verarbeitet als der normale Speicher liefern kann.
Wenn ich z.B. 4 Cores mit je 1 GHz betreib, und jeder core nen eigenen Mem-Controller verpass müßten der L3 völlig überflüssig sien und 256K L2/Core ausreichen.
DAs geht aber dann eben wieder in richtung NUMA (wobei bei 4 Cores ein normales SMP-Design noch völlig ausreichend währe)
Bei der Alpha (ich glaub ab der BUS-Version 6.2) wars z.B. so das wenn eine Speicherzelle nicht im Cache der CPU war, erst der Chache der anderen CPUs dursucht wurde bevor auf den RAM zugegriffen wurde.
Das heist, um wieder das 4-Core beispiel zu nehmen, das effektiv 256K L2 und 3x256K L3 Cache zur verfügung standen.
|
SYSMATRIX
Legend
Legend
|
Das kommt ganz auf den aufbau an.
Das Cache-Problem hast ja nur wenn die CPU Daten schneller verarbeitet als der normale Speicher liefern kann. ich würde sagen das ist so in 99.999999% der fälle so. Wenn ich z.B. 4 Cores mit je 1 GHz betreib, und jeder core nen eigenen Mem-Controller verpass müßten der L3 völlig überflüssig sien und 256K L2/Core ausreichen. das ist so stichhaltig arm und technisch unfundiert, daß ich nichtmal lust hab ein argument dagegen zu liefern. DAs geht aber dann eben wieder in richtung NUMA (wobei bei 4 Cores ein normales SMP-Design noch völlig ausreichend währe)
Bei der Alpha (ich glaub ab der BUS-Version 6.2) wars z.B. so das wenn eine Speicherzelle nicht im Cache der CPU war, erst der Chache der anderen CPUs dursucht wurde bevor auf den RAM zugegriffen wurde. was ist ein normales SMP design? aber das cache coherence protokoll des EV5/6/7 soll angeblich das komplizierteste existierende seiner art sein. die designer selbst waren verwundert das es funktioniert. so eine beschreibung wie da oben kommt mir dennoch komisch vor. dieses directory based cc läßt so ein szenario ja beinahe garn icht vorkommen. afair hatte das 4 states: local(im l1/l2 der cpu), shared (alle cpus haben eine kopie davon), excluive (nur in einer cpu) und an den 4 state kann ich mich nicht erinnern. Das heist, um wieder das 4-Core beispiel zu nehmen, das effektiv 256K L2 und 3x256K L3 Cache zur verfügung standen. das ist so ziemlich das schlechteste modell zur beschreibung der mem-hierarchie beim alpha das ich je gelesen hab.
|
Anmeldung