Er java et tregt språk?

[doloop]

Dette er dog bare et av Oracles potensielle problemer. Mange er ikke fornøyd med hvordan Oracle kjører Java-skuta og f.eks. Eclipse Foundation vha. Ian Skerrett har bedt Oracle om å "get a clue"

Sun gjorde det de holdt på med mye bedre enn oracle. Tviler på at det er særlig mange som er uenige om det.

 

Spørsmålet er vel hvordan dette skal løses. Å gjenopprette sun er vel ikke en mulig løsning nå lenger. Men kanskje gi de gamle sun prosjektene litt friere tøyler, slik at de kan få fortsette litt mer som før.

 

På en annen side så er det vel et spørsmål om hvor lenge java ansees å være nødvendig, for lokale programmer finnes det, og har alltid funnets andre språk som i mine øyne gjør samme nytte. Og for nettprogrammer har html5 veldig mange nye spennende muligheter.

 

Java er jo ikke det raskeste av språk, og det er en opplevelse å programmere det. (Ikke mitt favorittspråk)

 

Jeg sier ikke at java vil forsvinne med det første, for det er det alt for stort. Men kanskje at java for vanlige bruker kanskje mister sin status, og at apple ikke vil ha ansvar for å utvikle noe som ikke lenger er så viktig for deres fokusgruppe.

 

 

Kjære deg.

 

Java er ikke et tregt språk, java som alle andre språk har sin styrker og svakheter, men argumentet om at det er tregt er et argument fra ignoranse. Du vil finne eksempler der kode kjører kjappere på C og eksempler der java kjører kjappere en C kode (les feks om hotspot optimering). Nå er derimot ikke hastigheten til et språk det viktigste for normale programmer (ja i spill vil gjerne dette bety noe). Det som betyr noe i den virkelige verden er hvor mye erfaring som finnes, hvor lett et program er å utvikle, og hvor lett det er å vedlikeholde. Ettersom java i dag kan løse de fleste problemer man kommer over, og det er så mye ekspertise inne i miljøet er det ikke trolig det dør ut. Ikke fordi det er så mye bedre enn alt annet, men fordi det er bra nok, og det er kjent teknologi.

 

Bare for opplysning, Java er i dag og har vært det siste tiåret det språket med mest aktivitet. Sist statistikk jeg så viste at omtrent 40% av all ny kode som lages i verden er nettop java. Java er også mer enn bare java apiene, det er en VM som kjører en rekke andre språk (feks Scala, Ruby, Groovy og Clojure), det er også en plattform som en del av kjempene i IT verden har som grunnpilar (Google, IBM, Oracle mm). Java opplever også nå en ny fødsel på Android, et område jeg tror vil vokse veldig mye fremover.

 

 

Men, dersom du mener desktop er det viktige innen programvare, ja da har du rett, java har ikke mye å stille opp med (og en del av jobben min er swing utvikling så jeg vet om dets problemer). Java sin styrke kommer på serversiden, det området som også er mest voksende innen IT verden. Jeg tror ikke vi ser java dø som den de facto utviklingsplattformen på lenge enda, ihvertfall ikke som følge av teknisk limitasjoner. Det er jo selfølgelig mulig oracle gjør noen kjempebrølere, men selv da ville jeg tro (ettersom java er opensource) at java ville overleve.

 

At apple valgte å stoppe sin utvikling av java er mer et tegn på at de ikke satser på serversiden og at de ønsker å knytte sine kunder til operativsystemet, eller ihvertfall ikke betale for utvikling av noe som lar kundene deres bytte plattform (java har jo som kjent den fine muligheten å kjøre på alle platformer som støtter dens rammeverk).

Endret 29. oktober 2010 av doloop

[Beef Supreme]

Kjære deg.

 

Java er ikke et tregt språk, java som alle andre språk har sin styrker og svakheter, men argumentet om at det er tregt er et argument fra ignoranse. Du vil finne eksempler der kode kjører kjappere på C og eksempler der java kjører kjappere en C kode (les feks om hotspot optimering). Nå er derimot ikke hastigheten til et språk det viktigste for normale programmer (ja i spill vil gjerne dette bety noe). Det som betyr noe i den virkelige verden er hvor mye erfaring som finnes, hvor lett et program er å utvikle, og hvor lett det er å vedlikeholde. Ettersom java i dag kan løse de fleste problemer man kommer over, og det er så mye ekspertise inne i miljøet er det ikke trolig det dør ut. Ikke fordi det er så mye bedre enn alt annet, men fordi det er bra nok, og det er kjent teknologi.

 

Bare for opplysning, Java er i dag og har vært det siste tiåret det språket med mest aktivitet. Sist statistikk jeg så viste at omtrent 40% av all ny kode som lages i verden er nettop java. Java er også mer enn bare java apiene, det er en VM som kjører en rekke andre språk (feks Scala, Ruby, Groovy og Clojure), det er også en plattform som en del av kjempene i IT verden har som grunnpilar (Google, IBM, Oracle mm). Java opplever også nå en ny fødsel på Android, et område jeg tror vil vokse veldig mye fremover.

 

Tips: Lag to identiske programmer som sorterer en liste med 10.000 objekter av en klasse. Det ene programmet skrevet i C++ og det andre i Java. Legg til en timer som skriver ut i console hvor mange ms det tar for hvert av programmene. Kom så tilbake her og si at "argumentet om at det er tregt er et argument fra ignoranse"

 

Java er mest brukt fordi man trenger ikke være spesielt flink til å holde styr på så mye kode som man må i f.eks C++, så utviklingstiden går kraftig ned sammen med antallet bugs. Java tar seg av all minnehåndtering osv selv, noe som igjen fører til treghet i form av at objekter oftest blir kopiert i minnet, istedet for at det sender en pekerreferanse.

Endret 30. oktober 2010 av Beef Supreme

[doloop]

Kjære deg.

 

Java er ikke et tregt språk, java som alle andre språk har sin styrker og svakheter, men argumentet om at det er tregt er et argument fra ignoranse. Du vil finne eksempler der kode kjører kjappere på C og eksempler der java kjører kjappere en C kode (les feks om hotspot optimering). Nå er derimot ikke hastigheten til et språk det viktigste for normale programmer (ja i spill vil gjerne dette bety noe). Det som betyr noe i den virkelige verden er hvor mye erfaring som finnes, hvor lett et program er å utvikle, og hvor lett det er å vedlikeholde. Ettersom java i dag kan løse de fleste problemer man kommer over, og det er så mye ekspertise inne i miljøet er det ikke trolig det dør ut. Ikke fordi det er så mye bedre enn alt annet, men fordi det er bra nok, og det er kjent teknologi.

 

