hvorfor skal ikke den vanlige personen i gata lenger få bruke delphi ?

[Giddion]

Når det gjelder java blir java kompilert til s.k. bytecode når du kompilerer programmet. Deretter blir bytecode kompilert videre til maskinkode når du kjører programmet i Java Virtual Machine. Dette medfører initielt en liten forsinkelse. Til gjengjeld kan JIT-kompilatoren produsere maskininstruksjoner som utnytter hver enste lille feature i akkurat den prosessoren programmet kjører på. Et program som er kompilert til maskinkode direkte vil måtte begrense seg til det minste felles multiplum av maskinkodeinstruksjoner som er tilgjengelig på de plattformene programmet er ment å kjøre.

 

Jupp dette var en for lang tråd til at jeg kan ikke holde meg ute lengere

 

Nå er det jo sånn at en JIT kompilator ikke kan ta seg tid til å utføre en alle de oppgavene en normal kompilator gjør og vil da i teorien ikke kunne produsere like optimal kode som andre kompilatorer.

 

Kode som kompileres direkte til maskinkode vil bare droppe støtte for nye fancye funksjoner i en cpu hvis man bruker en virkelig naiv implementasjon. Det er fult mulig å legge inn kode som skjekker hvilke funksjoner som er tilgjengelig og velge ulike møter å gjøre ting på.... siterer direkte fra delphi-feature-matrix.. Delphi 2010 har støtte for:

 

High performance x86 Assembler – 32-bit inline assembler supporting the Intel® x86 instruction

set (including Intel Pentium® Pro, Pentium III, Pentium 4, Intel MMX,TM SIMD, Streaming

SIMD Extensions, SSE, SSE2, SSE3, SSE 4.1, SSE 4.2, AMD SSE4A and AMD® 3DNow!®

Trenger jeg å skriver mer?

[GeirGrusom]

Programmet må rekompileres stadig for nye Delphi utgivelser for å holde tritt med utviklingen av prosessorer. For VM systemer så trengs det kun å oppdatere JIT-en. Samme gjelder 64-bit, hvor .NET programmer kan kompileres som "Any CPU" som gjør at programmet er 64-bit på 64-bit systemer, og 32-bit på 32-bit systemer. Delphi er utelukkende 32-bit.

[quantum]

Kode som kompileres direkte til maskinkode vil bare droppe støtte for nye fancye funksjoner i en cpu hvis man bruker en virkelig naiv implementasjon. Det er fult mulig å legge inn kode som skjekker hvilke funksjoner som er tilgjengelig og velge ulike møter å gjøre ting på.... siterer direkte fra delphi-feature-matrix.. Delphi 2010 har støtte for:

 

High performance x86 Assembler – 32-bit inline assembler supporting the Intel® x86 instruction

set (including Intel Pentium® Pro, Pentium III, Pentium 4, Intel MMX,TM SIMD, Streaming

SIMD Extensions, SSE, SSE2, SSE3, SSE 4.1, SSE 4.2, AMD SSE4A and AMD® 3DNow!®

Trenger jeg å skriver mer?

Hehe, begynner å nærme seg JIT dette jo :-)

 

Kan vel egentlig bare svare at det kun er de naive JIT-implementasjonene som hopper over kompileringstrinnene du nevner og håpe jeg har rett i dét :-P Begge tilnærminger medfører kompromisser, det tror jeg nok vi kan være enige om.

 

I praksis tror jeg nok det er andre ting som utgjør mere relevante forskjeller. F.eks. cpu-cycels brukt til søppeltømming, og minneforbruk generelt.

[zotbar1234]

I praksis tror jeg nok det er andre ting som utgjør mere relevante forskjeller. F.eks. cpu-cycels brukt til søppeltømming (...)

 

Du mener, siden for en rekke allokeringsmønstre er GC raskere enn eksplisitt deallokering?

[quantum]

I praksis tror jeg nok det er andre ting som utgjør mere relevante forskjeller. F.eks. cpu-cycels brukt til søppeltømming (...)

 

Du mener, siden for en rekke allokeringsmønstre er GC raskere enn eksplisitt deallokering?

Prøv et litt tungt Swing-gui så skjønner du hva jeg mener. Prøv å skrive en fullstendig setning så skjønner kanskje jeg hva du mener... :o)

