Optimaliserer Java for Shanghai

[int20h]

AMD jobber sammen med Sun, Oracle og IBM for å maksimere Java-ytelsen på den ferskeste Opteron-arkitekturen.

 

Les mer

[Anders Jensen]

De kan optimalisere så mye de vil for Shanghai. Nehalem kommer til å ta den kaka fullstendig uansett. Dessverre..

[HKS]

Dessuten vil minst 90% av disse optimaliseringene også gjøre at Nehalem får bedre ytelse. Instruksjonssettet er nesten identisk.

 

Tror nok ikke dette får så mye å si, etter å ha sett tall på Nehalem i server-miljø så må jeg nok si meg helt enig i det Anders Jensen sier... Nehalem kommer nok til å ta den kaka fullstendig... Dessverre...

[DarkSlayer]

som om java-miljøet bryr seg...

 

Om jobben må deles opp i tråder og prosesser, så lager man antagelig en sak som går på flere maskiner og kan skalere. Noen % her og der ... det er kun nisjebedrifter/løsninger som bryr seg om.

 

Optimalisering av kode i kompilatorer er noe som pågår konstant, og nye teknikker oppdages og implementeres hele tiden.

Java er en 2stegs løsning, der man først kompilerer til bytekode, og så kjører den i en jit compiler. Er ikke så lenge siden jeg leste at kompileringen til bytekode inneholdt mye optimizering, men når JIT motoren kjører så genererer den sourcen på nytt fra bytecode, for så å kjøre en egen optimisering... øh ... forstå seg den som kan.

 

Men java går da fort nok. Raskere enn php

 

Men som sagt. Hardware er billig, og det er ganske mange faktorer som spiller inn ved kjøp av servere. At java utnytter det ene 2% mer enn den andre er peanøtter på godt norsk. På en annen side, det er ikke så mange som har såpass stålkontroll på java at de tenker i slike baner.

 

pr stunt fra et skip som synker.

[idos]

PR stunt eller ikke.. jeg får håpe de lykkes. Uten AMD kan intel melke verden som MS har gjort..

[Imsochobo]

Hvorfor er folk negative til optimaliseringer ?, dagens software er skrap iforhold til hva det var.

 

Vi har mildt sagt for mye kraft for at devs skal gidde å gjøre jobben riktig.

 

la oss for eksempel tenke.

 

Metode A = 60 sec på en jobb men å lage software'n tar 2 mndr.

 

Metode B = 80 sec på en jobb men å lage software'n tar 2mndr.

 

 

Hva velger de? metode B.

 

Bare ett eksempel, men sånn det er.

[jorgis]

Metode A = 60 sec på en jobb men å lage software'n tar 2 mndr.

 

Metode B = 80 sec på en jobb men å lage software'n tar 2mndr.

 

 

Hva velger de? metode B.

 

Med lik utviklingstid velger en seff metoden som tar kortest tid. Eller var det kanskje omvendt du mente?

 

At du sier at dagens programvare er "skrap" i forhold til hva det var, så kan det vel kanskje ha noe å si med kompleksiteten i dagens løsninger? OpenOffice har i dag over dobbelt så mange linjer kildekode som hele Windows NT 3.1 hadde. Siste Debian (4.0) er nå på over 283 millioner linjer kildekode. Når så omfattende løsninger skal skrives og vedlikeholdes er det jo klart at en prioriterer en løsning som yter marginalt dårligere om det gir kortere utviklingstid. Det er ikke uten grunn at tolkede språk som Python og Ruby har slått så godt an i nyere tid.

[Del]

De kan optimalisere så mye de vil for Shanghai. Nehalem kommer til å ta den kaka fullstendig uansett. Dessverre..

AMD ser ut til å ha ihvertfall et halvår med den beste serverløsningen over hele linja. I et fungerende marked ville det vært tilstrekkelig. For de som skal handle nå er det greit å vite at Java vil fungere enda bedre på Shanghai om en stund.

 

Når vi først er inne på java, har du sett denne:

http://www.phoronix.com/scan.php?page=arti...mance&num=1

[DarkSlayer]

Hvorfor er folk negative til optimaliseringer ?, dagens software er skrap iforhold til hva det var.

Du er ikke en programmerer ser jeg - jeg er. php, java, c++, etc etc etc.

 

Før i tiden så var det lett å lage kodesnutter som slukte mye maskinkraft. De hadde dårlige muligheter for tråder, eller spre oppgaver over clustere. Idag så har man helt rått med kraft og minne sammenlignet.

 

Ta et eksempel med å lage et gui. Java swing eksempler er lett å se på.

http://java.sun.com/docs/books/tutorial/ui...out/border.html

Her lager man et vindu, legger på en layout manager, en knapp i hvert område, så litt kode for å starte og kjøre greia. Dritenkelt.

 

Men bak all denne koden, så ligger det kode og passer på størrelse, plassering, resizing, tar i mot systembeskjeder etc etc etc. Hele miljøet bak dette er formidabelt. Det er faktisk 1000 ting dette systemet bare gjør for deg. I gamle dager måtte du gjøre ALT manuelt. Vi snakker 100vis av dager. Dette er laget på 30min om man er litt sløv.

 

