Python vs. Java

[steingrim]

Eh, jo den kompilerer den, men den kompilerer den ikke til x86-maskinkode, den kompileres til et bytecode. Det er fortsatt KOMPILERING som jeg mistenker er zotbar1234s poeng.

 

Men siden jeg kjenner hr Zotbar privat vet jeg at han kan mer om kompilatorteknikk enn alle oss til sammen, så jeg kan være forutinntatt

[NevroMance]

Hmm... Trudde både python og perl var rene interpreta språk, vanligvis, men lærte noe nytt nå når jeg så på wikipedia:

 

http://en.wikipedia.org/wiki/Interpreted_language

 

Så da gir jeg meg på den.

 

Men nå vil jeg fortsatt si at python ikke egner seg til store, regnekrevende beregninger. Da er nok java bedre, selv om det også er langt fra optimalt. Når python blir kompilert og kjørt "samtidig" gjør det at språket er en del tregere enn språk som er kompilert først og så kjøres.

 

Hvis du forresten virkelig vil ha et raskt språk for å gjøre slike beregninger kan du se litt nærmere på Fortran. Ikke et spesielt koselig språk, men veldig raskt til slike beregninger.

[GeirGrusom]

edit: note to self: slutt å skrive poster her etter en fylletur.

 

Jeg er som kjent enig med NevroMance.

 

Hvis zotbar kan mye om kompilatorteknikk hadde det vært fint om han viste det bedre. Ved å ikke vite hvordan void* brukes i C og hvordan compileren behandler det, setter en ikke et bra eksempel.

 

Men Python kan være et fint språk det, men jeg mener bare at språk som er laget for native code er bedre til krevende prosesser som visualisering kan være i mange tilfeller.

 

That is all.

Endret 19. desember 2008 av GeirGrusom

[steingrim]

edit: note to self: slutt å skrive poster her etter en fylletur.

Nei, nei, ikke slutt med det

Men Python kan være et fint språk det, men jeg mener bare at språk som er laget for native code er bedre til krevende prosesser som visualisering kan være i mange tilfeller.

Jeg kan null og niks om visualisering, men jeg vet at Python er veldig populært til tunge beregninger i forsknings-Norge. Grunnene er NumPy og at det er så latterlig enkelt å skrive utvidelser i C og Fortran. Dermed får man det beste fra to verdener!

[NevroMance]

NumPy er et bra bibliotek ja, grunnen til at det faktisk er så raskt er jo også fordi det er et bibliotek skrevet i C. Hvis du bruker en C/Fortran utvidelse til python er det selvsagt brukbart til simuleringer osv, men da er det C/Fortran som regner ut, ikke python. Python sin styrke ligger nemlig i det at det er mulig å skrive utvidelser, den enkle syntaxen, filbehandling osv. men selve simuleringen burde en bruke et annet språk for å kjøre. Eller NumPy hvis du fortsatt vil tro du lar python gjøre hele jobben:P

 

Største problemet med sånne utvidelser er jo også at en må skrive et mellomlag som sender data fra python til C, siden python er dynamisk typet. Kan innimellom gi litt unødvendig mye jobb for lite ytelsesboost, da et kall fra python til C er kostbart.

[teflonpanne]

Som jeg har sagt før vil parallellisering være viktig framover med prosessorer med mange kjerner. Da egner (rene) funksjonelle språk seg særdeles godt pga. mangel av sideeffekter. Et ganske kult eksempel på det er coconut, eller code constructing user tool, som er et verktøy skrevet i haskell for cell-prossesoren i playstation 3. Det er et dsl hvor man skriver en sær blanding av haskell og domene spesifikt funksjonell assembly, men resultatet er kode som er 4 ganger raskere enn C på de områdene han har benchmarket. Du kan se en google talk av det her:

 

Jeg tror også dette er noe man kan laste ned et sted, så de som har playstation 3 (og de uten, mener det fins en emulator for det også) kan installere linux på den og leke seg med dette.

 

Og nå kom jeg på at dette var en tråd om java vs python, så uh, det var kanskje litt off topic. Men on topic, siden ingen av språkene egner seg spesielt bra til raske numeriske beregninger hadde jeg helt klart valgt python fordi man uansett bare kan prototype eller må interface mot c allikevel.

[zotbar1234]

Påstandene mine er ikke uriktige bare fordi du ikke forstår hva jeg mener.

 

Du påstod at kompilering av pythonkoden er klønete. Som vist gjentatte ganger er dette feil.

 

Du påstod videre at kompilering av skriptspråk er problematisk, siden bl.a. datatypene følger objektene heller enn variablene som peker på/refererer til objektene. Som vist er dette også feil.

 