[MailMan13]

High performance x86 Assembler – 32-bit inline assembler supporting the Intel® x86 instruction

set (including Intel Pentium® Pro, Pentium III, Pentium 4, Intel MMX,TM SIMD, Streaming

SIMD Extensions, SSE, SSE2, SSE3, SSE 4.1, SSE 4.2, AMD SSE4A and AMD® 3DNow!®

Trenger jeg å skriver mer?

Var dette så imponerende da?

 

Ikke en eneste 64-bit CPU.

 

Ingen instruksjonsett etter Pentium 4 tyder på at man ikke får tatt i bruk alle registerutvidelsene som kom med x86-64 heller. Enten er den listen ufullstendig, eller så er det noen ganske dramatiske mangler.

Nå er det jo sånn at en JIT kompilator ikke kan ta seg tid til å utføre en alle de oppgavene en normal kompilator gjør og vil da i teorien ikke kunne produsere like optimal kode som andre kompilatorer.

Det er nok litt "give and take" her. Den er begrenset av hvor mye tid den kan bruke, men til gjengjeld så har den også mulighet for mer spesifikke cpu-features, cache optimalisering og ting som in-lining av anonyme members og den slags som pre-komilert kode ikke gjør noe bra, om i det hele tatt.

Endret 1. februar 2010 av MailMan13

[zotbar1234]

Prøv et litt tungt Swing-gui så skjønner du hva jeg mener. Prøv å skrive en fullstendig setning så skjønner kanskje jeg hva du mener... :o)

 

Jeg ser ikke helt sammenhengen mellom tungt Swing-gui og GC.

[GeirGrusom]

Prøv et litt tungt Swing-gui så skjønner du hva jeg mener. Prøv å skrive en fullstendig setning så skjønner kanskje jeg hva du mener... :o)

GC skal da ikke påvirke ytelsen betraktelig. Faktisk så kan det være raskere, ettersom minne blir frigjort når det er nødvendig eller tid til det, fremfor når det står i programkoden at det skal skje.

GC er en ulempe for real-time programmer på grunn av den uforutsigbare oppførselen, men for normale programmer vil jeg hevde at det er en stor fordel.

[quantum]

Prøv et litt tungt Swing-gui så skjønner du hva jeg mener. Prøv å skrive en fullstendig setning så skjønner kanskje jeg hva du mener... :o)

GC skal da ikke påvirke ytelsen betraktelig. Faktisk så kan det være raskere, ettersom minne blir frigjort når det er nødvendig eller tid til det, fremfor når det står i programkoden at det skal skje.

GC er en ulempe for real-time programmer på grunn av den uforutsigbare oppførselen, men for normale programmer vil jeg hevde at det er en stor fordel.

GC tar noe tid, jobber du med fryktelig mye greier oppe i f.eks. netbeans, eller et annet Java IDE av noe kompleksitet - eneste eksemplet jeg har siden det er eneste klient-java-applikasjon jeg bruker interaktivt - vil du merke at programmet tar en bitteliten tenkepause innimellom for å tømme søppel.

 

«Noe», f.eks. søppeltømming, blir ikke raskere om det skjer på et «annet» tidspunkt, det blir bare mer eller mindre forstyrrende. Mulig det går an å tune noen gc-parametre, dersom man synes det er plagsomt, jeg syns memory-leaks er langt værre.

 