Dette gjør at det å lage kode går betydelig kjappere. Programmene blir tyngre ja - men vi har maskinkraft, så det er ikke noe problem. Det går fort nok. Minne? Ikke no problem.

 

Det er helt feil å tro at det å lage kjapp kode = bra kode. Det er også helt feil å tro at kjapp kode = ubetydelig ekstrakostnader. Det er lett å lage kode som får ting til å funke. Samtidig må man tenke på vedlikehold, og rask kode kan ofte være drepen for vedlikehold, fordi koden kan bli for sær.

 

Make it work

Make it fast

Make it good

 

Idag, så stopper vi på make it work. Vi skal tjene penger, og kunden er faktisk overhode totalt uinteressert i de 2 siste leddene. Fordi det gir ikke kunden noe som helst. De 2 leddene er også svært kostbare.

 

En kunde kommer ofte tilbake og vil ha ekstra features, eller man bare fortsetter å utvikle greia. Om du brukte 2d på "make it work, 2d på "make it fast", og 2d på "make it good" - og så skal skrive om dritten, så har du i realiteten kastet bort 4dager. Det er mange tusen kroner det.

 

På toppen av dette så er de fleste programmerere dårlige, og viser liten interesse for faget. De har en jobb og er fornøyd med det. Bubblesort ftw.

De fleste programmerere bruker også mye tid på å lære seg nye ting, for å i det hele tatt henge med i den teknologiske hverdagen.

Java er ikke bare java. I et lite program så forholder jeg meg lett til 10 ulike teknologier i form av under-språk, konfigurering, biblioteker, rammeverk, verktøy etc etc etc.

 

Dagens software er faktisk mye bedre enn det var for 10år siden. Men da fantes ikke internett, sql-injections, buffer overflow, og folk var fornøyd med noe som lignet en knapp.

Idag skal knappen automagisk skaleres og tilpasses svaksynte, ha animasjoner, automagisk posisjonere seg etc etc etc.

 

Du snakker om en verden jeg overhode ikke kjenner meg igjen i. Det er en fin verden, men den fins ikke.

 

Optimalisering er også skummelt. Fordi kompilatorer gjør faktisk enormt mye optimalisering for deg. Så å skrive "optimalisert kode" som noen idioter liker å gjøre - trenger faktisk ikke være optimalisert, fordi den er så sær at den går glipp av den autmatiske optimaliseringen som ofte er best.

 

Det riktige her, er å stille spørsmålet "går det treigt?". Hvis ja, OG KUN HVIS JA, så gjør man en "profiling" av koden. Finner punktet der det går treigt, OG KUN DER, gjør noe med saken. Ofte snakker vi om dårlig algoritme fremfor andre ting.

I min verden php/java web apps - så er det sql kall som er det som bruker mest tid. Går det for treigt så trenger man kanskje bare en index i basen - problemet løst.

 

Hvis kunden ikke betaler - så er det ikke et problem.

Endret 20. desember 2008 av DarkSlayer

[Anders Jensen]

De kan optimalisere så mye de vil for Shanghai. Nehalem kommer til å ta den kaka fullstendig uansett. Dessverre..

AMD ser ut til å ha ihvertfall et halvår med den beste serverløsningen over hele linja. I et fungerende marked ville det vært tilstrekkelig. For de som skal handle nå er det greit å vite at Java vil fungere enda bedre på Shanghai om en stund.

Kanskje det. Bilindustrien ser gjerne at salget av et merke begynner å vakle for gjeldende merke i det folk mister troen på det, ikke 3 måneder etter at de er konkurs og tilbudet av biler i distrubusjonskanalen blir lite. Ingen vil sidde med et produkt en ikke får support, reservedeler eller oppgraderinger til. Når AMD ligger så langt nede og Nehalem grisebanker Shanghai maskiner med dobbelt så mange kjerner og sokkler da kan en jo begynne å lure på hva det neste blir. Kanskje noen kjøper SUN og AMD for å starte en ny vertikal leverandør?

 

Når vi først er inne på java, har du sett denne:

http://www.phoronix.com/scan.php?page=arti...mance&num=1

Linux er raskere enn vista i noe. Joda, ikke akkurat store nyheter det. Java setter OS stacken ganske mye på prøve siden det er mye trådskifting og bakgrunnsprosesser som skal samhandle. Ikke tilfeldig atmer ryddige miljøer som Linux/Unix og da gjerne på Power/IA64 kjører java best. Det handler om å jobbe smart.

 

Darkslayer: Enig i det meste du sier. De fleste programmerere er ikke tjent med å optimnalisere. Men noen er veldig tjent med det. Har selvsett folk gjøre forferdelige tabber i valg av teknologi som førte til store forsinkelser for produktet. Det ble rett og slett så tregt at det ikke var brukbart. Tenk store datastrukturer lagret i XML og behandlet i c# programmer. Noen må ha vært full. Fikk beskjed om å optimalisere serverne mine for å håndtere det. Jeg sa "ikke faen" på en litt mer diplomatisk måte. Deretter byttet de til c++ og renere datastrukturermed ca 10x ytelsesforbedring. Jeg kunne kanskje gitt de 1,5-2x med råeste CPU, SSD og RAID kontroller. Til en lite hyggelig pris og fortsatt ubrukelig.

