HKS Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 FP ytelsen blir nok langt bedre enn i Dothan, men jeg tviler på at det blir mye å juble over i HPC sammenheng. Jeg tror ikke det plager Intel veldig sterkt, de ser ikke ut til å satse på x86 i dette markedet. Intel har jo hatt stor suksess med xeon på klynge for HPC, har Intel planer om å skalere ned satsingen der? I HPC merkedet er det Itanium 2 eller Opteron som gjelder nå... Lenke til kommentar
Del Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 Raptor' date='29/07/2005 : 09:10'] I HPC merkedet er det Itanium 2 eller Opteron som gjelder nå... Bør nesten føye IBMs Power til listen også. Dersom Opterons dualkjerne allerede har utkonkurrert Xeon i HPC markedet er dette meget store nyheter, har du noe informasjon om det? Lenke til kommentar
snorreh Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 (endret) "Sossaman" vil muligens finne sin nisje i enkelte bladtjenere, men ellers er det mye å utsette på den ifølge dette: Does Intel's Sossaman make any sense? Since Yonah is going to launch in February, that brings up a big question about Sossaman, the DP Xeon version. The real question is not when, but why bother? First a little background, Yonah will be out in Q1, so Sossaman will most likely trail it by a few weeks. This is a 31W dual core PM based chip that should be fairly strong in Int, but weaker in FP. The biggest drawback is that it only supports 32-bit x86, no iAMD64 for you. The chip's replacement, the all new Merom will be out in Q3, or about six months later, and Woodcrest the DP Xeon will be out a little while after that. So, you have six months from Sossaman launch until it is surpassed in every way by Woodcrest. Is it really worth the infrastructure cost and tooling to make servers and blades with a half year expected lifespan? Altså vil den ha svak flytetallsytelse som er viktig for mange tjenerapplikasjoner, ingen 64-bit støtte dvs. maks 3GB RAM (les: begrenset bruksområde), kun 667FSB som effektivt bare er 333FSB fordelt på begge kjernene (les: flaskehals ytelsesmessig), og prosessoren vil altså bare eksistere i ca. 6 måneder før den blir faset ut (les: lite fremtidsrettet). Nok et halvfabrikat fra Intel? Endret 29. juli 2005 av snorreh Lenke til kommentar
Del Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 Har sett påstander begge veier om hvorvidt den vil støtte 64-bit, så jeg avventer den litt, men uttalelsene om fp ytelse er meget interessante, det er i grunnen her jeg kunne tenkt meg litt mer info, synes det er veldig merkelig hvis Intel overlater x86 HPC markedet til AMD. Lenke til kommentar
HKS Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 Raptor,29/07/2005 : 09:10] I HPC merkedet er det Itanium 2 eller Opteron som gjelder nå... Bør nesten føye IBMs Power til listen også. Dersom Opterons dualkjerne allerede har utkonkurrert Xeon i HPC markedet er dette meget store nyheter, har du noe informasjon om det? Ja, har stående et par PowerPC maskiner på lab'en... De som kjøper interconnect produkter fra oss til ny hardware bruker den ofte på AMD hardware... Da snakker jeg ikke om clustere som går inn i top 100 listen Lenke til kommentar
snorreh Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 (endret) Har sett påstander begge veier om hvorvidt den vil støtte 64-bit, så jeg avventer den litt, men uttalelsene om fp ytelse er meget interessante, det er i grunnen her jeg kunne tenkt meg litt mer info, synes det er veldig merkelig hvis Intel overlater x86 HPC markedet til AMD. Ettersom "Sossaman" er basert på "Yonah" så vil den ikke få 64-bit støtte: http://www.dvhardware.net/article5188.html A thing which Yonah won't feature is 64-bit, because it would mean a big difference in battery life. Og når det gjelder flytetallsytelsen så gir disse testene kanskje en liten pekepinn på hva man kan forvente seg: http://www.gamepc.com/labs/view_content.as...70ct479&page=12 http://techreport.com/reviews/2005q1/dfi-8...f/index.x?pg=16 http://www.anandtech.com/cpuchipsets/showd...spx?i=2342&p=16 http://www.aceshardware.com/SPECmine/index...mt=2800&o=0&o=1 Endret 29. juli 2005 av snorreh Lenke til kommentar
Simen1 Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 ingen 64-bit støtte dvs. maks 3GB RAM (les: begrenset bruksområde) Vel, det der tar jeg med en klype salt. Begrensningen på 3GiB gjelder kun Windows XP/2003 som automatisk setter av 1GB til seg selv av begrensningen på 4GiB slik at programmene har adgang til mask 3GiB. Denne 1GiB kan konfigureres ned, eller fjernes helt ved bruk at et annet OS. (i Win 2000 er denne grensa default 2GiB, i Linux er det ikke noe skille) Jeg synes dermed det er riktigere å si at begrensningen er 4GiB siden mange HPC clustere kjører en form for *NIX. Men begrensningen på 4GiB er ikke bastant den heller. Selv en PentiumIII Xeon kan utstyres med opp til 64GiB ram via 36bit adressering. Dette vil riktignok gi et innhugg i ytelsen siden OS'et må bytte mellom forskjellige 4GiB-partisjoner av ram'en, men muligheten er i hvertfall der. Ytelsen mellom program og en av disse ram-partisjonene er helt på høyde med vanlig minneytelse, det er først når man må bytte partisjon ofte det vil gå tregt. Så jeg synes det blir litt feil å si bastant at det blir maks 3GiB. Lenke til kommentar
snorreh Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 (endret) Uten bruk av fryktelige PAE (Physical Address Extensions) så er faktisk 3GB maks minne også i Linux: http://www.spack.org/wiki/LinuxRamLimits PAE does not increase Linux's ability for *single* processes to see greater then 3GB of RAM (see below).[...] Without PAE compiled into the kernel the OS can address a maximum of 4GB of RAM. [...] The 4 GB limit is really less, depending on your hardware and BIOS. Your BIOS will create a memory hole below 4 GB large enough for all your PCI devices. This hole might be 1 or 2 GB. Minst 1GB er altså reservert av BIOS/kjernen til PCI-enheter o.l. Denne 3GB maks-grensen gjelder forøvrig både fysisk og virtuelt minne, bare så det er helt klart. Med 64-bits CPU og OS så har man derimot ikke slike begresninger, og selv med bare litt fysisk minne så kan man likevel bruke maks virtuelt minne til ethvert 32-bits program når man trenger det. Faktisk så kan ethvert 32-bits program i Windows XP x64 bruke opptil 4GB dedisert minne, mens alt minnet på Windows XP 32-bit blir delt mellom kjernen og programmene slik at man i beste fall får 3GB minne tilgjengelig (uten PAE). Muligheten for å kunne bruke mer enn 3GB fysisk/virtuelt minne er altså nyttig, spesielt når man arbeider med store datamengder, og det er altså umulig med "Yonah/Sossaman" siden disse ikke støtter 64-bit. Endret 29. juli 2005 av snorreh Lenke til kommentar
Del Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 Raptor' date='29/07/2005 : 11:37'] Ja, har stående et par PowerPC maskiner på lab'en... De som kjøper interconnect produkter fra oss til ny hardware bruker den ofte på AMD hardware... Da snakker jeg ikke om clustere som går inn i top 100 listen Jeg skjønner godt hvis du ikke føler deg komfortabel med å gi flere detaljer, men det hadde vært veldig fint å få informasjon din i et perspektiv. Hvis vi snakker om Norge er vel oljebransjen største kunde, og der vet vi at Dell er stor leverandør (hvilket pt. ikke er forenelig med Opteron). @snorre: Takker for linker! Tallenes tale var rimelig knusende, men P.M har jo glimrende overklokkingsresultater, så jeg lurer jo litt på hvilke frekvenser de vil legge seg på for stasjonære maskiner. Skulle gjerne sett Intel utalt seg om hvorvidt de vil utstyre Sossaman med 64-bit utvidelse eller ikke. Så jeg synes det blir litt feil å si bastant at det blir maks 3GiB. Sant nok, selv om det ikke er noen stor sak. På klynge er det uansett 2 CPU'er pr. node, og utsyrt med 4GB pr. node er det ikke meningen å kjøre mange jobber over 2GB pr. CPU. Klynger bruker naturligvis linux, og ergo full tilgang til RAM. Minne er dog dyrt, så for meg virker det ikke hensiktsmessig å bygge klynger med mer enn 4GB pr. node over hele fjøla. Spesielt minnekrevende jobber kan man bruke arbeidsstasjoner eller utvalgte opp-spec'ede noder til, evt. shared memory maskiner om man har økonomi til å ha sånt, men da begynner vi å snakke om et ganske smalt marked her til lands. Lenke til kommentar
snorreh Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 (endret) @snorre: Takker for linker! Tallenes tale var rimelig knusende, men P.M har jo glimrende overklokkingsresultater, så jeg lurer jo litt på hvilke frekvenser de vil legge seg på for stasjonære maskiner. Skulle gjerne sett Intel utalt seg om hvorvidt de vil utstyre Sossaman med 64-bit utvidelse eller ikke. Se her: http://vr-zone.com/?i=2470&s=1 when Yonah is launched in H1 2006, the initial clock speeds and model numbers are expected to be x20 (1.67GHz), x30 (1.83GHz), x40 (2.0GHz) as well as x50 (2.17GHz). There are low voltage versions of Yonah as well; x48 (1.67GHz) and x38 (1.50GHz) Som det fremkommer fra dette bildet hentet fra samme artikkel så har ikke "Yonah" støtte for 64-bit (x86-64), bare MMX, SSE, SSE2 og SSE3: Endret 29. juli 2005 av snorreh Lenke til kommentar
el_salvad Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 (endret) ... Endret 29. juli 2005 av el_salvad Lenke til kommentar
Simen1 Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 (endret) Det er ikke noen stor sak nei, men jeg synes det skal nevnes at muligheten finnes og at de 3 eller 4GiB ikke er helt bastante grenser. Et program kan gjerne aksessere mer enn 4GiB av gangen også, det må bare være delt opp i moduler som tar en ting av gangen. Hvis det skulle være behov for det på en HPC så kan det fint programmeres inn. Det har som sagt noen ytelsemessige konsekvenser, og økonomiske som Del sier, men det er altså teoretisk mulig å bruke opp til 64GiB med Dothan. (Og forsåvidt AMD K7-serien(?), K8-serien, PentiumIII Xeon-serien, Banias-serien, CeleronM, og alle Pentium4-kjerner for den saks skyld) Her er et par linker angående PAE36: http://www.computerbase.de/news/hardware/p..._herbst_winter/ http://www.computerbase.de/lexikon/PAE Og oversettelse for de som ikke er stødig i tysk. Og en link på engelsk: http://forums.ocmodshop.com/pr.aspx?f=4&m=12939 Selv K8 støtter PAE36, selv om det gir lite mening å bruke denne modusen på K8. Angående OS så støtter Linux kjerer 2.4.4 og oppover denne modusen, samt Windows 2000 Advanced datacentre. (sikkert flere også, som jeg ikke har fått sjekket ut) Edit: Her påstår de faktisk at PAE36 har vært med på lasset helt siden Pentium Pro (1995): http://bellota.ele.uva.es/~jesman/BigSeti/ftp/MPR/120901.pdf Endret 29. juli 2005 av Simen1 Lenke til kommentar
snorreh Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 (endret) Det er ikke noen stor sak nei, men jeg synes det skal nevnes at muligheten finnes og at de 3 eller 4GiB ikke er helt bastante grenser. Et program kan gjerne aksessere mer enn 4GiB av gangen også, det må bare være delt opp i moduler som tar en ting av gangen. Hvis det skulle være behov for det på en HPC så kan det fint programmeres inn. Det har som sagt noen ytelsemessige konsekvenser PAE er noe salig rot og er faktisk en ganske stor sak å programmeres inn støtte for, og er også etter Linus Torvalds og mange andre et meget stygt hack: http://www.ussg.iu.edu/hypermail/linux/ker...302.2/1909.html The only real major failure of the x86 is the PAE crud. Let's hope we'll get to forget it, the same way the DOS people eventually forgot about their memory extenders. 64-bit er utvilsomt den beste løsningen for å støtte mer minne, så la oss slippe mer PAE-tull Endret 29. juli 2005 av snorreh Lenke til kommentar
Simen1 Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 Jeg er helt enig på at PAE36 er noe herk og tull, og at AMD64 er en totalt overlegen teknikk. Jeg ville bare at du skulle være litt mindre bastant i påstanden om at 3GiB var maksimalt. Lenke til kommentar
snorreh Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 (endret) Jeg er helt enig på at PAE36 er noe herk og tull, og at AMD64 er en totalt overlegen teknikk. Jeg ville bare at du skulle være litt mindre bastant i påstanden om at 3GiB var maksimalt. Joda, men i praksis så er maks-grensen 3GB. Svært få programmer støtter PAE i dag siden det gir elendig ytelse, og PAE var også en av hovedårsakene til at AMD64 ble så populært nesten over natten. Nå som 64-bit allerede er standard i tjener-markedet så virker det rimelig idiotisk å gi ut en 32-bits tjener-prosessor som "Sossaman" til neste år, så det må være lov å spørre seg om hva Intel roter med for tiden? Endret 29. juli 2005 av snorreh Lenke til kommentar
Simen1 Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 Takk Nå ble det litt mindre bastant Lenke til kommentar
Del Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 @Snorre: Fatter ikke hvordan du til enhver tid finner alle linkene, men du har langt på vei overbevist meg både når det gjelder frekvens, fp-ytelse og 32-bit. Hvis alt dette stemmer tror jeg Dell får en svett periode fremover. Lenke til kommentar
el_salvad Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 X86-secret.com Il supportera également l'EM64T ("36 bit memory addressing"), l'EIST (Gayserville 3), le multi-threading (CPU BI-Core oblige) et le "FSB address and data parity", un système de contrôle d'erreurs sur le bus de donnée. Noe som betyr oversatt til engelsk; It will also support the EM64T ("36 bit memory addressing"), the EIST (Gayserville 3), multi-threading (CPU Bi-Core obliges) and the "FSB address and dated parity", a system of control of errors on the data bus. Ettersom jeg ser dette, tror vil den støtte 64-bit. Og så kan jeg ikke tro at Intel vil komme med en Xeon uten 64-bit nå. Lenke til kommentar
Del Skrevet 29. juli 2005 Del Skrevet 29. juli 2005 X86-secret.com It will also support the EM64T ("36 bit memory addressing"), the EIST (Gayserville 3), multi-threading (CPU Bi-Core obliges) and the "FSB address and dated parity", a system of control of errors on the data bus. Ettersom jeg ser dette, tror vil den støtte 64-bit. Og så kan jeg ikke tro at Intel vil komme med en Xeon uten 64-bit nå. Ja, det var i grunnen den kilden jeg siktet til da jeg mente det ikke var klart ennå, jeg har ikke sett noen andre uttale det samme. Ellers er jeg enig med deg, det virker ubegripelig at de ikke skal legge inn utvidelsen. Selv om dette i praksis ikke betyr all verden for en klynge, vil det nok likevel bety mye for de som sitter og bestemmer innkjøp. På servere eller arbeidsstasjoner med stort minnebehov er det spikeren i kista. 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å