Til slutt lirte du av deg denne perlen -- "å bruke Python til å skrive store omfattende ressurskrevende programmer kan være uheldig for sluttbrukeren", uten at du legger frem noe som helst objektiv, tallfestet begrunnelse på hvorfor det er tilfellet.

 

GeirGrusom, dine uriktige påstander begynner å bli slitsomme. Enten har du tall som underbygger dem (og da legg dem frem), eller slutt å tviholde på stråmenn, innrømm at du har gjort en feil, og beveg deg videre.

 

Men det at du skriver ned den kommandolinja der får meg til å tro at du er helt på jordet når det gjelder hva jeg snakker om.

 

*Slutt* å komme med feilaktige påstander, GeirGrusom. Det begynner å bli slitsomt å poengtere feil i dem. Denne sier rimelig klart at "python foo.py" vil kompilere en pythonfil til bytekoden (bytekoden ville ikke være lagret, men det er helt uinteressant).

 

edit:

Du visste ikke hvordan en behandler void* datatyper i C,

 

Fordi du sporer av i en monolog om hva en kompilator kan/ikke kan gjøre med en void*, betyr ikke at motdebattantene dine ikke vet hvordan en void* datatype (altså, en peker) behandles i C. Hvor i debatten har jeg demonstrert mangel på kunnskap om hvordan void* behandles av en kompilator i C?

 

du viser ingen forståelse for hvordan Python eller andre språk kompileres til forskjellige nivåer (det virket ikke som om du er klar over hva python byte code er engang) (...)

 

Tillatt meg å gjenta det jeg allerede skrev i tidligere innlegg:

 

* Pythonkildekoden kompileres av CPython. Den kompileres til bytekoden i utgangspunktet.

* Pythonkildekoden kan videre kompileres til maskinkoden på noen arkitekturer (f.eks. vha. psyco).

 

Men neida, *du* hevdet jo at kompilering av Python er klønete. Er det derfor jeg viser ingen forståelse for hvordan Python kompileres til forskjellige nivåer?

 

(...) du skriver ned en kommandolinje for å starte et python script som er 101% irrelevant for diskusjonen.

 