Endret 21. desember 2008 av Anders Jensen

[Osse]

De kan optimalisere så mye de vil for Shanghai. Nehalem kommer til å ta den kaka fullstendig uansett. Dessverre..

 

Er du betalt av Intel for å spre møkker, vet du er kunnskapsrik og burde være relativt inteligent. Viser også til innlegget lengre nede, er iogfordeg morsomt med fanatikere i begge leire, men en hver med litt iq burde ha respekt for at det overhode finnes konkuranse, sjekk litt angående r&d for du er så stolt av intel er litt bedre, og pr i dag har litt bedre cpu, og vel på server fronten har de vel ikke det pr i dag.

[DarkSlayer]

*snipp

 

Darkslayer: Enig i det meste du sier. De fleste programmerere er ikke tjent med å optimnalisere. Men noen er veldig tjent med det. Har selvsett folk gjøre forferdelige tabber i valg av teknologi som førte til store forsinkelser for produktet. Det ble rett og slett så tregt at det ikke var brukbart. Tenk store datastrukturer lagret i XML og behandlet i c# programmer. Noen må ha vært full. Fikk beskjed om å optimalisere serverne mine for å håndtere det. Jeg sa "ikke faen" på en litt mer diplomatisk måte. Deretter byttet de til c++ og renere datastrukturermed ca 10x ytelsesforbedring. Jeg kunne kanskje gitt de 1,5-2x med råeste CPU, SSD og RAID kontroller. Til en lite hyggelig pris og fortsatt ubrukelig.

 

XML - grøss, frysninger.

 

Du peker på en vanlig feil, og en feil som ikke er opplagt til å begynne med. Xml var sikkert fint til å begynne med. Det er jo dritlett, nytt og spennende. Men pga valget man tar med teknologi, så ender man opp med å lage et sirupsystem. 2år senere X 5utviklere, så er det til en stygg pris.

 

Joa. Det å tenke seg om et par ganger rundt teknologi er viktig. Det jeg sku frem til er jo at det er veldig mange parametere som er oppi gryta når man koker sammen en løsning. At java blir optimalisert for en bestemt cpu har ca 2% betydning i mine øyner. Mange driftere har ofte et nært forhold til en bestemt leverandør, kanskje for pris- eller supportfordeler. Mange er jo "HP server er best" til det fanatiske. Ofte er ikke hardware problemet. Hardware er dritbillig.

[Anders Jensen]

At java blir optimalisert for en bestemt cpu har ca 2% betydning i mine øyner. Mange driftere har ofte et nært forhold til en bestemt leverandør, kanskje for pris- eller supportfordeler. Mange er jo "HP server er best" til det fanatiske. Ofte er ikke hardware problemet. Hardware er dritbillig.

Antagelig er ikke optimaliseringene CPU spesifikke i det heletatt. F.eks vil teknikker for å kjøre garbage collection være like nyttige for alle andre multicore maskiner. Tipper Nehalem vil utnytte 99-100% av de påtenkte optimaliseringene. Om så ikke er tilfelle så blir det et smalt marked de putter penger inn i, ikke helt java tankegangen.

 

Enig i at hardware er billig så lenge du snakker om 2-way servere. 4-way x86 er fortsatt greit. Etter det beggynner det å koste.

Endret 21. desember 2008 av Anders Jensen

[HKS]

De kan optimalisere så mye de vil for Shanghai. Nehalem kommer til å ta den kaka fullstendig uansett. Dessverre..

 

Er du betalt av Intel for å spre møkker, vet du er kunnskapsrik og burde være relativt inteligent. Viser også til innlegget lengre nede, er iogfordeg morsomt med fanatikere i begge leire, men en hver med litt iq burde ha respekt for at det overhode finnes konkuranse, sjekk litt angående r&d for du er så stolt av intel er litt bedre, og pr i dag har litt bedre cpu, og vel på server fronten har de vel ikke det pr i dag.

Han er nok ikke betalt av Intel for å spre møkk...

 

http://it.anandtech.com/IT/showdoc.aspx?i=3484&p=11

 

Akuratt denne sammenligner Shanghai på 2,66GHz med Core 7i på 2,66GHz i enkelte serverbenchmarks.

 

It looks like the newest Xeon will be about 36% faster in MySQL, 26% on our MCS website, and 22% faster on Oracle. That is quite impressive, but this is only a preview and we are only showing you single processor results. Take them with a grain of salt, but it looks like the newest Xeon will smash things up.

 

Merk også at i den testen har Shanghai en fordel på klokkefrekvensen...

 

Det ser nok dessverre ut som at når Nehalem basert Xeon kommer i februar/mars så vil AMD miste det det siste lukrative markedet hvor de har vært best på de siste årene...