Edit: Nå kan det vel diskuteres hva som er «normale programmer», men jeg vil vel egentlig hevde at java desktopapplikasjoner ikke er helt «normale», java brukes (etter min mening) best (eller ihvertfall mest) på tjeneren. Der er også gc minimalt forstyrrende siden det forsvinner i asynkronitet, latency, krøll på hyssingen og annet. Skal man lage en desktopapplikasjon som virker maksimalt responsiv kan man nettopp dra nytte av kontrollen over når minne-opprydning skal skje i programkoden. Men manuell minnehåndtering krever at man holder tunga rett i munnen, man risikerer minnelekkasjer, og det øker ikke akkurat responsiviteten det heller. Dessuten er det etter min mening meningsløst arbeid iom. at automatisk søppeltømming stort sett fungerer mer enn bra nok.

Endret 1. februar 2010 av quantum

[zotbar1234]

GC tar noe tid (...)

 

Det er veldig applikasjonsavhengig. For en rekke allokeringsmønstre er GC raskere enn manuell deallokering.

[quantum]

Prøv et litt tungt Swing-gui så skjønner du hva jeg mener. Prøv å skrive en fullstendig setning så skjønner kanskje jeg hva du mener... :o)

 

Jeg ser ikke helt sammenhengen mellom tungt Swing-gui og GC.

Neivel. De Swing-applikasjonene jeg bruker til daglig har et brukbart komplekst gui. Dette medfører at søppeltømminga blir litt omstendelig. I tillegg har applikasjonene, f.eks. JDeveloper eller Netbeans, ganske store fotspor når man åpner litt komplekse prosjekter med mange biblioteker, plugins osv. Resultatet er at man opplever et lite «zombie-moment» i ny og ne når søpletømminga finner sted.

 

Nå er jeg spent på om du også har et poeng?

 

GC tar noe tid (...)

 

Det er veldig applikasjonsavhengig. For en rekke allokeringsmønstre er GC raskere enn manuell deallokering.

Generelt er det aldri noe vanskelig å finne en langsommere metode/algoritme. Er dét poenget ditt? Eller er det at ikke alle applikasjoner er like?

Endret 1. februar 2010 av quantum

[zotbar1234]

Neivel. De Swing-applikasjonene jeg bruker til daglig har et brukbart komplekst gui. Dette medfører at søppeltømminga blir litt omstendelig.

 

Jeg ser ikke helt hvorfor nettopp komplisert gui skal medfører omstendelig gc.

 

 

GC tar noe tid (...)

 

Det er veldig applikasjonsavhengig. For en rekke allokeringsmønstre er GC raskere enn manuell deallokering.

Generelt er det aldri noe vanskelig å finne en langsommere metode/algoritme.

 

Poenget her var at automatisk gc var raskere enn manuell. Klarere nå?

[quantum]

Jeg ser ikke helt hvorfor nettopp komplisert gui skal medfører omstendelig gc.

Mener du virkelig at søppeltømming er O(1)?

Poenget her var at automatisk gc var raskere enn manuell. Klarere nå?

Nei, hvor står det? Du må nesten komme med en referanse hvor dette slås kategorisk fast.

[zotbar1234]

Jeg ser ikke helt hvorfor nettopp komplisert gui skal medfører omstendelig gc.

Mener du virkelig at søppeltømming er O(1)?

 

Hvor kom O(1) fra? "ikke omstendelig" er ikke ekvivalent med O(1).

 

Men når vi først er inne på O(1) -- enhver variasjon av SemiSpace collector, der nesten ingen objekter er live i det neste runde med gc starter vil være nesten O(1). Det kombinert med oppdeling av heap i generasjoner har gitt svært gode resultater.

 

Poenget her var at automatisk gc var raskere enn manuell. Klarere nå?

Nei, (...)

 

Hvilken del er uklar?

 

(...) hvor står det?

 

Det står flere steder.

 

- "Myths and realities: the performance impact of garbage collection", av Blackburn, Cheng og McKinley

- "Reconsidering custom memory allocation" av Berger, Zorn og McKinley

- "Garbage collection can be faster than stack allocation" av Appel

 

... er bare noen få eksempler.

 

Du må nesten komme med en referanse hvor dette slås kategorisk fast.

 