Dette er bare så vakkert. Du anklager meg for å demonstrere manglende forståelse, men du mener at et eksempel på kompilering av Pythonkoden er 101% irrelevant. Fakta som motbeviser dine påstander er altså irrelevante nå? (hint: når du er ferdig med å fakturere meg, kan du jo tenkte litt over at CPython vil kompilere en vilkårlig py-fil til bytekoden og i noen tilfeller vil denne bytekoden lagres eksplisitt på filsystemet (test "import foo" i bar.py, gitt en pythonfil "foo.py". Ser du en foo.pyc? Hva tror du *den* inneholder?)

 

Mitt argument var at Python ikke alltid er tilstrekkelig til alle oppgaver når det gjelder visualisering. Helt tilfeldigvis så er det akkurat 3D grafikk og slikt jeg jobber mest med for tiden, og jeg vet hva som kreves.

Hvilken implementasjon av Python som brukes er egentlig irrelevant, av to grunner:

- 99% av alle som bruker Python bruker CPython

- CPython er referanseimplementasjonen og standarden på språket, som andre compilere må føye seg etter, og denne definisjonen mangler noen ting som kan være kritisk når det gjelder ytelse for behandling av svært store datamengder på svært kort tid.

 

OK? dette er argumentene mine summert opp i to forholdsvis korte linjer.

 

Men hvordan ble det med klønete kompilering av Pythonkoden? Dette er *dine* ord. For at nettopp det var din opprinnelige innvending. Hadde du skrevet "Python ikke alltid er tilstrekkelig til alle oppgaver når det gjelder visualisering", ville det ikke ha vært noe å protestere på (fordi det er riktig -- intet språk er tilstrekkelig når det gjelder visualisering (eller noen andre passe store og generelle emner)).

 

Du nevnte for eksempel at en kan skrive utvidelser i C for å gjøre krevende oppgaver, som er et argument jeg aksepterer, og som du burde forsøkt å fremheve bedre.

 

Ikke verst. Det er altså min feil? Jeg blir fasinert for hvert nye innlegg som kommer av deg. Du våger å skjelle meg ut og så henger det på *meg* at jeg ikke var tydelig nok, enda jeg nevnte C som et alternativ fra starten av. Where do you get off...

 

Istedet har du prøvd å angripe mine argumenter (...)

 

Ja, det er det som pleier å skje med argumentene i en debatt. Er de gode (hint: tall og verifiserbare fakta), greier de å stå på sine egne bein uten at du trenger å bruke mer tid på det.

 

(...) og få meg til å kaste bort masse tid på å forklare deg ting du burde ha visst eller forstått før du kastet deg ut i dette.

 

Et øyeblikk, når jeg skrev at jeg slo opp slike ting i en bok, ba du meg om å slutte med det og begynne å lese det du skrev selv. Hva er det du *egentlig* vil?

 

Jeg har nesten lyst til å fakturere deg for det.

 

Ah, det er altså det du vil. Du er velkommen til å forsøke deg på det, såsnart du har forklart hva du skal få betalt for. PM for adresse- og kontoinformasjon.

[zotbar1234]

Når python blir kompilert og kjørt "samtidig" gjør det at språket er en del tregere enn språk som er kompilert først og så kjøres.

 

Følg med i timen, er du snill. Et språk er aldri tregere enn et annet språk. Det er vel ikke så vanskelig å få med seg?

[NevroMance]

Når python blir kompilert og kjørt "samtidig" gjør det at språket er en del tregere enn språk som er kompilert først og så kjøres.

 

Følg med i timen, er du snill. Et språk er aldri tregere enn et annet språk. Det er vel ikke så vanskelig å få med seg?

 

Hva skal en si da? Numerisk utregning av et enkelt integral i python vs. java viser at det tar lenger tid i python med standard implementasjon enn med java, dette er fordi løkker i python bruker lenger tid enn løkker i java.

 

Om det er kompilatoren eller hva det er som gjør at det bruker lenger tid på utregningene er stort sett ganske likegyldig. Når en, i teorien lik, implementasjon av et problem i to forskjellige språk ikke bruker ca. lik tid ved gjentatte kjøringer vil de fleste si at det språket som bruker lengst tid er tregere enn det som bruker kortest tid. Selvsagt ved bruk av standard kompilatorer.

 

Jeg kan fint lite om kompilatorteknikk, derfor bruker jeg uttrykk personer som ikke har kjennskap til kompilatorteknikk bruker.

[Mr.Garibaldi]

Slik jeg leser han sier han at et språk ikke har en hastighet, og således ikke kan være raskere eller tregere enn ett annet, men at det er implementasjonen av språket som varierer.

[zotbar1234]

Følg med i timen, er du snill. Et språk er aldri tregere enn et annet språk. Det er vel ikke så vanskelig å få med seg?

 

Hva skal en si da?

 

At implementasjon A av språk S er raskere enn implementasjon B av språk T for den gitte oppgaven.

 

Om det er kompilatoren eller hva det er som gjør at det bruker lenger tid på utregningene er stort sett ganske likegyldig. Når en, i teorien lik, implementasjon av et problem i to forskjellige språk ikke bruker ca. lik tid ved gjentatte kjøringer vil de fleste si at det språket som bruker lengst tid er tregere enn det som bruker kortest tid. Selvsagt ved bruk av standard kompilatorer.

 

For det første, standardkompilatorer? C har f.eks. *ingen* standardkompilator (selv om man kunne kanskje ønske seg en referanseimplementasjon).

 

For det andre, det gir ikke mening å sammenligne hastigheten på løkker i språk A vs. språk B. Det eneste man kan sammenligne er disse løkkene slik de blir realisert i en spesifikk implementasjon. Årsaken til at språksammenligning ikke gir mening, er at det ikke finnes noe sammenligningsgrunnlag hva hastighet angår på språknivå. Man kan snakke om hvor lang tid en sekvens med instruksjoner (maskin- eller bytekode) tar, men ikke hvor lang tid en gitt språkkonstruksjon tar.

 

For det tredje har folk en lei tendens til å glemme med det med "tilsvarende" kontruksjoner. En løkke som teller opptil en viss brukeroppgitt grense er langt mindre triviell enn man skulle i utgangspunktet antatt. Skulle man skrive den tilsvarende koden for Java og Python, ville man ha måtte gå over til BigInteger i Java. Det å kartlegge nøyaktig hva tilsvarende betyr er mao. ikke alltid rett frem.

 

Videre gir det ikke mening å sammenligne tilsvarende konstruksjoner i forskjellige *språk*, siden for et gitt språk har man gjerne implementasjoner som kan variere i en veldig stor grad i kvalitet på den genererte koden såvel som valg av koden man kompilerer kildekoden til. Det vil gi lite mening å sammenligne tolkning av Java bytekode vs. x86 maskininstruksjoner generert for den tilsvarende Pythonkoden, selv i en såpass triviell situasjon som en løkke.

 

Og selv om et språk har egenskaper som stiller krav til runtimesystemet som man i utgangspunktet skulle trodd kostet mer tid og ressurser, er det langt i fra sikkert hva et konkret tilfellet med en gitt implementasjon skulle ende opp med. Favoritteksempelet mitt er garbage collection -- av og til er det raskere å la runtimesystemet rydde enn å bruke manuell allokering/frigjøring.

 

Moralen er altså, sammenlign det som kan sammenlignes. Epler med epler, implementasjoner med implementasjoner.

[NevroMance]

Jaja, når implementasjonen av et språk som regel blir sett på som det samme som språket selv (Klag så mye du vil på det, men programmerere som ikke driver med kompilatorteknikk sier faktisk at et språk er tregt, ikke en implementasjon) vil jeg si at det er lov å kalle et språk tregt.

 

Men synes egentlig hele den diskusjonen burde droppes, da det er veldig OT i forhold til sprørsmålet i første posten. Hvis du fortsatt vil krangle og klage på våre manglende kunnskaper om kompilatorer (Ja, jeg kan ca. 0 om kompilatorer og innrømmer det) burde du heller lage en egen tråd om det. For min del er diskusjonen ferdig med konklusjonen at du vet mye mer om kompilatorer enn meg, at du er ekstremt kranglete av deg og at jeg fortsatt kommer til å kalle et språk tregt, sorry, men orker rett og slett ikke ta meg selv og kompilatorer så høytidelig at jeg velger å si:

At implementasjon A av språk S er raskere enn implementasjon B av språk T for den gitte oppgaven.

[zotbar1234]

Jaja, når implementasjonen av et språk som regel blir sett på som det samme som språket selv

 

Det er overhodet ingen grunn til å sette dette likhetstegnet.

 

(Klag så mye du vil på det, men programmerere som ikke driver med kompilatorteknikk sier faktisk at et språk er tregt, ikke en implementasjon) vil jeg si at det er lov å kalle et språk tregt.

 

Det er lov å kalle jorden flat. Men slike utsagn demonstrerer kun at man misforstår hva man uttaler seg om.

[GeirGrusom]

Slik jeg leser han sier han at et språk ikke har en hastighet, og således ikke kan være raskere eller tregere enn ett annet, men at det er implementasjonen av språket som varierer.

 

Tja, men dette er dog heller ikke helt riktig.

 

En implementasjon blir begrenset av språket, og hastigheten til et språk som ikke støtter statiske datatyper vil også nødvendigvis bli begrenset av dette sammenlignet med språk som gjør det.

[NevroMance]

Det er lov å kalle jorden flat. Men slike utsagn demonstrerer kun at man misforstår hva man uttaler seg om.

 

Og det har jeg sagt flere ganger, jeg kan absolutt null om kompilatorteknikk, når jeg skal anbefalle et språk for slike beregninger som i denne tråden, går jeg veldig fort for fart. Det at det finnes implementasjoner av python som er raskere enn implementasjoner av C er meg revnende likegyldig, da de fleste implementasjoner av C er raskere enn de fleste implementasjoner av python.

 

Men igjen, det her har sklidd way OT!

[cyclo]

GeirGrusom: Du drar frem argumenter som hastighet og "klønete" (hva nå enn det egentlig betyr - skulle gjerne sett en definisjon på klønete i denne forbindelse) kompilering. Samtidig sier du at java er det beste valget. Men burde du egentlig ikke anbefale C i så måte? For om det skal være gode argumenter er jo nødvendigvis java bare det beste av to onder...

[GeirGrusom]

GeirGrusom: Du drar frem argumenter som hastighet og "klønete" (hva nå enn det egentlig betyr - skulle gjerne sett en definisjon på klønete i denne forbindelse) kompilering. Samtidig sier du at java er det beste valget. Men burde du egentlig ikke anbefale C i så måte? For om det skal være gode argumenter er jo nødvendigvis java bare det beste av to onder...

 

Men med C må en bruke en hel masse tid på ting som ikke er direkte relevant til oppgaven, som minnebehandling.

 

Jeg mener at Java er middelveien i dette tilfellet.

[Dead_Rabbit]

Okey, nå har jeg ikke lest alle innleggene her, men jeg slenger ut min mening likevel. Språk som Python, Ruby, whatever er veldig fine språk. De har mye penere syntaks enn språk som Java, og er gjerne mer ekspressive. Pr. i dag ville jeg likevel gått for et språk som Java (jeg ville aldri gått for Java, men et språk i den duren der) for tyngre systemer, fordi dagens implementasjoner av Python & co ofte ikke gir like høy hastighet som Java & co. Jeg gleder meg til den dagen hvor Ruby er like raskt som det er pent, though.

 

Når det gjelder kompilering/kjøring og slikt, ser jeg ikke de helt store forskjellene.

[GeirGrusom]

Hehe jeg liker ikke egentlig Java jeg heller

 

Kanskje D hadde vært beste valget... men jeg må bare innse det, D kommer aldri til å bli noe stort dessverre.

Endret 20. desember 2008 av GeirGrusom