Bare for opplysning, Java er i dag og har vært det siste tiåret det språket med mest aktivitet. Sist statistikk jeg så viste at omtrent 40% av all ny kode som lages i verden er nettop java. Java er også mer enn bare java apiene, det er en VM som kjører en rekke andre språk (feks Scala, Ruby, Groovy og Clojure), det er også en plattform som en del av kjempene i IT verden har som grunnpilar (Google, IBM, Oracle mm). Java opplever også nå en ny fødsel på Android, et område jeg tror vil vokse veldig mye fremover.

 

Tips: Lag to identiske programmer som sorterer en liste med 10.000 objekter av en klasse. Det ene programmet skrevet i C++ og det andre i Java. Legg til en timer som skriver ut i console hvor mange ms det tar for hvert av programmene. Kom så tilbake her og si at "argumentet om at det er tregt er et argument fra ignoranse"

 

Java er mest brukt fordi man trenger ikke være spesielt flink til å holde styr på så mye kode som man må i f.eks C++, så utviklingstiden går kraftig ned sammen med antallet bugs. Java tar seg av all minnehåndtering osv selv, noe som igjen fører til treghet i form av at objekter oftest blir kopiert i minnet, istedet for at det sender en pekerreferanse.

 

 

At du tror å sortere en liste en gang er et mål på noe viser din ignoranse. Å sammenligne en liten kodensutt med en annen er idioti. La meg forklare.

 

JIT på en veldig enkel måte (er veldig mye i JIT jeg ikke kan noe om så jeg kan ikke forklare alt). JIT er java sin Just In Time compiling, det er dette som er hovedforskjellen mellom java og c++.

 

I c++ blir koden din øyeblikkelig oversatt til maskinkode. Compileren kan gjøre en del optimiseringer for type prosessor osv, men la oss ikke gå i dybden på dette, det er ikke vitkig og ikke her noen forksjell er. I java blir koden din oversatt til byte code. På dette tidspunktet har ikke du kjørbar kode, du har et sett med instruksjoner til JIT. Hva dette betyr er at maskinkoden ikke er kompilert før koden kjøres. Dette betyr også at JIT har mye mere informasjon om programmets nåværende stat, i motsetning til i c++ hvor den må ta utgangspunkt i et generell stat når den compiles. Her har java (og .net feks) en fordel; dersom klassen inneholder 10000 felter, men bare 2 er faktisk i bruk, ja da compilerer JIT klassen til kun å ha de 2 felter, mens i c++ vil den måtte sette av pekere for alle 10000 feltene irrelevant om de brukes i denne sesjonen. JIT lærer også å kjenne igjen kodesnutter mens den kjører, og om den ser for eksempel at disse 14 metodene blir alltid kjørt etterhverandre eller denne loopen blir veldig ofte kjørt kan den gjøre ting som å inline koden (http://en.wikipedia.org/wiki/Inline_expansion).

 

Andre eksempler på optimisering JIT kan gjøre som et compila c++ program ikke kan gjøre er er type sjekking og context switching.

 

Jeg synes ikke direkte sammenligninger mellom språk er direkte nyttige, men her har du en ganske nøytral sammenligning som viser java vinner i enkelte eksempler.

 

http://scribblethink.org/Computer/javaCbenchmark.html

 

 

Du tar også feil i at java kopierer verdier, og dette tyder på at du har misforstått noe grunnleggende eller rett og slett ikke kan noe java.

 

Hovedgrunnen til java sitt dårlige rykte er 3 ting. Den ene har ikke hatt relevanse i de siste 5 årene ihvertfall, og den andre er et reelt issue for ting som krever full kontroll over timing.

 

Det første er at java er tregt. Dette har ikke stemt på lenge. En dårlig java koder og en dårlig c++ koder, da vil nok java programmereren skrive raskest kode. En god java programmerer og en god c++ programmerer vil begge kunne skrive rask kode. En ekspert java programmerer og en ekspert c++ programmerer vil c++ programmereren kanskje kunne gjøre flere optimiseringer enn java og vinne marginalt. Java er ikke et tregt språk tiltross for at du har hørt dette fra dine venner eller lest det på et forum.

 

Det andre er at java ikke kan gjøre ting som krever nøyaktighet til millisekundet, dette har ikke noe med java sin kjapphet, men med det faktum at java har en garbage collector. Denne vil rense minnet når den føler det er skittent, og som følger kan den kjøre akkurat når din timing var veldig viktig, og ødlegge for deg. Derfor er ikke Java egnet til ting som spill. Du kan få veldig mye lagg akkurat i det minnet blir renset, noe som ikke er akseptablet. Om derimot om 5 000 http requests et sekund blir delayet med 1 sekunder spiller ikke dette noen rolle for en webplattform.

 

Den siste er skrivebordsprogrammer. Disse er ofte trege, ikke som følge av java men som følge av APIene for skrivebordsprogrammer ikke har vært et satsningsområde, og som følger ikke har blitt oppdatert.

[Del]

At du tror å sortere en liste en gang er et mål på noe viser din ignoranse.

Sortering av liste er den mest relevante operasjonen for databaseytelse, som igjen er den mest relevante beregningstunge work-load'en for integer kode. Du bør være litt mer forsiktig med dine påstander. Kanskje du mener det er på flyttallskode Java har sin store styrke?

[doloop]

At du tror å sortere en liste en gang er et mål på noe viser din ignoranse.

Sortering av liste er den mest relevante operasjonen for databaseytelse, som igjen er den mest relevante beregningstunge work-load'en for integer kode. Du bør være litt mer forsiktig med dine påstander. Kanskje du mener det er på flyttallskode Java har sin store styrke?

 

Igjen: å sortere en liste en gang er ikke et mål for reell ytelse. Sorter listen 10 millioner og vi kan begynne om å snakke om ytelse. Hvilket program ser du for deg sorterer en liste en gang og aldri igjen, som igjen har kjempekrav til ytelse ned til millisekund nivå?

 

Det virker som du ikke forsto, eller med vilje ser bortifra hva jeg snakket om om hotspot optimisering. I en JIT mot ikke JIT sammenligning må du se på ytelse i bruk, ikke i hvor lang tid det tar i første gjennomkjøring. I native kode vil dette bli det samme hver iterasjon om alt annet er likt, men med en JIT som også gjør optimiseringer basert på erfaring (slik som java gjør) vil det bli bedre å bedre resultater frem til koden når full optimisering (Som er optimisering en vanlig compiler ikke kan gjøre grunnet mindre informasjon).

 

Et program kjører ikke en gang så avsluttes, de kjører i uker, måneder eller år. JIT tar som jeg har prøvd å fortelle nå gang på gang tid for å analysere best mulig optimisering, og derfor vil det ikke være en relevant sammenligning å se hvor fort den første sorteringen går. Kjør sorteringen et par millioner ganger på begge steder så kan vi begynne å snakke om å sammenligne hastighet (om du fortsatt mener en sammenligning av sortering av et array er alfa og omega testen av et språk). Dette er ikke relevant i driften av et program, om det går bittelitt tregre første dagene det kjører, men deretter kjappere og kjappere, og tilpasser seg automatisk bruksmønstre, ja da for meg er ihvertfall dette en kjempefordel.

 

Det virker som du prøver å påstå at java er dårlig på nettopp database operasjoner, når Java er defacto standarden i bank sektoren, den industrien med noe av den tyngste database bruken som finnes. Det brukes også mye i søking feks apache lucene, som også er database intesivt.

 

Jeg har heller aldri hevdet at java er sterk på flyttall, men dets limitasjoner er ikke som følge av hastighet, men IEEE prosessorspesifikasjonen og bakoverkompatibilitet.

[Runar]

Forslag til bedre emnetittel mottas med takk! Dette innlegget vil bli slettet iløpet av 24 timer.

[endrebjo]

Det virker som du prøver å påstå at java er dårlig på nettopp database operasjoner, når Java er defacto standarden i bank sektoren, den industrien med noe av den tyngste database bruken som finnes. Det brukes også mye i søking feks apache lucene, som også er database intesivt.

Jeg tar ikke noe som helst standpunkt for hva som er kjappest av C/C++ og Java, men merker meg likevel en liten ting. Du er sikkert allerede klar over at fryktelig mange defacto standarder ikke nødvendigvis kommer av ytelsesfortrinn. F.eks har PHP blitt fryktelig stort på internett, også på kritiske og ytelsesviktige sider, til tross for at det er et tregt skriptspråk (selv om Zend prøver å fikse litt). Facebook kjørte lenge PHP og løste ytelsesproblemet med å kjøpe mer hardware. Jeg leste at en eller annen hevdet at Facebook kunne klart seg med halve maskinparken hvis de hadde brukt C++ i stedet. Og det siste året kan det se ut som at de har auto-portet deler av PHP-koden sin til C++ (link).

 

Så da kan det vel strengt tatt være at banksektoren mener at Java er raskt nok, og at utviklings- og vedlikeholdskostnadene ved å bruke Java fremfor C++ vipper skålen i favør av Java. Altså at Java ikke nødvendigvis er kjappest, men samtidig at det ikke er tregt. I såfall støtter jeg deler av "vendettaen" din om å prøve å overbevise enkelte om at Java ikke er tregt, men i enkelte tilfeller føler jeg du prøver litt for hardt å overbevise om at Java er like kjapt eller kjappere. Det er vel sistnevnte som enkelte ikke ønsker/klarer å ta inn over seg.

[Del]

Igjen: å sortere en liste en gang er ikke et mål for reell ytelse. Sorter listen 10 millioner og vi kan begynne om å snakke om ytelse. Hvilket program ser du for deg sorterer en liste en gang og aldri igjen, som igjen har kjempekrav til ytelse ned til millisekund nivå?

OK, så det var at listen ble sortert en gang du hadde innvendinger imot. Så du mener faktisk at databasetype oppgaver er et område hvor Java typisk har bedre ytelse enn C/C++ implementeringer?

Det virker som du ikke forsto, eller med vilje ser bortifra hva jeg snakket om om hotspot optimisering.

Neida, jeg er kjent med både det og JIT, men jeg ser vel mer på det som et plaster på elendig ytelse enn noe som drar ifra kompilert kode.

I en JIT mot ikke JIT sammenligning må du se på ytelse i bruk, ikke i hvor lang tid det tar i første gjennomkjøring. I native kode vil dette bli det samme hver iterasjon om alt annet er likt, men med en JIT som også gjør optimiseringer basert på erfaring (slik som java gjør) vil det bli bedre å bedre resultater frem til koden når full optimisering (Som er optimisering en vanlig compiler ikke kan gjøre grunnet mindre informasjon).

Alt det høres jo fint ut, men profilering av kode er fullt mulig i C/C++/Fortran, hvor du gir inn typiske datasett og kompilatoren gjør optimaliseringer knyttet til det. Derfra har vi også et godt erfaringsgrunnlag for å se nøyaktig hvor effektiv denne metodikken er sammenlignet med å kompilere uten profilering. Gevinsten er ofte liten, gjerne knyttet til lokalitet av minne og grenpredikering.

Et program kjører ikke en gang så avsluttes, de kjører i uker, måneder eller år. JIT tar som jeg har prøvd å fortelle nå gang på gang tid for å analysere best mulig optimisering, og derfor vil det ikke være en relevant sammenligning å se hvor fort den første sorteringen går. Kjør sorteringen et par millioner ganger på begge steder så kan vi begynne å snakke om å sammenligne hastighet (om du fortsatt mener en sammenligning av sortering av et array er alfa og omega testen av et språk).

Hva tror du skjer om vi kjører det en million ganger hvert sted? Blir java raskere enn C++ implementeringen?

Det virker som du prøver å påstå at java er dårlig på nettopp database operasjoner, når Java er defacto standarden i bank sektoren, den industrien med noe av den tyngste database bruken som finnes. Det brukes også mye i søking feks apache lucene, som også er database intesivt.

Jasså, hvilke Java-baserte databaser er så utstrakt i bruk i banksektoren? Er du kjent med java-prosjekter i banksektoren og hvilke erfaringer de har gjort seg. Typisk om de er fornøyd med ytelse og utviklingskostnad?

Jeg har heller aldri hevdet at java er sterk på flyttall, men dets limitasjoner er ikke som følge av hastighet, men IEEE prosessorspesifikasjonen og bakoverkompatibilitet.

Her må du nesten forklare hva du mener. Mener du at Java er svak på flyttall? Isåfall hvorfor? Endret 30. oktober 2010 av Del

[doloop]

For å oppsummere hva jeg mener uten å gå frem og tilbake med abstrakte eksempler.

 

Jeg hevder java ikke er en sinke. Jeg sier ikke java vil slå c++ eller andre språk i alle eksempler, jeg sier derimot at du ikke kan avskrive Java på grunnlag av hastighet med mindre som nevnet du krever tidsnøyaktig utføring. Java holder tritt med, og vil i tilfeller yte bedre enn for eksempel c++ implementasjoner på grunn av JIT. Du kan ei heller realistisk optimisere c++ kode til å gjøre alle de samme optimaliseringene som JIT gjør uansett hvor mye du prøver med mindre programmet ditt er på 5 linjer kode.

 

I et lite program på maks et par tusen kodelinjer er det mulig å gjøre en del optimiseringer som du nevner, men du kan for eksempel aldri gjøre dynamisk rekompilering mot spesifikke scenario slik JIT gjør når den oppdager et "hotspot". Det er derfor Java i visse tilfeller kan slå c++ kode i ytelse.

 

 

La meg lage et forenklet JIT eksempel:

Du har et program som skal filtrere spam post fra ikke spam post. Det vil være trender i hvilken av deteksjonsrutinene dine som finner spam ettersom hvilken spammer som er aktiv på hvilken dag. Denne uken på mandag gjør en analyse av ordene i tittelen det bra, mens rutinen som skanner igjennom ordene i mailen ikke treffer like ofte. Tirsdag reverseres denne trenden, rutinen som undersøker teksten er den mest effektive å kjøre først.

 

I et c++ program er flyten av programmet ditt fast og ettersom hva som er optimalt vil endre seg kan du ikke forvente å ha kompilert denne flyten optimalt. Du må enten ha sett for deg denne endringen å kjøre mer kode for å bestemme hva som er best (noe som igjen ville koste ytelse og du er da omtrent like langt som JIT, men med milevis mere kode å vedlikeholde). Dersom du ikke har laget en algoritme for å bestemme rekkefølgen vil din kompilerte klasse alltid følge rekkefølgen på kallene som du skrev. JIT derimot kan se trenden (selfølgelig ikke perfekt, men bedre enn ingen optimering). Så tirsdag etter å ha kjørt en stund oppdager den at "oj, her er det bedre å kjøre ord først" branchen, og kompilerer ned ny native kode etter denne rekkefølgen.

 

Du kan prøve å få programmet ditt til å dekke alt, men med mindre du skal skrive enormt mye mere kode (Java har vel ca 250 000 c++ kodelinjer dedikert i hovedsak til optimisering som alle java programmer drar nytte av) vil du ikke kunne forutse alt slikt. Java kan også inline på måter du ikke kan i c++. Du kan i c++ manuelt inline eller gi keywords til compileren for å fortelle her er det nok lurt å inline, men dette vil kun dekke de stedene du manuelt føler er viktige, eller som kompilatoren tagger som lure å inline. I JIT kan en klasse rekompileres når JIT oppdager at her er det noe å hente på å gjøre dette med en faktisk analyse av kjøringen på dette tidspunktet, ikke ved compilering. Det kan være på steder som er helt sære for utvikleren selv å tenke på, og som profileringen ikke avslører fordi bruksmønster endrer seg under levetiden til programmet.

 

 

Anngående databaser:

Dersom du spør etter faktiske database implementasjoner i java er det ikke de store databasene ofte skrevet i java (men vi har jo noen, HBase og hsqldb blant annet), jeg regnet med database at du faktisk siktet til bruk av database ikke skriving av data til disk. Dersom vi tar Oracle som utgangspunkt er denne mye eldre enn Java, og dermed kunne umulig vært utviklet i java. Det samme gjelder MySql(ikke at denne benyttes i bankvesenet, men det er verdens mest brukte database). Dette er nok hovedgrunnen til java baserte sql implementasjoner ikke er standard i dag, de største databasene har eksistert før java kom på banen, og de som satt med ekspertise på database feltet var mer kjent med andre språk.

 

 

Flyttall:

Jeg regnet med kritikken din siktet til javas unøyaktighet ved strictfp og det faktum at java sine krav som følge av bakoverkompatibilitet er mindre nøyaktige enn de fleste floating point prosessorene i dag. Dersom dette er feil fortell meg hva problemet ditt er.

 

Flyttall er derimot langt fra min sterke side, jeg har enda ikke trengt å bry meg om det så har ikke noen dyp innsikt annet enn fra lesing. Men dersom du har et godt argument å komme med vil jeg gjerne høre det.

Endret 30. oktober 2010 av doloop

[Del]

Jeg hevder java ikke er en sinke. Jeg sier ikke java vil slå c++ eller andre språk i alle eksempler, jeg sier derimot at du ikke kan avskrive Java på grunnlag av hastighet med mindre som nevnet du krever tidsnøyaktig utføring. Java holder tritt med, og vil i tilfeller yte bedre enn for eksempel c++ implementasjoner på grunn av JIT. Du kan ei heller realistisk optimisere c++ kode til å gjøre alle de samme optimaliseringene som JIT gjør uansett hvor mye du prøver med mindre programmet ditt er på 5 linjer kode.

Det er helt uvesentlig om du får gjort de samme optimaliseringene, det som betyr noe er ytelsen du får i praksis. Det eneste jeg har sett deg komme opp med her (utenom oppgulp fra Java salgsprat) er en ti år gammel lenke hvor skribenten åpenbart forsøker å forsvare Java, samt en påstand om suksesshistorie i bankvesenet.

 

Her skal du få to ferske lenker fra meg:

http://www.itu.dk/~sestoft/papers/numericperformance.pdf

http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf

 

Når det gjelder bankvesenet venter jeg fortsatt på at du skal besvare mine spørsmål ovenfor.

I et c++ program er flyten av programmet ditt fast og ettersom hva som er optimalt vil endre seg kan du ikke forvente å ha kompilert denne flyten optimalt.

Det er fullt mulig å profilere et C++ program for å finne hotspots. Du ser ut til å tro at JIT vil ordne dette for deg. Jeg vil anbefale deg en litt mindre religiøs tilbedelse av JIT, det finnes ingen kompilator som kan ordne opp i råtten kode, JIT vil ikke erstatte behovet for å studere flyten i et program. Gevinsten ved å kunne gjøre optimaliseringer i run-time er avhengig av hva du faktisk får ut av det, og her er du så diffus som det overhodet er mulig å bli. Gi meg noen virkelige datapunkt, og konkrete eksempler med tilhørende analyse.

Anngående databaser:

Dersom du spør etter faktiske database implementasjoner i java er det ikke de store databasene ofte skrevet i java (men vi har jo noen, HBase og hsqldb blant annet), jeg regnet med database at du faktisk siktet til bruk av database ikke skriving av data til disk. Dersom vi tar Oracle som utgangspunkt er denne mye eldre enn Java, og dermed kunne umulig vært utviklet i java. Det samme gjelder MySql(ikke at denne benyttes i bankvesenet, men det er verdens mest brukte database). Dette er nok hovedgrunnen til java baserte sql implementasjoner ikke er standard i dag, de største databasene har eksistert før java kom på banen, og de som satt med ekspertise på database feltet var mer kjent med andre språk.

Tror du virkelig at alder på kodebasen er grunnen til at praktisk talt ingen koder databaser i Java? Til din informasjon ble MySQL sluppet i 1995, men SQLite har du hoppet over, den ble sluppet i 2000 når både JIT og hotspot var vel etablert. Endret 31. oktober 2010 av Del

[Beef Supreme]

Fryktelig krass du ble da. Jeg påstår ikke at jeg har mest peiling av alle i verden i Java eller C++, men med mindre du har holdt på med begge språkene i over 40 år og kan alt, så tror jeg at det jeg har lært på NITH de siste årene er korrekt.

 

Utrolig morsomt at du skryter sånn av dette med hotspot. Har du lest dette?

Sun actually has multiple JVMs. The HotSpot JVM is written largely in C++, because HotSpot is heavily based on the Animorphic Smalltalk VM which is written in C++.

Såeh. Ro deg litt ned med fanboyismen din.

 

In any case. Poenget mitt er at jeg mener at man ikke kan si at et språk er kjappere enn et annet, hvis det er hovedsakelig skrevet i språket man sammenlikner det med. Hvordan kan Java være kjappere enn C++, hvis Java er avhengig av å ha størsteparten av sine egne funksjoner skrevet i C++ for å bli kjapt?

Endret 31. oktober 2010 av Beef Supreme

[doloop]

Vi er visst helt enig, det er helt uvesentlig å se på 10 linjer kodes utførelse (med mindre det er hele programmet ditt), og om det er det, ja da er sikkert krav som skalabilitet mye mere viktig en ytelsen per kjerne.

 

 

Hva er ytelse?

For en seriøs sammenligning av språks ytelse må vi jo være enig i hva ytelse er. Jeg definrer ytelsen til et språk som en korrelasjon mellom utviklingskostnader, skalabilitet og vedlikehold (kanskje slenge inn hardwarekostnader også?). Det hjelper fint lite om ditt java eller c++ program knuser alt på ytelse når det har 1000 brukere, men dersom det ikke lar seg skalere opp til 100 000 brukere uten enorme kostnader, ja da er det et dårlig valg såfremt dette vil være krevd om det lykkes med den første biten.

 

Jeg kan her for eksempel sikte til Integrasco, et norsk selskap som driver med søking av sosiale medier. På javazone ga de en forelesning om hibernate shards. Jeg tviler ikke på at første versjon av programmet deres kunne vært laget mye raskere om de valgte noe annet enn java og mysql (mysql for meg virker som et rart valg, men de forsvarte seg med å si det var dette de hadde kjennskap til, læringsprosses er vel også en del av utviklingskostnad i guess), men i dag hvor de sitter med 30-40 servere med data og må analysere denne ned til trender for nøkkelord, ja da ville de nok ha raskt funnet ut hvor dumt valget hadde vært å gått for en c++ løsning.

 

Tallknusing

Det finnes programmer der tallknusing av matriser er viktig. Java kan gjøre enkelte slike løsninger bra og enkelte dårlig. Det øyeblikke du trenger flere maskiner i nettverk som snakker sammen, dynamisk antall med tilgjengelig ressurser, eller varierende type kalkulasjoner kan java klare seg. Uten disse er nok ikke java det beste valget, her vil nok et lavnivå språk (slik som C) være best. Så dersom du skal lage et spill go ahead, ikke bruk java, det egner seg ikke til dette.

 

Profilering og hvordan måle ytelse

Ja det er mulig å manuelt profilere hotspots, og alle gjør dette, du kan selv velge hvor mye tid og penger du vil legge i optimisering, og om du har uendelig tid til å utvikle (og uendelig penger ettersom utvikling koster penger) er nok assembly språket du bør velge for alle programmer. I den virkelige verden derimot kan du ikke profilere og optimisere manuelt i uendelig tid.

 

 

Bankvesenet

For bankvesenet er det uhyrlig viktig å ha 100% feilfri operasjon og ingen nedetid på programvaren sin, denne bransjen velger da trygg, gjennomtestet og utprøvd teknologi, siden dette er det billigste alternativetet. De har valgt java fordi fordi dets ytelse er perfekt for denne bransjen. Jeg sier altså ikke de har valgt java fordi det er så mye kjappere på for eksempel sortere alle kontoene i banken alfabetisk deretter etter balanse, deretter etter hvor mange inskudd som blir gjordt i året, jeg sier de har valgt java fordi det gir en overall bedre ytelse enn hva alternativene gir.

 

Databaser

Det finnes en rekke databaser implementert i java, men få av disse er veldig populære, hvorfor tør jeg ikke spekulere i, men det gjør sikkert du. Jeg nevnte de to største jeg har hatt erfaring med (HBase og hypersonic), og ja mysql kom i 1995, når kom java? Jo i 1996 ble jdk 1.0 sluppet.

 

At du hevder det ikke finnes java databaser er også ganske feil. Mitt første treff på google lister følgende open source sql implementasjoner

 

Apache Derby

Ozone

Berkeley DB

NeoDatis ODB

H2

Perst

TinySQL

MyOODB

Metanotion BlockFile

JODB

AcornDB

Hypersonic SQL

Mckoi SQL Database

Quadcap Embeddable Database

Axion

yaRDBMS

Ashpool

db4o

One$DB

Neo4j

SmallSQL

jiql

Jalisto

 

SQLite

Jeg ser ikke hva SQLite har med diskusjonen å gjøre, hvorfor valgte de ikke java? De hadde sikkert et ønske om ikke å måtte ha en vm, eller de hadde ekspertise på et annet språk, eller de hadde et eller annet krav som java ikke oppfylte. Det blir jo regn spekulasjon.

 

Med mindre du kan vise til uttaleser fra Richard Hipp om at han ikke valgte java som plattform på grunn av ytelse, ja da er det ikke et poeng for eller i mot. Dersom du ønsker å gå ned veien om "Hvorfor er ikke x skrevet i java" ja da kan vi jo gjøre det motsatte også, "Hvorfor er ikke y skrevet i c++?

[Del]

Det hjelper fint lite om ditt java eller c++ program knuser alt på ytelse når det har 1000 brukere, men dersom det ikke lar seg skalere opp til 100 000 brukere uten enorme kostnader, ja da er det et dårlig valg såfremt dette vil være krevd om det lykkes med den første biten.

 

Jeg kan her for eksempel sikte til Integrasco, et norsk selskap som driver med søking av sosiale medier. På javazone ga de en forelesning om hibernate shards. Jeg tviler ikke på at første versjon av programmet deres kunne vært laget mye raskere om de valgte noe annet enn java og mysql (mysql for meg virker som et rart valg, men de forsvarte seg med å si det var dette de hadde kjennskap til, læringsprosses er vel også en del av utviklingskostnad i guess), men i dag hvor de sitter med 30-40 servere med data og må analysere denne ned til trender for nøkkelord, ja da ville de nok ha raskt funnet ut hvor dumt valget hadde vært å gått for en c++ løsning.

Hæh? Hvorfor mener du C++ ville vært et håpløst valg? Mener du at C++ kode har et problem med skalering? Tror du det er uvanlig å kjøre C++ kode på store klynger?

Bankvesenet

For bankvesenet er det uhyrlig viktig å ha 100% feilfri operasjon og ingen nedetid på programvaren sin, denne bransjen velger da trygg, gjennomtestet og utprøvd teknologi, siden dette er det billigste alternativetet. De har valgt java fordi fordi dets ytelse er perfekt for denne bransjen. Jeg sier altså ikke de har valgt java fordi det er så mye kjappere på for eksempel sortere alle kontoene i banken alfabetisk deretter etter balanse, deretter etter hvor mange inskudd som blir gjordt i året, jeg sier de har valgt java fordi det gir en overall bedre ytelse enn hva alternativene gir.

Vet du i det hele tatt hva du snakker om her, eller tar du det bare fra løse luften? La meg gjenta mine spørsmål, og se om du kan svare:

 

Jasså, hvilke Java-baserte databaser er så utstrakt i bruk i banksektoren? Er du kjent med java-prosjekter i banksektoren og hvilke erfaringer de har gjort seg. Typisk om de er fornøyd med ytelse og utviklingskostnad?

SQLite

Jeg ser ikke hva SQLite har med diskusjonen å gjøre,

Da vet du antagelig svært lite om databaser. Den er meget populær, mer vanlig enn alle de Java-basert du ramset opp til sammen med svært god margin. Blant annet Apple liker den godt. Selv Javabaserte Android bruker SQLite.

[doloop]

Hvorfor c++ ville vært et håpløst valg

 

Jeg tok kanskje litt hardt i når jeg sa "håpløst valg", men la oss gå igjennom punktene jeg mener gjør java til et utmerket valg på en slik løsning.

 

1) Ferdig skrevet gratis applikasjonsserver

Du finner ferdige løsninger som er grundig testet og verifisert, disse er som regel gratis og blir gratis oppdatert, noe som sørger for at din kode for ytelses-optimiseringer lenge etter at du er ferdig med å skrive den. De er også glimrende på skalering, og du trenger å ta få grep for å tilpasse deg skaleringen. I mange tilfeller vil skalering kun være et spørsmål om server konfigurasjon.

 

2) Stor sikkerhet og forutsigbarhet

Det er en milliard maskiner som daglig tester ut java sin virtual machine og APIene du bruker. Svakheter og mangler er grundig dokumentert og du kan planlegge rundt dem. Med mindre du lager alt selv vil du ha få overaskelser, og når du får dem har andre oppskrift ferdig for deg på hvordan de blir løst som oftest.

 

3) Sikkerhet i programmets oppførsel

Oppførselen til programmet ditt kan du stole på uavhengig av operativsystem og maskinvare. Du kan altså trygt oppgradere operativsystemet og maskinvare uten å måtte rekompilere og teste grundig.

 

4) Mulighet for flere språk

Du finner en rekke språk som er byte kode kompatibel med java, og de kan også skrives i samme IDE, og kalles opp direkte fra java kode, akkurat som vanlig java kode.

 

Et veldig godt eksempel her er trådsikkerhet. Dersom du har noen gang prøvd å skrive trådsikker kode vet hvor mye problemer dette byr på. Med java kan du veldig enkelt skrive trådsikker kode ved hjelp av Clojure. Lykke til med trådsikkerhet i c++ =)

 

5) Samme leverandør på hardware og software

Dette er miligens ikke et veldig sentralt punkt for mange, men du har muligheten til en alt i en løsning der et gigantisk selskap står som garantist for kompatibiliteten.

 

6) Min subjektive erfaringen fra min jobb

Jeg lager ERP system for blant annet bruk mot banksektor og det offentlige. Igjennom dette har jeg ofte måtte snakke med bank og offentlige systemer. Min programmeringspartner har tidligere jobbet med betaling og minibankløsninger for Nordea, og jeg har fra han fått høre mange historier.

 

Det første jeg har erfart fra bankene er at de tør ikke oppgradere gamle systemer. De er ikke komfortable med å gjøre endringer på deres gamle løsninger, og foreslår alltid workarounds uansett hvor tungvinte de er. Enkelte løsninger krever tilogmed spesialisert hardware kun for å kommunisere. Jeg har derimot opplevd at javaprosjekter som oftest er ansett som "levende", at de altså kan modifisere de (det tar fortsatt lang tid selvfølgelig).

 

Databaser

Som jeg skrev for n poster siden, nei det er ikke java databaser i utstrakt bruk i bankvesenet, jeg skrev jeg regnet med du snakket om database i henhold til bruk av databasen ikke den fysiske skrivingen av data til lagringsmedie. For eksempel bruk av hibernate.

 

Databaser er dessuten en veldig viktig del av jobben min; og jeg tar jeg til etteretning at du mener jeg er ignorant angående dette, og skal sørge for å studere dette emnet bedre så jeg kan komme meg opp på din kompetanse.

 

Kunnskapen min omfatter dog SQLite, og det jeg påpekte var at dette programmet ikke er relevant i diskusjonen om at java er et tregt, ineffektivt språk, akkurat som at en diskusjon rundt unreal engine ikke er relevant angående javas ytelse.

[zotbar1234]

Java tar seg av all minnehåndtering osv selv, noe som igjen fører til treghet i form av at objekter oftest blir kopiert i minnet, istedet for at det sender en pekerreferanse.

 

Eh, saken er at nettopp en copying collector kan være raskere enn eksplisitt allokering/deallokering. Hvorvidt det vil være tilfellet avhenger av allokeringsmønsteret til programmet. Så GC fører definitivt ikke til "treghet" uten forbehold.

[Del]

men la oss gå igjennom punktene jeg mener gjør java til et utmerket valg på en slik løsning.

Søk deg jobb hos Oracle, du er som en salgskatalog. Masse fine ord og ingen substans.

3) Sikkerhet i programmets oppførsel

Oppførselen til programmet ditt kan du stole på uavhengig av operativsystem og maskinvare. Du kan altså trygt oppgradere operativsystemet og maskinvare uten å måtte rekompilere og teste grundig.

Sikkerhet my ass. Bankid har gitt meg så mange grå hår at jeg får lyst til å riste deg. Det eneste positive jeg ser med Java pr. i dag er at det holder .net på armlengdes avstand. Å la innhold på nett kontrolleres av et selskap som Oracle er galskap, litt mindre galskap enn å gi kontrollen til MS riktignok.

4) Mulighet for flere språk

Du finner en rekke språk som er byte kode kompatibel med java, og de kan også skrives i samme IDE, og kalles opp direkte fra java kode, akkurat som vanlig java kode.

Dette er et argument for C og C++, ingen språk har rikere infrastruktur.

Et veldig godt eksempel her er trådsikkerhet. Dersom du har noen gang prøvd å skrive trådsikker kode vet hvor mye problemer dette byr på. Med java kan du veldig enkelt skrive trådsikker kode ved hjelp av Clojure. Lykke til med trådsikkerhet i c++ =)

Tråder er noe herk også i Java. OpenMp funker greit, ellers er jeg glad i flere prosesser.

6) Min subjektive erfaringen fra min jobb

Jeg lager ERP system for blant annet bruk mot banksektor og det offentlige. Igjennom dette har jeg ofte måtte snakke med bank og offentlige systemer. Min programmeringspartner har tidligere jobbet med betaling og minibankløsninger for Nordea, og jeg har fra han fått høre mange historier.

 

Det første jeg har erfart fra bankene er at de tør ikke oppgradere gamle systemer. De er ikke komfortable med å gjøre endringer på deres gamle løsninger, og foreslår alltid workarounds uansett hvor tungvinte de er. Enkelte løsninger krever tilogmed spesialisert hardware kun for å kommunisere. Jeg har derimot opplevd at javaprosjekter som oftest er ansett som "levende", at de altså kan modifisere de (det tar fortsatt lang tid selvfølgelig).

Da foreslår jeg at du er tydelig på at det er ERP systemer du uttaler deg om. Det gir mer tyngde og uendelig mer informasjonsverdi i posten din. Til din informasjon er ERP typisk ikke ytelsessensitivt, og derfor ser du utstrakt bruk av skripting. Bankene sliter med mye gammel Cobolkode, men C og C++ er til stede på det som krever ytelse og sikkerhet.

Kunnskapen min omfatter dog SQLite, og det jeg påpekte var at dette programmet ikke er relevant i diskusjonen om at java er et tregt, ineffektivt språk, akkurat som at en diskusjon rundt unreal engine ikke er relevant angående javas ytelse.

Koden i SQLite er public domain, og inneholder ikke mer kode enn at du kunne portet det over til Java rimelig enkelt. Når da hele verden bruker denne, også på Javabaserte systemer som Android, så er det et rimelig klart hint om at i dette tilfellet C (som også Postgresql er kodet med, MySQL er kodet i C++) er et bedre egnet språk enn Java. Når alle de vesentlige kommersielle databasene (Oracle, MSSQL og IBM's DB2) alle er kodet i C/C++ så er dette også et klart hint. Disse aktørene hadde hoppet over til Java umiddelbart om det hadde gitt signifikant bedre ytelse. Endret 31. oktober 2010 av Del

[doloop]

Sikkerhet my ass. Bankid har gitt meg så mange grå hår at jeg får lyst til å riste deg. Det eneste positive jeg ser med Java pr. i dag er at det holder .net på armlengdes avstand. Å la innhold på nett kontrolleres av et selskap som Oracle er galskap, litt mindre galskap enn å gi kontrollen til MS riktignok.

 

Jeg tror du mistforsto hva jeg mente med sikkerhet. Jeg snakket her ikke om kommunikasjonskryptering osv, men sikkerheten du kan føle med at koden din kjører likt på alle systemer. Altså suns WORA argument. Dette er en garanti du ikke har med feks c++.

 

Eksempeler

Argumentrekkefølgen er uspesifisert

#include <iostream>
int f() {
 std::cout << "In f\n";
 return 3;
}

int g() {
 std::cout << "In g\n";
 return 4;
}

int sum(int i, int j) {
 return i + j;
}

int main() {
 return sum(f(), g()); 
}

 

rekkefølgen f() og g() blir kalt opp er uspesifisert i c++, mens i java er den spesifisert

 

peker sammenligning

int main(void)
{
 int a = 0;
 int b = 0;
 return &a < &b;
}

 

resultat her er uspesifisert og dermed gjør at din kode kan oppføre seg forskjellig

 

Udefinert oppførsel

 

void f(void)
{
 char * p = "wikipedia"; // requires deprecated implicit conversion from const char[] to char*
 p[0] = 'W'; // undefined behaviour
}


int f(int x)
{
 return x/0; // undefined behavior
}


void f(void)
{
 int arr[4] = {0, 1, 2, 3};
 int * p = arr + 5; // undefined behavior
}

a[i] = i++;

 

resultat her er udefinert og opp til implementasjonen og bestemme og dermed gjør at din kode kan oppføre seg forskjellig

 

I java har du ikke slike usikkerhetsmomenter. De er selvfølgelig mulig å unngå i c++, men det krever høyere kompetanse av kodeforfatteren, og dermed høyere utviklingskostnad.

 

 

Maskinvareavhengihet

Flyttalls aritmetikk vil som et eksempel oppføre seg forskjellig på forskjellig maskinvare. Dets nøyaktighet vil være forskjellig og som følger ditt program vil være forskjellig. I java kan du spesifisere dette til alltid å oppføre seg likt (med tap av nøyaktighet på moderne CPUer for å være bakoverkompatible med gamle)

 

 

 

Dette er et argument for C og C++, ingen språk har rikere infrastruktur.

 

Sett deg inn i hva jeg sa her =)

 

Ellers vil jeg nevne at java er også det mest "populære" språket i dag og har vært i ganske lang tid. Det er ikke akkurat mangel på java kode der ute. Javas "infrastruktur" som du kaller det er enorm.

 

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

 

Tråder er noe herk også i Java. OpenMp funker greit, ellers er jeg glad i flere prosesser.

 

Du har tydligvis ikke prøvd Clojure, du trenger her ikke bry deg om deadlocks osv fordi logikken er bygget inn som standard. Det at den kjører som byte code i java gir java en kjempefordel.

 

Du har selvfølgelig en rekke andre språk som kjører i java. Feks scala, ruby, python, erlang og groovy etc

 

 

SQLite

Å porte kode fra et språk til et annet direkte vil sjeldent føre til ytelsesforbedring. Du må selvfølgelig designe programmet etter programmeringspåkets egenskaper.

 

Det er også lite vits å satse tungt på å utvikle et database svar på en eksisterende database, med mindre det er fordi du mener den har mangel som en branching ikke kan løse, eller at det går for tregt. Jeg har aldri hevdet java vil knuse c eller c++ i ytelse, jeg har ganske enkelt sakt at Java ikke henger etter. Det vil så å si aldri tjene seg å skrive et moderne program om kun for å endre plattform.

 

Hvilken mulig grunn ser du for å lage en ny implementasjon tilsvarende sqlite når en eksisterer i dag som ikke har problemer (innenfor hva den prøver å løse?

Endret 31. oktober 2010 av doloop

[Manuel]

resultat her er udefinert og opp til implementasjonen og bestemme og dermed gjør at din kode kan oppføre seg forskjellig

 

I java har du ikke slike usikkerhetsmomenter. De er selvfølgelig mulig å unngå i c++, men det krever høyere kompetanse av kodeforfatteren, og dermed høyere utviklingskostnad.

Problemer som dette skyldes utviklere som prøver å skrive så kryptisk kode at de fortjener å få en hundekjeks av Stroustrup. Men det er en bedre grunn til at nevnte eksempler ikke burde være et problem i praksis: Utvikler klarer å være disiplinert nok til å begrense antallet bieffekter per statement.

 

Det er ikke akkurat slik at det er mangel på snodig atferd som rammer alle som har lært seg Java; den vidstrakte bruken av "shallow copies", feilaktig sammenligning av strenger som "funker fint" siden JVM kan benytte seg av at strenger er uforanderlige og inneholder samme sekvens og mangel på multippel arv.

 

Førstnevnte er tydeligvis noe som går langt over hodet på mange av de som sammenligner ytelsen til Java-containere kontra STL-containere.

[Del]

Sikkerhet my ass. Bankid har gitt meg så mange grå hår at jeg får lyst til å riste deg. Det eneste positive jeg ser med Java pr. i dag er at det holder .net på armlengdes avstand. Å la innhold på nett kontrolleres av et selskap som Oracle er galskap, litt mindre galskap enn å gi kontrollen til MS riktignok.

 

Jeg tror du mistforsto hva jeg mente med sikkerhet. Jeg snakket her ikke om kommunikasjonskryptering osv, men sikkerheten du kan føle med at koden din kjører likt på alle systemer.

Jeg misforstod ikke. Bankid har vist at Java sin plattformuavhengighet er rimelig skjelven. Så lenge du holder deg til windows går det gjerne greit. OSX, linux, solaris etc. har vært sjansespill, for ikke å snakke om de forskjellige nettleserne.

Dette er et argument for C og C++, ingen språk har rikere infrastruktur.

 

Sett deg inn i hva jeg sa her =)

 

Ellers vil jeg nevne at java er også det mest "populære" språket i dag og har vært i ganske lang tid. Det er ikke akkurat mangel på java kode der ute. Javas "infrastruktur" som du kaller det er enorm.

 

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Jeg har satt meg inn i det du sa. Statistikken du referer til kan ikke oversettes i linjer kode, og dette er gjort klart i lenken. Det som derimot er viktigere er at Java av forskjellige årsaker ofte ender opp som stand-alone prosjekt med lite kodedeling. For meg som foretrekker åpen utvikling er Java en katastrofe, hvilket betyr at alle sitter på hver sin haug og koder opp de samme snuttene om og om igjen. Dette er forsåvidt ikke språket sin feil i seg selv, men det betyr at du finner en rikere verdikjede hos C og C++. Du kan også observere hvilken positiv betydning dette har hatt for Perl og nå har for Python.

Du har tydligvis ikke prøvd Clojure, du trenger her ikke bry deg om deadlocks osv fordi logikken er bygget inn som standard. Det at den kjører som byte code i java gir java en kjempefordel.

Clojure er et spennende prosjekt. Spent på å se om Lisp arven gjør terskelen litt høy for utviklere. Jeg så forsåvidt ikke på det som Java. Endret 31. oktober 2010 av Del

[doloop]

Problemer som dette skyldes utviklere som prøver å skrive så kryptisk kode at de fortjener å få en hundekjeks av Stroustrup. Men det er en bedre grunn til at nevnte eksempler ikke burde være et problem i praksis: Utvikler klarer å være disiplinert nok til å begrense antallet bieffekter per statement.

 

Ja jeg er helt enig det kan unngås men det krever kunnskap om alle disse udefinerte oppførslene. i=i++;

 

er ikke veldig kryptisk kode...

 

 

Det er ikke akkurat slik at det er mangel på snodig atferd som rammer alle som har lært seg Java; den vidstrakte bruken av "shallow copies", feilaktig sammenligning av strenger som "funker fint" siden JVM kan benytte seg av at strenger er uforanderlige og inneholder samme sekvens og mangel på multippel arv.

 

Førstnevnte er tydeligvis noe som går langt over hodet på mange av de som sammenligner ytelsen til Java-containere kontra STL-containere.

 

 

Er problemet at standard oppførsel er shallow copy? Jeg har ikke hørt argumentet at shallow copy fører til ytelsestap (logisk sett vil det jo føre til ytelesesøkning)? Det er også fint mulig å imlementere deep copy om du trenger dette, og du burde jo også kunne få IDEen til å genere disse for deg om det er noe du trenger mye av. Jeg har egentlig aldri støtt på problemer med dette, men kanskje det skyldes at jeg i hovedsak har kodet java og ikke har tenkt på det.

 

At java utnytter det at strings er immutable er vel strengt tatt ikke negativt, og kan faktisk la deg utføre (om kryptiske) ytelsesforbedringer =) Jeg ser dog poenget ditt at sammenligning av stringer kan forføre nybegynner til å mistforstå == operatoren, men dette er da i mye mindre grad enn c++ og dets høye terskel for å skrive god kode. Sannelig ikke noe jeg ville våge meg ut på, men jeg ser at muligheten er der.

 

 

 

Misforstå meg ikke, jeg nekter ikke for at en glimrende c++ utvikler(som det ikke er altfor mange av!) kan lage algoritmer som knuser de fleste andre språk på samme problem, men den faktiske nytten av dette er diskutabel. Det er ikke mange programmer som trenger slik ytelse til den kostnaden. I hovedsak vil slike programmer som krever denne typen ytelse være programmer som JVMen? Ikke akkurat noe de fleste selskaper trenge å bry seg om.