"Kategorisk" finnes ikke her, siden (slik påpekt allerede), oppførselen til gc avhenger av allokeringsmønstrene til programmet. Hvorvidt gc vil koste mindre, omtrent samme, eller mer enn eksplisitt deallokering avhenger av programmet. Det er, mao, ikke slik at gc => programmet går tregt, selv om det omtrent alltid var slik på 70-tallet. Dette var poenget mitt.

[sinnaelgen]

kan jeg (som er uvitende ) få en forklaring på begrepene GC og O(1) ?

[zotbar1234]

kan jeg (som er uvitende ) få en forklaring på begrepene GC og O(1) ?

 

GC, O(1)

[quantum]

kan jeg (som er uvitende ) få en forklaring på begrepene GC og O(1) ?

GC = Garbage Collection. Det fins veldig mange bedre forklaringer på gc enn det jeg kommer med nå. Kort fortalt; Dersom du allokerer en objektinstans, f.eks. med new Person() i Java, så vil minnet denne instansen opptar bli automatisk gjenbrukt til andre formål, hvis det viser seg at du ikke trenger den lengre. Et naivt eksempel følger:

 

Person newPerson = new Person();
newPerson.setName("Odd");
business.store(newPerson);

 

Nå er newPerson lagret i databasen, så vi trenger ikke den mere. I noen språk ville man nå eksplisitt måttet deallokere minnet som newPerson refererer til, mens i f.eks. Java vil jvm'en oppdage at objektet newPerson refererer til ikke er referert til av andre referansevarialbe, og frigjøre minnet automatisk når referansen går ut av scope (dvs. i realiteten når gc-prosessen kjøres).

 

O(1) betyr konstant eksekveringstid uansett hvor mye oppgavens kompleksitet øker. Det er få algoritmer som er velsignet med denne egenskapen, gc er ikke blant dem ... O(n) er å telle sauer, jo flere sauer, jo lengre tid ... n sauer tar n tid å telle.

 

Hvis du vil vite mer om dette så anbefaler jeg å ta en runde på wikipedia/google, der finner du mye bedre forklaringer enn her. Se http://en.wikipedia.org/wiki/Big_Oh_notation

[quantum]

Hvorvidt gc vil koste mindre, omtrent samme, eller mer enn eksplisitt deallokering avhenger av programmet. Det er, mao, ikke slik at gc => programmet går tregt, selv om det omtrent alltid var slik på 70-tallet. Dette var poenget mitt.

Det var vel knappest noen bombe. Det meste går saktere enn, like fort som, eller raskere enn ... det meste.

 

Pointet her var vel at ts gjerne ville fortsette med pascal for å unngå jit (og gc?), og så har vi tilbakevist at han har noe særlig å tjene på det?

 

Merkelig at du ikke ser sammenheng mellom et komplekst swing-gui og tilsvarende utfordring for søppeltømminga ... men alle kan ikke se alt, godnatt.

[zotbar1234]

Det var vel knappest noen bombe. Det meste går saktere enn, like fort som, eller raskere enn ... det meste.

 

Det får være din konklusjon. Min konklusjon var noget mer spesifikt.

 

Men hvis det var knappest en bombe, hvorfor overraskelsen ifm. at gc gjorde det bedre enn eksplisitt deallokering?

 

Merkelig at du ikke ser sammenheng mellom et komplekst swing-gui og tilsvarende utfordring for søppeltømminga (...)

 

Opplys meg. Hva, spesifikt til komplekst swing-gui, gjør gc "omstendelig" (ift. alle andre typer allokeringsmønstre).

[GeirGrusom]

Et swing GUI lager da ikke spesielt mange objekter... Det skal heller ikke være vanskelig å slette det igjen fra minnet heller så jeg skjønner ikke hva som skal være så tregt med det...

Dessuten trengs ikke objektene nødvendigvis å slettes i det hele tatt (alt etter hvordan programmet fungerer)