snorreh Skrevet 16. november 2004 Del Skrevet 16. november 2004 a) it released years too late Noen vil kanskje si IPF er forut for sin tid og vil mislykkes av den grunn. Må innrømme at jeg har problemer med å ta poenget (at det har godt lang tid fra prosjektet ble startet til produktet lå på bordet?) [...] (ja, jeg regner fortsatt IPF for å være i introduksjonsfasen) Der tar du nok ganske feil dessverre, så jeg anbefaler at du oppfrisker historiekunnskapene dine med å lese dette: http://www.brainyencyclopedia.com/encyclop...it/itanium.html Design of the Itanium series started in 1994, based on pioneering research by Hewlett-Packard into VLIW designs. The original HP design was "clean", but that is to be expected from a design that was never to be used in a production setting. After Intel became involved the cleanliness of the original design was marred by the addition of several new capabilities needed for "real work" use, notably the ability to run IA-32 instructions, and HP adding their own features to ease migration from the HP-PA. The project has met with lackluster market success. Originally planned for release in 1997, the schedule slipped several times. In 2001 the first version, code named Merced and manufactured on a 180 nm process, shipped. Speeds of 733 and 800MHz were offered, with a choice of 2Mb or 4Mb off-die L3 cache. Prices ranged from US$1200 to over US$4000. However, performance was disappointing. In IA-64 mode, it performed only slightly better than an equivalently clocked x86 design, and when running x86 code, performance was extremely poor, about 1/8th that of an similarly clocked x86 processor. Soon even Intel suggested it wasn't a "real" release. The main (though by no means only) problem with the Itanium was that the latency of its third-level cache was extremely high, which resulted in the amount of usable bandwidth being greatly reduced. Intel was forced to use an on-die solution for the next design Sjekk linken for flere interessante detaljer om Itanium. Lenke til kommentar
el-asso Skrevet 16. november 2004 Del Skrevet 16. november 2004 a) it released years too late Noen vil kanskje si IPF er forut for sin tid og vil mislykkes av den grunn. Må innrømme at jeg har problemer med å ta poenget (at det har godt lang tid fra prosjektet ble startet til produktet lå på bordet?) [...] (ja, jeg regner fortsatt IPF for å være i introduksjonsfasen) Der tar du nok ganske feil dessverre, så jeg anbefaler at du oppfrisker historiekunnskapene dine med å lese dette: http://www.brainyencyclopedia.com/encyclop...it/itanium.html Design of the Itanium series started in 1994, based on pioneering research by Hewlett-Packard into VLIW designs. At jeg tar feil når jeg sier at IPF fortsatt er i introduksjonsfasen ? Tja, nå er det slik at de ulike fasene i et produkts livssyklus ikke er låst til et bestemt antall år. Dette må sees i sammenheng med den totale levetiden på produktet, dessuten er det ikke planleggingsfasen (startet i 1994) for Itanium jeg snakker om. Med introduksjonsfasen mener jeg den første delen av levetiden, om denne er ett år eller ti år er likegylding, det kommer som sagt an på den totale levetiden for prosjektet/produktet. Her er det i tillegg snakk om en "familie" av kompliserte produkter der overgangen mellom de ulike fasene i livssyklusen (introduction, early life, useful life, wear out period) vil være ganske diffus. Så inntil Itanium foreligger med egenskaper som er tilnærmet lik målsettingen velger jeg å si at IPF er i introduksjonsfasen. Men det er rom for tolkning. Lenke til kommentar
Knick Knack Skrevet 16. november 2004 Del Skrevet 16. november 2004 (endret) Introduksjonsfase eller ikke. Jeg støtter at Itanium kom ut forut for sin tid. Om en ser på instruksjons formatet ("pakker" på 3) og sammenligner det med Itanium 2 så ser en klart at Itanium 2 (håndterer 2 "pakker"/syklus) er det smaleste designet som gir ordentlig mening å implementere da 1 "pakke"/syklus blir svært ineffektivt i forhold til hvor mange I, M, B og F units en må ha. (Paul Demone har forklart dette i detalj på RWT) Itanium 1 var for smal og det visste de, men det var ikke særlig praktisk mulig å implementere et kraftigere desig enn Itanium 1 på den tiden. Selv Itanium 2 var for kraftig til å bli implementert på 180nm prosessen og det er helt klart at det er først på 130nm prosessen at en har klart å balansere design å produksjonsprosess sånn rimelig greit. rimelig greit som i willy var rimelig greit tilpasset 180nm prosessen. På samme måte som Northwood var godt balansert til 130nm prosessen og ville vært det til 90nm prosessen så kommer Itanium 2 til å være godt balansert til 90nm og 65nm. Siden Itanium 2 er det minste IPF designet som er fornuftig og fordi dette designet ikke blir virkelig godt balansert med produksjonsprosessen før på 90nm, kan en si at IPF har vært forut for sin tid. Om en begynte å pønske på designet i 1950 eller 2000 er irrelevant for arkitektur/prosess sammenhengen. Ser en det fra en software perspektiv eller i forhold til hva HP/Intel har forespeilet oss så er den selvsagt forsinket men hverken HP eller Intel kan bryte fysikkens lover så det blir vi pent nødt til å leve med. Nå har det forøvrig kommet et nytt inlegg på Aces som var svært interessant: http://www.aceshardware.com/forum?read=115112595 Godt gjenomtenkt innlegg det der. Dette burde kanskje være av spesiell interesse for deg snorreh: Also, how big of a code bloat would really really be that significant? On a 3 GB PC game, you usually don't see much more than 10 MB of code. The rest is all content. Kode vokser langt senere enn data og det er faktisk et alment akseptert faktum at kodestørrelse er et ikke tema. Greit det har noen konsekvenser en må håndtere, men en vinner som regel mye mer enn en taper. Endret 16. november 2004 av Knick Knack Lenke til kommentar
snorreh Skrevet 16. november 2004 Del Skrevet 16. november 2004 At jeg tar feil når jeg sier at IPF fortsatt er i introduksjonsfasen ?Tja, nå er det slik at de ulike fasene i et produkts livssyklus ikke er låst til et bestemt antall år. Dette må sees i sammenheng med den totale levetiden på produktet, dessuten er det ikke planleggingsfasen (startet i 1994) for Itanium jeg snakker om. Med introduksjonsfasen mener jeg den første delen av levetiden, om denne er ett år eller ti år er likegylding, det kommer som sagt an på den totale levetiden for prosjektet/produktet. Her er det i tillegg snakk om en "familie" av kompliserte produkter der overgangen mellom de ulike fasene i livssyklusen (introduction, early life, useful life, wear out period) vil være ganske diffus. Så inntil Itanium foreligger med egenskaper som er tilnærmet lik målsettingen velger jeg å si at IPF er i introduksjonsfasen. Men det er rom for tolkning. Tja, det virker ikke som hverken Intel eller HP har hatt eller har noen klar målsetning med Itanium. Hvilken målsetning mener du det skulle være? Den virker å være et resultat av komité-arbeid der resultatet ble "Ja takk, vi tar alt sammen". Første generasjons Itanium burde aldri ha bli sluppet ut på markedet, men burde heller ha blitt på labben for å luke bort ting i arkitekturen som er mindre effektive. Pga. denne "tabben", så sliter dagens Itanium fortsatt med unødvendig bagasje man ikke kan bli kvitt. Det er nå 10 år siden Itanium-prosjektet ble igangsatt, og har vært et ekstemt kostbart eksperiment for alle innvolverte parter. Fremtidsutsiktene ser heller ikke særlig positive ut, spesielt ikke hvis Itanium fortsatt blir regnet for å være i en introduksjonsfase. Lenke til kommentar
snorreh Skrevet 16. november 2004 Del Skrevet 16. november 2004 (endret) Nå har det forøvrig kommet et nytt inlegg på Aces som var svært interessant:http://www.aceshardware.com/forum?read=115112595 Godt gjenomtenkt innlegg det der. Dette burde kanskje være av spesiell interesse for deg snorreh: Ja, absolutt interessante meninger det der - selv likte jeg best dette: OOOE processors are still generally better simply because you don't need a magic compiler to get good results. And in turn good compiler results depend on good code coming in... Ever read through source code from companies like Monolith or EA? Hell, I've seen modern DirectX game engines that have leftover render code for Amiga... It's a mess. Det at Itanium er totalt avhengig av "magiske" (les: utrolige) kompilatorer for å yte brukbart er et fundamentalt problem som konkurrerende plattformer ikke har. Vincent Diepeveen hadde forøvrig et passende innlegg om dette her: http://www.aceshardware.com/forum?read=115112808 Instead of making 2 chips P4 and itanium, both designed in a way that they can get produced in such a way to maximize the profit a chip, leaving the problems to solve to the compiler team, intel better make 1 good chip that is both good in floating point and delivers a good performance for its users at integer software. If you add a bit of L3 cache to such chip then, you can sell it as highend Xeon chip. Right now it is a race of the defeated what intel is doing. Speeding up the memory controller of itanium2 of course doesn't mean that accessing memory goes faster than competitors. It just means that the huge gap there will get a bit smaller. But please imagine. In 2006+ producing a chip with an off chip memory controller? Imagine that a new fighter gets produced with propellors, using the claim: "they are faster than the previous generation of propellors". Those opponents will shoot 'em down like ducks. We are in the jet age now! Endret 17. november 2004 av snorreh Lenke til kommentar
Knick Knack Skrevet 17. november 2004 Del Skrevet 17. november 2004 (endret) Snorreh: Vincent Diepeveens argument for ODMC kan du like gjerne bruke for IA64 kontra AMD64. x86 er for probell å regne mot IA64. Når det gjelder bruk av ODMC så har jeg skrevet hva jeg tror om det på Aces tidligere. For å oppsummere kort: Chip interconnect er i ferd med å gjøre et teknologisk hopp (FB-DIMM, PCIe, Infiniband) ved overgang til dual-simplex arkitekturer på fysisk/elektrisk nivå. Det vil medføre at frekvensen til interconnect vil ta igjen on chip klokka og muligens gå forbi. Slik at en i fremtiden (typisk 2007) ser noe i retning av "P5"2.5GHz, 5GHz FSB. Da faller fordelen med ODMC nesten bort. I tillegg kommer ymse versjoner av multithreading til å skjule minneforsinkelser og en ender opp med eksakt samme throughput for to ellers like design der den ene har ODMC. Kun singel tråd ytelse vil hå nevneverdig nytte av ODMC i 2006. Altså vil servere uten ODMC ikke ha noe problem med å konkurere. På desktop/workstation vil ODMC ofte kunne være til nytte siden en gjerne har et begrenset antall tråder med full last. Har du imidlertid mulighet til å fyre opp to cpu intensive tråder per core så vil det ha større inflytelse på utnyttelsesgraden av CPU enn en ODMC. Når det gjelder kompilatorer så har IPF fortsatt igjen en god vei å gå. Desverre for dens konkurrenter! Kompilatorene er imidlertid blitt svært mye bedre bare i år og som en ser av ytelsesgevinsten i blandt annet Java så er IPF nå fullt på høyde med konkurrentene. At det fortsatt er en del å gå på er jo bare synd for de som per i dag har svært optimale kompilatorer, slik som x86. De har ingen "gratis" forbedring av nevneverdig størrelse å se frem til. Endret 17. november 2004 av Knick Knack Lenke til kommentar
Knick Knack Skrevet 17. november 2004 Del Skrevet 17. november 2004 (endret) En fyr på Aces har nå endelig funnet et slags veikart som beskriver hva jeg har babla om i over en måned nå: http://www.aceshardware.com/forum?read=115112907 Seriell FSB er fremtiden i maskiner med to eller flere sockets. Av kompatibilitets hensyn og fleksibilitet vil den sikket bli foretrukket i maskiner med en socket også. Her er bildet: http://pc.watch.impress.co.jp/docs/2004/1117/kaigai01l.gif Først vises dagens system med parallelt minne og CPU kommunikasjon (seriell IO, PCIe er ikke vist). Så kommer FB-DIMM som neste skritt, antagelig tidlig i 2005. Deretter blir FSB og Northbridge (NB) gjort seriell. IO er jo allerede seriell så NB håndterer nå kun serielle signaler. Til slutt blir parallell/seriell broen som kommer på FB-DIMM minne modulene til å bli integrert i selve DRAM brikken. Dette er i praksis hva RDRAM har gjort i flere år nå. Disse tiltakene vil ha langt større invirkning på minne forsinkelse enn ODMC, særlig i systemer med mange sockets. Endret 17. november 2004 av Knick Knack Lenke til kommentar
snorreh Skrevet 17. november 2004 Del Skrevet 17. november 2004 Snorreh: Vincent Diepeveens argument for ODMC kan du like gjerne bruke for IA64 kontra AMD64. x86 er for propell å regne mot IA64. Hehe, isåfall er Itanium en jetmotor der rotorbladene står feil vei Når det gjelder bruk av ODMC så har jeg skrevet hva jeg tror om det på Aces tidligere. For å oppsummere kort: Chip interconnect er i ferd med å gjøre et teknologisk hopp (FB-DIMM, PCIe, Infiniband) ved overgang til dual-simplex arkitekturer på fysisk/elektrisk nivå. Det vil medføre at frekvensen til interconnect vil ta igjen on chip klokka og muligens gå forbi. Tror du virkelig at utviklingen av integrert minnekontroller (ODMC) og HyperTransport kommer til å stå stille? HyperTransport 2.0 er allerede klar, og du har kanskje fått med deg HTX også? Se her: http://forum.hardware.no/index.php?showtopic=328099&hl= Slik at en i fremtiden (typisk 2007) ser noe i retning av "P5"2.5GHz, 5GHz FSB. Da faller fordelen med ODMC nesten bort. I tillegg kommer ymse versjoner av multithreading til å skjule minneforsinkelser og en ender opp med eksakt samme throughput for to ellers like design der den ene har ODMC. Kun singel tråd ytelse vil hå nevneverdig nytte av ODMC i 2006. Altså vil servere uten ODMC ikke ha noe problem med å konkurere. På desktop/workstation vil ODMC ofte kunne være til nytte siden en gjerne har et begrenset antall tråder med full last. Har du imidlertid mulighet til å fyre opp to cpu intensive tråder per core så vil det ha større inflytelse på utnyttelsesgraden av CPU enn en ODMC. Nei, det har jeg ingen tro på for å være ærlig. Fordelen med integrert minnekontroller på hver prosessor er først og fremst bedre skalering av minnebåndbredden, og kombinert med HyperTransport for bedre skalering av I/O-båndbredden gir dette både en mer fleksibel og rimeligere løsning. Det stemmer ikke at integrert minnekontroller bare er nyttig i enkeltrådsoppgaver, faktisk viser den sin største styrke i 2+veis systemer (jf. Opteron vs. Xeon MP). HyperTransport har også så langt vist seg å klokke bedre enn noen annen busstopologi, så jeg har ingen tro på 5GHz FSB (Intel sliter jo f.eks. med å få 1066FSB til å fungere på Prescott). Hovedpoenget med å gå til flerkjerne-teknologi er for å øke flertrådsytelse og parallellisering av problemer, altså skifte fokus bort fra enkelttrådsproblematikk. Ikke la deg blende altfor mye av Spec-tester Når det gjelder kompilatorer så har IPF fortsatt igjen en god vei å gå. Desverre for dens konkurrenter! Kompilatorene er imidlertid blitt svært mye bedre bare i år og som en ser av ytelsesgevinsten i blandt annet Java så er IPF nå fullt på høyde med konkurrentene. At det fortsatt er en del å gå på er jo bare synd for de som per i dag har svært optimale kompilatorer, slik som x86. De har ingen "gratis" forbedring av nevneverdig størrelse å se frem til. Tja. Igjen baserer du deg bare på Spec-tester, som du snart må lære deg å ta med en spade salt spesielt med tanke på reelle ytelsestall. Jeg ser lite til denne såkalte store ytelsesforbedringen i Java på Itanium med BEA 8.1 SP3 på mine problemer iallefall. Med dobling av antall registre så har AMD64 gitt x86 en pen ytelsesforbedring i nesten alle ting, og alt som kreves her er stort sett en enkel rekompilering. Likevel så har ytelsen på kompilatorer ikke forbedret seg mer enn 20-30% de siste 20 årene, mens ytelsen på prosessorene har mangedoblet seg siden den gang. Det er temmelig naivt å tro at ytelsen på kompilatorer kommer til å bedre seg noe særlig i fremtiden heller, ettersom programvare har en tendens til å henge etter maskinvare likevel. Lenke til kommentar
b0nna Skrevet 17. november 2004 Del Skrevet 17. november 2004 As I predicted! moahahaha!! Lenke til kommentar
Knick Knack Skrevet 17. november 2004 Del Skrevet 17. november 2004 (endret) snorreh: svarene dine tyder på at du ikke har fått med deg essensen i hva jeg har skrevet. Det er nytteløst å fortsette før du har lest posten min så nøye at du forstår mine påstander. Her er hva du bør jobbe med å forstå: 1) Nei jeg kjenner ikke til HTX det er derfor jeg har postet i HTX tråden du linker til. Det har forøvrig ingenting med tema å gjøre. 2) Den hypotetiske 5GHz FSB arkitekturen er en seriell dual-simplex arkitektur og har absolutt ingenting med dagens problem med frekvensskalering av parallell (multi-drop) half-duplex FSB. 3)Hypertransport er ikke den mest avanserte buss teknologien der ute og den er langt fra den som øker frekvensen best. Alle dual-simplex link arkitekturene er mer avensert enn HT som er full-duplex. Disse dual-simplex standardene er blandt annet PCIe, FB-DIMM og Infiniband. PCIe opererer i dag på 2.5GT/s mot HTT sine 2GT/s og fremtidige 2.8GT/s. Infiniband opererer i dag på 2.8GT/s over avstander som er lengre enn HTX støtter. FB-DIMM er foreløpig ukjent men de skal støtte minst DDR2-800 på en 14bits (2 paritets bit) bred link. Det tilsvarer 4.2GT/s. Dette er link teknologien Intel antagelig ønsker å benytte i sin serial FSB og da ser du at ca 5GT/s (GHz) ikke er så usannsynlig. way beyond HTT 4) Interessant hvordan tester blir irelevante med en gang Opteron ikke leder. Dette tror jeg er et av dine største kredibilitets problemer. I 2006 vil det ikke eksistere en enesete relevant test etter denne definisjonen. IPF og Power5 kommer til å ta alt av "best ytelse" tester. Endret 17. november 2004 av Knick Knack Lenke til kommentar
snorreh Skrevet 17. november 2004 Del Skrevet 17. november 2004 En fyr på Aces har nå endelig funnet et slags veikart som beskriver hva jeg har babla om i over en måned nå:http://www.aceshardware.com/forum?read=115112907 Seriell FSB er fremtiden i maskiner med to eller flere sockets. Av kompatibilitets hensyn og fleksibilitet vil den sikket bli foretrukket i maskiner med en socket også. Her er bildet: http://pc.watch.impress.co.jp/docs/2004/1117/kaigai01l.gif Ser absolutt interessant ut, ikke helt ulikt med hvordan punkt-til-punkt HyperTransport og PCI-Express fungerer idag. Det er på høy tid at Intel også oppdaterer bussen på sine prosessorer, siden den representerer en klar flaskehals i deres flerprosessor-løsninger (ref. Xeon MP/Itanium): http://blogs.msdn.com/craigmcmurtry/archiv.../05/252858.aspx The typical x86 processor prior to the Opteron accessed memory via a memory controller located on a separate chip called the North Bridge, which also served as the connection to the Level 2 cache, the AGP slot, and some of the PCI devices. So, a lot of traffic was traveling over the connection between the processor and the North Bridge, a connection called the Front Side Bus. That connection became a bottleneck, slowing down access to memory. In multi-processor systems, the processors shared the Front Side Bus, so the bottleneck became even more severe. An Opteron processor has a memory controller built right in, so data in memory does not have to travel to the processor via the North Bridge across the Front Side Bus. Furthermore, the processors do not compete for access across the Front Side Bus, but, where they need to access memory via one another’s memory controllers, they do so across a dedicated connection channel called the HyperTransport that is controlled by logic built into the processors rather than into external chips. In theory, not only is performance improved, but scalability is improved as well, while costs decrease because fewer chips are required. Lenke til kommentar
Knick Knack Skrevet 17. november 2004 Del Skrevet 17. november 2004 (endret) Ser absolutt interessant ut, ikke helt ulikt med hvordan punkt-til-punkt HyperTransport og PCI-Express fungerer idag. Det er på høy tid at Intel også oppdaterer bussen på sine prosessorer, siden den representerer en klar flaskehals i deres flerprosessor-løsninger (ref. Xeon MP/Itanium): Ja det er korrekt. Punkt til punkt naturen til seriell FSB og PCIe er lik den i HTT. De benytter riktig nok en litt annen elektrisk løsning, men mye er likt. Blandt annet er alle disse linkene full duplex sett på lag 2 OSI, men PCIe er egentlig dual-simplex. PCIe har heller ikke egne ledere for klokke men det har faktisk FB-DIMM (om den brukes til klokking av linken er jeg faktisk usikker på) og HTT. Hovedforskjellen er at de nyere dual simplex arkitekturene kan støtte høyere frekvenser siden en slipper å trekke fra mottatt signal slik en må i en full duplex arkitektur som HTT. Det vil antagelig også være forskjeller på topologien Intel velger. Jeg antar de velger stjerne topologi med NB i midten og alt minne og alle CPU'er koblet til direkte med hver sin dedikerte link. AMD bruker som kjent et maskenett med minnet distribuert utover i nettet. Dette er selvsagt en billigere løsning, men den gir dårligere skalering. Vel og merke er begge løsningene langt bedre enn den multi-drop FSB arkitekturen Intel benytter i dag. Endret 17. november 2004 av Knick Knack Lenke til kommentar
snorreh Skrevet 17. november 2004 Del Skrevet 17. november 2004 snorreh: svarene dine tyder på at du ikke har fått med deg essensen i hva jeg har skrevet. Det er nytteløst å fortsette før du har lest posten min så nøye at du forstår mine påstander. Joda, men det er vanskelig å ta dine påstander seriøst siden du er så ensidig negativ til integrerte minnekontrollere selv om det åpenbart har sine klare fordeler allerede i dag. Her er hva du bør jobbe med å forstå: 1) Nei jeg kjenner ikke til HTX det er derfor jeg har postet i HTX tråden du linker til. Det har forøvrig ingenting med tema å gjøre. Vel, se innlegget mitt vedrørende Pathscale InfinPath HTX-adapter. 2) Den hypotetiske 5GHz FSB arkitekturen er en seriell dual-simplex arkitektur og har absolutt ingenting med dagens problem med frekvensskalering av parallell (multi-drop) half-duplex FSB. Klart det, det er jo dagens parallelle buss som den serielle punkt-til-punkt bussen skal erstatte er det ikke? Vedrørende 5GHz-buss, så er ikke det like klart om er mulig: http://www.aceshardware.com/forum?read=115112934 "We are exceeding 1GHz (in the transfer rate of FSB), but it is not possible to exceed so largely. 1.2GHz probably is possible, but what is made 5GHz thinks "that it is not possible, that Gelsinger says. 3)Hypertransport er ikke den mest avanserte buss teknologien der ute og den er langt fra den som øker frekvensen best. Alle dual-simplex link arkitekturene er mer avensert enn HT som er full-duplex. Disse dual-simplex standardene er blandt annet PCIe, FB-DIMM og Infiniband. PCIe opererer i dag på 2.5GT/s mot HTT sine 2GT/s og fremtidige 2.8GT/s. Infiniband opererer i dag på 2.8GT/s over avstander som er lengre enn HTX støtter. FB-DIMM er foreløpig ukjent men de skal støtte minst DDR2-800 på en 14bits (2 paritets bit) bred link. Det tilsvarer 4.2GT/s. Dette er link teknologien Intel antagelig ønsker å benytte i sin serial FSB og da ser du at ca 5GT/s (GHz) ikke er så usannsynlig. way beyond HTT Du glemmer at man kan ha flere HTT-linker og HTT-hoster i et system slik at den totale båndbredden overgår PCI-Express, FB-DIMM, Infiniband m.fl. En annen ting du ser bort ifra er pris, og HyperTransport er utvilsomt den beste bussteknologien sett utifra totale kostnader i et system. Det at den i tillegg er en åpen standard har gjort den til svært populær i industrien og brukes i tillegg til AMD64-systemer også i Apple-systemer, CISCO-rutere, etc. 4) Interessant hvordan tester blir irelevante med en gang Opteron ikke leder. Dette tror jeg er et av dine største kredibilitets problemer. I 2006 vil det ikke eksistere en enesete relevant test etter denne definisjonen. Nei, men etter å ha brent meg på Spec-tester tidligere har jeg lært å ikke ta dem særlig seriøst. Du derimot virker å ha klokketro på dem, og bruker dem for alt de er "verdt". Neppe særlig lurt etter min mening Lenke til kommentar
Knick Knack Skrevet 18. november 2004 Del Skrevet 18. november 2004 http://www.cbronline.com/article_news.asp?...60-C543E6ED354F Alpha ned 27% IPF opp 5% for HP snorreh: Jeg er ikke ensidig mot ODMC. Jeg har flere ganger uttalt at dette er en stor fordel for singel socket maskiner, men at en bør vente til serielt grensesnitt mot minnet er tilgjengelig i stor kvantum. For multi socket maskiner må en nesten opp på IBM Power MCM topologien for at det skal ha noe for seg, men det er igjen svært dyrt. Lenke til kommentar
Boralis Skrevet 18. november 2004 Del Skrevet 18. november 2004 Vel når det gjelder ensidighet , så vil jeg påstå at det er flere som er det ; Dog er det ikke alle som evner å se det . Lenke til kommentar
snorreh Skrevet 18. november 2004 Del Skrevet 18. november 2004 (endret) http://www.cbronline.com/article_news.asp?...60-C543E6ED354F Alpha ned 27% IPF opp 5% for HP Ikke overraskende når HP har stoppet videreutviklingen av Alpha-plattformen. Itanium øker faktisk med 11%, opp fra 5% i fjor av HP sine Business Critical Systems (BCS) salg: Fiorina said that HP's Integrity line of Itanium-based servers (which run HP-UX, Windows, Linux, and very soon OpenVMS) now account for 16% of total sales in the BCS unit, up from 5% a year ago. While that sounds great, what it means is that Itanium-based servers accounted for about $161 million of the $1.03 billion in BCS sales. This is a very small amount compared to the amount of revenue HP must be getting from the PA-RISC systems that the Integrities are intended to replace. Det betyr isåfall at salget av PA-RISC systemer er størst og har gått opp med 16% fra ifjor på bekostning av Alpha- og Itanium-salg. Dette beviser sånn sett min påstand om at kundene til HP fortsatt foretrekker PA-RISC fremfor Itanium, eller hva? Selv dette blir lite imponerende imot salget av Proliant-tjenere (Opteron og Xeon): The Enterprise Storage and Server unit posted sales of $4.1 billion in the quarter, up 7%, with shipments of x86-based ProLiant servers up 18% and revenue up 16%. snorreh: Jeg er ikke ensidig mot ODMC. Jeg har flere ganger uttalt at dette er en stor fordel for singel socket maskiner, men at en bør vente til serielt grensesnitt mot minnet er tilgjengelig i stor kvantum. For multi socket maskiner må en nesten opp på IBM Power MCM topologien for at det skal ha noe for seg, men det er igjen svært dyrt. Jada, men mener du å si at integrerte minnekontrollere ikke er nyttig i SMP? Isåfall er jeg ikke enig, det er jo nettopp her at det kommer til sin fulle rett (jf. Opteron vs. Xeon). Endret 18. november 2004 av snorreh Lenke til kommentar
Knick Knack Skrevet 19. november 2004 Del Skrevet 19. november 2004 Jada, men mener du å si at integrerte minnekontrollere ikke er nyttig i SMP? Isåfall er jeg ikke enig, det er jo nettopp her at det kommer til sin fulle rett (jf. Opteron vs. Xeon). Problemet er at du setter likhetstegn mellom delt buss topologi og ekstern minnekontroller. Det jeg sier er at stjerne topologi er bedre enn maske topologi og at masketopologi er bedre enn delt buss topologi. Videre impliserer maske topologi at en bruker ODMC og en kan derfor si at maske+ODMC er bedre enn delt buss + ekstern minnekonroller. Stjerne + ekstern minnekontroller er imidlertid bedre enn maske + ODMC. Nå skal en være forsiktig med å dra bastante slutninger kun basert på topologi. F.eks kommer twinvcastle til å være en slags stjerne topologi, men jeg tror ikke denne blir bedre enn maske systemene til AMD siden twincastle baserer seg på gammel link teknologi (parallell FSB). En må ha seriell FSB og helst fire stykker for at dette skal bli genialt, men da er det også så godt som perfekt. Et twincastle chipset med PCIe x32 og to grafikk kort i SLI vil imidlertid bli en kombinsjon jeg tror AMD skal slite hardt med å følge hvis Intel kommer opp med noen fornuftige Xeon prosessorer til dette chipsettet. Det er jo tydeligvis ingen selvfølgelighet. Lenke til kommentar
snorreh Skrevet 22. november 2004 Del Skrevet 22. november 2004 Problemet er at du setter likhetstegn mellom delt buss topologi og ekstern minnekontroller. Det jeg sier er at stjerne topologi er bedre enn maske topologi og at masketopologi er bedre enn delt buss topologi. Videre impliserer maske topologi at en bruker ODMC og en kan derfor si at maske+ODMC er bedre enn delt buss + ekstern minnekonroller. Stjerne + ekstern minnekontroller er imidlertid bedre enn maske + ODMC. Nå skal en være forsiktig med å dra bastante slutninger kun basert på topologi. F.eks kommer twinvcastle til å være en slags stjerne topologi, men jeg tror ikke denne blir bedre enn maske systemene til AMD siden twincastle baserer seg på gammel link teknologi (parallell FSB). En må ha seriell FSB og helst fire stykker for at dette skal bli genialt, men da er det også så godt som perfekt. Punkt-til-punkt busser er en suverent bedre løsning enn dagens delte buss som Intel benytter, uansett topologi. Integrerte minnekontrollere på prosessorene blir da eneste fornuftige løsningen for å redusere flaskehalser og redusere tilgangstiden til minnet for hver prosessor. Jeg anbefaler at du leser denne glimrende artikkelen: http://www.samag.com/documents/s=9408/sam0411b/0411b.htm Et twincastle chipset med PCIe x32 og to grafikk kort i SLI vil imidlertid bli en kombinsjon jeg tror AMD skal slite hardt med å følge hvis Intel kommer opp med noen fornuftige Xeon prosessorer til dette chipsettet. Det er jo tydeligvis ingen selvfølgelighet. Twincastle-brikkesettet vil også ha delte busser og bare utsette problemet enda lenger i beste fall. Selv har jeg mer tro på skalerbarheten til HyperTransport, en like rimelig og bra løsning skal du lete lenge etter Lenke til kommentar
Knick Knack Skrevet 2. desember 2004 Del Skrevet 2. desember 2004 (endret) Punkt-til-punkt busser er en suverent bedre løsning enn dagens delte buss som Intel benytter, uansett topologi. Det var vel akkurat det jeg sa. Integrerte minnekontrollere på prosessorene blir da eneste fornuftige løsningen for å redusere flaskehalser og redusere tilgangstiden til minnet for hver prosessor. Det finnes definitivt andre måter å ungå flaskehalser på samt redusere tilgangstidene. Stjerne topologi med minnekontrolleren i midten er bare ett eksempel der en oppnår akkurat dette uten bruk av integrert minnekontroller. Ikke det at å unngå bruk av integrert minnekontroller er et poeng i seg selv, men det finnes faktisk andre løsninger med andre fordeler og ulemper. Hva som er best avhenger i stor grad av applikasjonen. Til noe litt annet.. Informasjon om et nytt operativsystem som er skreddersydd til Itanium og utviklet av noen av de som kjenner arkitekturen best er kommet opp i lyset: Itanium inventor bobs to surface as chip's savior? "Secure64 is claiming that it will be virtually impossible to write worms or viruses that can attack the EAE, as it makes use of Itanium's rich security features. Third-parties can write applications to the EAE that make similar use of these security functions." Et system som er nærmest immunt mot virus og ormer, bygger utelukkende på ny teknologi høres svært fristende ut! Det er nesten så jeg tror sikkerheten i Itanium vil bli et viktigere trumfkort enn høy ytelse. Det er mange som tror Internett vil utvikle seg til en tilstand av relativt stort kaos. Da er slike maskiner intet mindre enn kjekt å ha. Effektiviteten til Secure64 vil antagelig også bli svært høy blandt annet fordi den er optimalisert for Itanium og kun for Itanium. Altså ikke masse rare tweaks for å støtte alskens tenkelige CPU arkitekturer. Med andre ord et OS som er like rendyrket som prosessoren det er ment å kjøre på. Dette høres nesten bedre ut enn IPF + Longhorn hvilket jeg antok skulle bli den første suksessen. Spørs bare om Secure64 kommer ut i rimelig tid. Det er nok snakk om et 2006-2008 perspektiv her, uten at jeg vet noe konkret. Det er også påstått noen helt ekstreme økninger i effektivitet og skalerbarhet. De virket litt merkelige, men var sannsynligvis tiltenkt Montecito eller helst Tukwila baserte systemer hvor OS vil spille en viktig rolle i utnyttelsen av systemet slik en også vil se for Niagara baserte systemer. En liten kurriositet er at artikkelen hos the register er skrevet av Ashlee Vance, som ikke akkurat er kjent for å være forelsket i IPF for å si det mildt. Enda en IPF-basher bites the dust? Begynner å bli tynnere i rekkene ettersom lyset går opp for dem: http://www.theregister.co.uk/2004/08/19/moto_hp_itanium/ Motorola's announcement is surprising mainly because the company's chief executive Ed Zander was ambivalent about Linux and a well-known Itanium-basher when he was president of Sun Microsystems two years ago. :!: Endret 2. desember 2004 av Knick Knack Lenke til kommentar
snorreh Skrevet 2. desember 2004 Del Skrevet 2. desember 2004 (endret) Integrerte minnekontrollere på prosessorene blir da eneste fornuftige løsningen for å redusere flaskehalser og redusere tilgangstiden til minnet for hver prosessor. Det finnes definitivt andre måter å ungå flaskehalser på samt redusere tilgangstidene. Stjerne topologi med minnekontrolleren i midten er bare ett eksempel der en oppnår akkurat dette uten bruk av integrert minnekontroller. Ikke det at å unngå bruk av integrert minnekontroller er et poeng i seg selv, men det finnes faktisk andre løsninger med andre fordeler og ulemper. Hva som er best avhenger i stor grad av applikasjonen. Ja, men det avhenger først og fremst av prisen også og de Itanium-brikkesettene du her skisserer er faktisk ekstremt kostbare. Vedrørende topologi, så er faktisk dette mulig med Opteron (gammel figur): http://www.digit-life.com/articles2/amd-ha...mily/index.html Skjønt med DDR400-minne og 1GHz HyperTransport-linker (8GB/s) idag Til noe litt annet.. Informasjon om et nytt operativsystem som er skreddersydd til Itanium og utviklet av noen av de som kjenner arkitekturen best er kommet opp i lyset: Itanium inventor bobs to surface as chip's savior? Ja, det virket interessant nok det men jeg frykter det blir et veldig smalt marked for Secure64 å konkurrere i: Again, companies like Sun and HP have been doing similar things with their versions of Unix. Secure64's biggest plus would be that it has tuned its software for Itanium only and thrown out any general purpose OS nonsense that would hamper web workload performance. That certainly makes it a unique player in the market, which is exactly what you want from a start-up. With its rich ties to HP, it's not hard to imagine Secure64 quickly appearing as an option for HP's Integrity server customers. This is a big "in" since HP accounts for about 85 percent of the Itanium ecosystem. The appliance idea never seems to take off as well as start-ups hope, and we have our doubts Secure64's play Jeg ville heller ikke gå så langt som å genierklære dem, dette er jo tross alt hjernene bak Merced Når det er sagt så er det også svært tvilsomt at HP kommer til å bytte ut HP-UX med det aller første, og SGI & Intel satser som kjent tungt på Linux fortsatt. En liten kurriositet er at artikkelen hos the register er skrevet av Ashlee Vance, som ikke akkurat er kjent for å være forelsket i IPF for å si det mildt. Enda en IPF-basher bites the dust? Begynner å bli tynnere i rekkene ettersom lyset går opp for dem: http://www.theregister.co.uk/2004/08/19/moto_hp_itanium/ Motorola's announcement is surprising mainly because the company's chief executive Ed Zander was ambivalent about Linux and a well-known Itanium-basher when he was president of Sun Microsystems two years ago. :!: Heller tvilsomt, det er jo i markedet for "mission-critical"-tjenere Itanium har funnet sin nisje nå og den inkluderer bl.a. bank- og teletjenester så dette bør ikke komme som noen overraskelse. Igjen så er dette et veldig smalt marked, og gir ikke de høye volumene som Intel hadde håpet på. Endret 2. desember 2004 av snorreh Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå