invariant
-
Innlegg
54 -
Ble med
-
Besøkte siden sist
Innholdstype
Profiler
Forum
Hendelser
Blogger
Om forumet
Innlegg skrevet av invariant
-
-
Fant dette på nettet et sted. Er det sant?
(en annen mulighet er jo å bruke openmp i Intel Fortran).
Invariant.
Improvements : Java vs C++
“Java is better than C++, more because of
what it does not have, than for what it has.”
– No global vars.
– Typos detected, not misinterpreted.
– No gotos.
– Disciplined uses abstracted (exceptions, labeled breaks).
– No pointers.
– Array-index out-of-bounds detected.
– In Java, pointers cannot be manipulated explicitly.
However, they serve as object handles.
– No explicit memory management.
– No memory leaks and no illegal access of freed storage.
– Improves readability.
Concurrent Programming
Threads can share address space. In Java,
threads are modeled after Hoare’s monitors.
• Java is a multi-threaded system, which is
very convenient for coding interactive,
multi-media applications.
– Doing I/O concurrently with reading a
document. (downloading via browser)
– Periodic updating of the screen with data
acquired in real-time. (sports/stocks ticker)
-
Joda, de jobber med saken med å innprente det. Problemet er at abstraksjonsnivået er såvidt høyt, selv om teorier og algoritmer både fra SMP-systemer og distribuerte systemer finnes er det tungt å forstå. Tror det er lenge før man klarer å utnytte potensialet i multikjerneprosessorer.
Selv er jeg vel bare ekspert i Fortran 77 (hvem er ikke det? :!: ), så derfor følgende spørsmål:
Stemmer det at Java har begrepene "concurrency" og "parallelism" som en del av språket? Vil det da være enklere å bruke Java enn C/C++ til slike ting? Eller skal vi lage en ny versjon av Fortran 77 som egner seg godt for "concurrency" og "parallelism"?
Invariant.
-
Må bare si meg enig i sitatene til el-asso, det er no herk å programmere multithreaded, det har jeg gjort en del på serversoftware, og der er det relativt "trivielt"..
Jeg kan tenkte meg hvor morsomt det er på en client som krever fullstendig synkronisering mellom threadene som i et dataspill, det blir vel årets spagettiopplevelse med dagens api'er.
Slutter meg til el-asso og balleklorin. Vi står overfor et lite paradigmeskifte i programmeringen - som ikke på noen måte vil gjøre det lettere for utviklerne. Når man skal begynne å kjøre samme program på 100 kjerner (i år 2015 ifølge Intel), så vil begrepet "årets spagettiopplevelse" være meget treffende. Vi får håpe det blir utdannet en ny generasjon utviklere som har "concurrency" og "parallelism" i blodet lenge før den tid.
Invariant.
-
Riktig. Etterhvert som en finner på stadig nye triks i ludo vil klokkefrekvensen få mindre og mindre betydning, men foreløpig er den jo en av de viktigeste faktorene.
Invariant.
-
Bra folk er engasjert. Nå vet vi jo ikke hvilken CPU som kommer i ViiV, men Yonah er kanskje en av kandidatene? For meg er det teknologien som er det morsomste, politikk osv. om hvem som skal selge hva til hvem osv. faller kanskje litt utenfor begrepet hardware? Teknologi er spennende uansett hvem som lanserer det - og konkurranse er lurt for det kommer jo alle brukere tilgode.
Invariant.
-
Personlig synes jeg ikke det er en eple og banan-sammenlikning, da yonah også ser ut til å kunne ble en grei desktop-CPU om prisen er rett). Og også intel har visstnok kommet med noen uttalelser som kan tyde på at de også til en viss grad vil satse på den til desktop-bruk(?). Men det stemmer jo at de testene jeg har sett ihvertfall er yonah vs desktop.
AtW
Tusen takk for oppklaringen. OK - da er jeg på nett. Så en sammenligner Yonah med desktop og ser at den er jo ikke så god, men ikke langt unna heller. Også havner nok Yonah i en del desktops også. Jeg forstår.
Da er jo ikke dette så gæli, for tidligere mobile platformer er jo ikke akkurat noen tallknusere heller, det er vi vel enige om, så da må Yonah anses for å være et lite evt. mellomstort steg i riktig retning, for Pentium D er jo en god regnemaskin vet jeg.
Invariant.
-
Jeg har sett et par slike benchmarks på nettet men synes det er rart at en ikke i større grad sammenligner Yonah mot andre mobile platformer. Er det noe jeg har gått glipp av her, eller stemmer det at en faktisk sammenligner epler og bananer?
Invariant.
-
-
Debatten om Yonah kan konkurere med X2 er egentlig irrelevant i forhold til den falske makredsføringa "mediaPC" er (måtte selvsagt lese gjennom testen til Antech)
Min konklusjon er at Intel ser at deres nye barn yonah ikke kan konkurere på high end med AMD, og derfor forsøker å lansere en "ny" plattform for å få salg for en ellers middelmådig cpu. Noe som sikkert ethvert firma ville gjort, for det er vel stort sett bare gamern som har behov for en ekstra kraften, dog skal det jo sies at i forhold til de andre cpu'er Intel har, så er jo Yonah et lite steg i riktig rettning.
Ja, selv om "Yonah" kanskje representerer det beste Intel har å by på for øyeblikket så er det likevel ingenting å skryte av. Ytelsen blir i beste fall middelmådig, prisen blir sikkert høy, og effektforbruket er minst 10W høyere sammenlignet med dagens Pentium-M. Konklusjonen min er at til tross for all hypen til Intel og en del media, så svarer "Yonah" på ingen måte til forventningene og kan derfor ikke karakteriseres som noe annet enn nok en flopp. Kanskje kommer Intel sterkere tilbake med "Merom" & co, men for å være ærlig så har jeg liten tro på at det kommer til å skje. Kanskje i 2008 hvis AMD & co. sover i timen? Vel, det gjenstår å se...
Etterhvert som folk får øynene opp, så vil nok også merkenavnet Intel Viiv technology bli synonymt med DRM som er alt annet enn gode nyheter for folk flest.
Dette minner, som tidligere, mer om polemikk enn om saklig argumentasjon.
Her kommer en lang rekke påstander som ikke begrunnes.
Jeg for min del synes det er flott med Yonah - for da må AMD skjerpe seg.
Det går jo i riktig retning 90 nm -> 65 nm ->32 nm -> 22 nm osv. og det blir jo artig å se hva som skjer etterhvert som teknologien stadig blir mer avansert. Foruten en lang rekke nye instruksjons-sett i årene som kommer vil en sikkert også se at antall kjerner og også cache size øker dramatisk. Og her er jo Yonah første skritt i riktig retning med 2 kjerner og 2 Mb cache som deles mellom kjernene.
Invariant.
-
Obs. bildet ble litt stort.
Invariant.
-
Hei alle sammen,
Siden AMD-tilhengerne er litt i overkant for øyeblikket, bidrar jeg med et bilde fra Intel sin Yonah presentasjon (under). Jo, Yonah er 30% bedre på SSE-ting, det er noe fundamentalt nytt på gang her - helt ny hardware som ingen har sett maken til før. Dette betyr at den er mye bedre på vektor-matte, video og spill en tidligere mobile platformer.
Invariant.
http://www.edn.com/media/IDFFall2005/Yonah...lMediaBoost.JPG (1280x800, 120kB)
Moderatoredit: Bildet er omgjort til link siden det ødela layouten på siden for mange lesere.
-
Hei!
Har du noen gang prøvd å kjøre et program med SSE2-kode på en PC uten SSE2? Da får du en stygg feilmelding "Priviliged Instruction". Derfor har Intel satt inn feilmeldingen "Fatal Error: This program was not built to run on the processor in your system" isteden basert på en CPUID-sjekk. Dersom du ikke liker dette, så kan du kompilere hovedprogrammet med -xW og lage din egen CPUID sjekk, basert på et lite program hos Microsoft: http://msdn2.microsoft.com/en-us/library/xs6aek1h.aspx, klikk på download sample. Nå er det ikke bare SSE, SSE2 og SS3 som varierer fra CPU til CPU, men også bl.a. Hyper-Threading. Så det er gode grunner for å ha en CPUID-sjekk, enten en fra kompilatoren, eller en du lager selv, for at du skal kunne bruke de seneste instruksjons-settene og samtidig gi hyggelige feilmeldinger til brukere dersom arkitekturen deres ikke støtter softwaren din.
Softwaren din er sikkert for vel-implementert til at PGO skal ha noen dramatisk effekt, men det kan lønne seg å leke seg litt med dette for å finne ut hva den eventuelle nytte-effekten kan være. Store programmer, med flere millioner kode-linjer, hvor mange har vært inne å kodet, og f.eks. en likningsløser bare er en liten del av det hele, kan være bedre egnet for PGO optimering. Men det kan også hende at det ikke har noen effekt. Det varierer fra case til case.
Invariant.
-
Nice try, problemet er selvfølgelig at mange på forumet ikke skjønner at du fleiper.
Opps, du gjennomskuet meg.
Men, likevel går det nok litt i den retningen, om noen år får vi knøttsmå SSE4 evt. SSE5 bærbare som får dagens servere og arbeidstasjoner til å se litt ynkelige ut. Faktisk er jo hele dette SSE oppstyret utviklet med tanke på multimedia applikasjoner, som musikk og video, at det samme instruksjons-settet også er svært velegnet for FP er nærmest en utilsiktet side-effect...En oppdtaert link om Viiv finner vi her:
http://www.intel.com/pressroom/archive/rel...0051130corp.htm
Invariant.
-
Viiv-plattformen ser ut til å bli lansert på i januar på CES-messen i Las Vegas og vil være leveringsklar samme kvartal.
Viiv blir mest sannsynlig også en tallknuser - effektive multimedia instruksjoner kan som kjent også brukes til annet enn å dekode mpeg film: snart kan du bytte ut din litt voldsomme AMD Opteron 254 med en søt liten Viiv.
Invariant.
-
Hei Del,
Hvis du leser min utskrift fra dokumentasjonen så har Intel lagt inn en test i hovedprogrammet (main module) slik at en unngår å kjøre på prosessorer som ikke støtter instruksjonsettet i executablen. For AMD slår denne testen av og til litt uheldig ut, og en må passe på å bruke /QxW evt -xW her, antatt at en vet hva en gjør, dvs. pass på SSE2 og SSE3 som vanlig.
De fleste velger å hoppe rett fra x87 til SSE2. Grunnen er at SSE var et litt uferdig instruksjons-sett siden det ikke støttet double precision. Så når du spør om det samme gjelder for SSE, så vet jeg ikke svaret, har aldri brukt SSE. SSE faller litt mellom to stoler, enten bruker man x87 eller så bruker man SSE2, for mange applikasjoner er jo x87 tilstrekkelig, hvis ikke hopp rett til SSE2.
Hvis det er noen mer du lurer på, er du fri til å presisere gamle evt. komme med nye spørsmål.
Invariant.
-
Invariant, du la subrutinen utenfor hovedprogrammet, er dette nødvendig for å få SSE2 støtte? Hadde vært fint om du kunne forklart hvorfor hvilke begrensinger hvis noen, som ligger i å ha koden i hovedprogrammet. Virker som om du allerede vet svaret, og det vil spare meg for masse testing.
JA. Ikke bare utenfor hovedprogrammet, men i en egen fil er nødvendig. Det går ikke an å ha forskjellige kompilator-opsjoner for rutiner i samme fil.
Dernest, er det slik at uten både -xW på hovedprogram og -xN på subrutine, så kan man ikke regne med å få full SSE2 støtte på AMD prosessorer, gjelder tilsvarende for SSE?
Vil generelt ikke anbefale float (SSE) dersom man holder på med FP, for stor avrundingsfeil.
Er knepet ditt godt forklart i dokumentasjonen til IFC/ICC (igjen virker det som om du allerede vet svaret, så det vil spare meg en god del tid)?
JA. Fra dokumentasjonen (http://cache-www.intel.com/cd/00/00/21/92/...ptimization.pdf):
In the Intel Compilers version 8.x and above, the
/Qx{N, B, P} (-x{N, B, P} on Linux) options generate
an error message if the application is run on an
incompatible processor:
“Fatal Error: This program was not built to
run on the processor in your system.”
For this check to be effective, ensure that the main
program or the main module of a dynamic library is
compiled with the options.
Sukk.
Hadde bare noen tatt seg tid til å lese Intel sine dokumentasjon isteden for å lese web-sider skrevet av Intel sine "fiender".
Flott invariant link du hadde. Helt enig med det som sto der.
Invariant.
-
So, this is a partial fix, but Intel's CPUID check will still hurt performance on AMD chips.
Mark.
Hello Mark,
I cannot see that this is true. Files compiled with -xN when linked with main program compiled with -xW, have full SSE2 versions of the SVML functions.
Best Regards,
Invariant
-
Jeg stusset litt på det, men en blings på et funksjonskall betyr ikke all verden, det er uansett fullt mulig å sjekke om det virkelig er lagt inn snubletråd på exp().
Vet ikke helt hvilken konklusjon jeg hadde som du er uenig i?
Bare for å være på den sikre siden, spør jeg en gang til: var det et AMD system du brukte?
Hei Del.
Det er ikke noen snubletråd i exp(), _vmldExp2 heller. Sjekket det akkurat.
Jeg forstår at du prøver å være nøytral, men siden jeg er tester ting selv, og ikke bare tar obskure linker på nettet for god fisk, burde du ikke tillegge "synserne" like stor vekt synes jeg. På vektskålen bør en faktisk test veie mye tyngre enn noe man har lest, jeg er uenig i at du tilegger "synserne" så stor vekt i utsagnet " bias er rimelig jevnt fordelt". Klart jeg har bias, men ikke på dette punktet.
Ja. Koden er kompilert på Intel og kjører så det hviner på AMD.
Invariant.
-
Grunnen til at jeg ikke har med exp() er at a**b ikke er exp() men derimot pow(). Så her har Mark feilet.
La oss anta at jeg isteden hadde skrevet a=exp(b). Da ville vi fått et kall til _vmldExp2. Et slikt kall vil også innebære kun SSE2 double precision (64 bit) calculations. Tror ikke jeg legger ved .asm koden for den også (veldig mange linjer).
Nei jeg er uenig i konklusjonen din Del. Med min metode blir det ikke lagt ut noen snubletråder for AMD.
Invariant.
-
i.e. mysub() is compiled to use SSE2 instructions, but it uses the exp() function. The Intel Math Library linked into your code checks the CPUID and calls VmlsExp4.W (the SSE2 routine) on Intel chips, and VmlsExp4.I (a non-vectorised exponential routine) on AMD chips.
Mark er jo litt unøyaktig i sine antagelser. Har han Intel kompilator? To feil i utsagnet over.
1. Det er ikke kall til exp(), men et kall til pow().
2. Det er ikke single presisjon slik han indikerer "VmlsExp4.W", s her betyr float = 32 bit. Det er double precision = 64 bit.
Så det er ikke VmlsExp4.W som kalles her men derimot vmldPow2.
Forskjellen er at VmlsExp4.W regner ut exp() til 4 float i parallell, mens vmldPow2 regner ut pow() til 2 double i parallell.
Invariant.
-
1) Code build with this flag will segfault on a PIII or an Athlon Thunderbird or any earlier CPU, so those flags are useless for code which you're going to distribute
Mark.
Sant nok, men dette er en overmåte konservativ approach. Hvorfor ikke lage kode som er bakoverkompatibel helt til Intel 4004 som kom 3 Qtr, 1971? Hvor skal man sette grensen? Vi har som sagt to versjoner, en med SSE2 og en uten. Den uten har ikke vært forespurt siden 2004.
Er andre kompilatorer noe bedre her? Lager man SSE2, med en hvilken som helst kompilator, så går den jo ikke på en PC uten SSE2.
2) Although the code that you compile is forced to use SSE2, if you use any vectorised math functions then these still have the CPUID check
Dump av mycode.obj ser (bl.a.) slik ut:
0000003E: movapd xmm0,xmmword ptr .bss[esi]
00000046: movapd xmm1,xmmword ptr .bss[esi+20h]
0000004E: call _vmldPow2
00000053: movapd xmmword ptr .bss[esi+40h],xmm0
Hvor en kaller _vmldPow2. Alle de variantene jeg fant av _vmldPow2 i biblioteket inneholder kun gode effektive SSE2 instruksjoner. Jeg tror Mark har blandet sammen SSE med SSE2 på dette punktet.
Under er dump av _vmldPow2 variantene (tok dette bort, det var jo så mange linjer og de fleste har vel fått dette med seg). Bare flotte effektive SSE2-instruksjoner.
Invariant.
-
Hei Del!
Det jeg skrev var:
Dersom en kompilerer hovedprogrammet med /QxW, så kjører koden fint på alle platformer.
Dette er ingen overdrivelse, for Intel leverer nøyaktig samme kompilator til Win32, Win-64, Linux-32 og Linux-64.
Det som er kjekt da er at man å utvikle kode i Microsoft sitt brukervennlige debugger-miljø (her er vel ingen lika bra!) på Windows, for deretter å rekompilere koden med nøyaktig samme Makefile, opsjoner osv. på de 4 over nevnte platformer. Bedre invarians er ikke mulig slik jeg ser det (bortsett fra Java da). Og, jo, alle Intel kompilatorer og kompilatoropsjoner osv. helt identiske på de ulike platformene, vi har til å med sett at .asm koden til resulterende executable blir den samme.
Invariant.
-
Siden dette går på Ace's også:
http://www.aceshardware.com/forums/read_po...47329&forumid=1
"Just use the 64bit icc. It doesn't generate any CPUID checks for SSE2
because SSE2 is standard on 64bit. It might for SSE3. SSE3 is
relatively obscure though and not that important." Av ingen ringere enn Andi Kleen.
Riktig. Kleen har helt rett:
Just use the 64bit icc. It doesn't generate any CPUID checks for SSE2
because SSE2 is standard on 64bit. It might for SSE3. SSE3 is
relatively obscure though and not that important.
SSE3 er klart obskurt med mindre man holder mye på med komplekse tall ol.
Dermed kan vi unngå testen både på Windows (min workaround) og på Linux-64 (ingen test).
Invariant.
-
De har altså to "code paths" eller hva det nå enn heter. En optimalisert og en som er garantert å kjøre på "alt" av hardware. Basert på CPUID sjekken så velges en av de to.
Hei.
Fint at du nevner dette, for på dette punktet er dokumentasjonen noe uklar.
Her er en oppklaring.
Man kan enten lage kode bare for SSE2 (som eksempel), eller kode for SSE2 som også kjører uten SSE2, dvs. to "code paths". Sistnevnte har jeg sett at gir en god del tregere kode, og i overgangsperioden mellom x87 og SSE2 (perioden 2000 - 2004), valgte vi derfor isteden å selge to versjoner av koden, en med SSE2 og en uten.
Altså har vi (f.eks.) opsjonene:
/QaxN - lager kode for SSE2 men kjører også andre steder: to "code paths".
/QxN - Lager kode bare for SSE2.
Så, er du sikker på at hardwaren din støtter SSE2, så bør du ligge unne opsjonene /QaxW, /QaxN,/QaxP osv. bruk heller /QxW, /QxN,/QxP. OBS: siste opsjon /QxP krever SSE3, men det er jo også vanlig på de nyeste AMD Opteron etterhvert. Ellers bør man ligge unna opsjonen /fast for det er aldri godt å vite hva den inneholder, f.eks. innebærer den bl.a. /QxP nå, og det er ikke så mange platformer med SSE3 foreløpig.
Dermed kan man trygt bruke /QxN (SSE2 en "code path") og /QxP (SSE3 en "code path") på AMD-64, så lenge hovedprogrammet (PROGRAM,main) kompileres med /QxW.
Typisk bra code får en vet å bruke /O2 (evt. /O3) og /Qip (evt. /Qipo) sammen med /QxN (SSE2) eller /QxP (SSE3).
Invariant.
Quad-kjerne, AMD eller Intel?
i Diskuter dataartikler (Tek.no)
Skrevet
Tusen takk for nyttig svar Ola. Tenkt meg nok det ja. Kan opplyse om at Fortran egner seg utmerket til tallknusing, og med litt tankearbeid kan vi sikkert bruke openmp på en lur måte for å bruke mange kjerner. Men lett er det ikke.
Invariant.