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

[quantum]

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).

 

Du forstår at søppeltømming ikke er O(1), men ikke at det jevnt over tar lengre tid å rydde i en stor/kompleks datastruktur enn i en liten/simpel datastruktur?

 

Når det gjelder gc vs. andre «deallokeringsmønstre» så er det en diskusjon du har med deg selv, og det må du gjerne fortsette med, jeg lever fint med at du er veldig uenig i et eller annet jeg ikke har hevdet.

[quantum]

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)

Det som kjennetegner et KOMPLEKST Swing-GUI er vel nettopp at det «lager» SPESIELT mange objekter sammenlignet med et enkelt Swing-GUI. Og ofte er det sånn at GUI-kompleksiteten gjenspeiler kompleksiteten i andre datastrukturer i programmet. Dét, og det faktum at de fleste Swing-GUI'er er ment å være interaktive, gjør at brukeren kan oppleve at søppeltømming faktisk tar tid. Derfor påstår jeg at effektiv gc-implementasjon er vel så viktig som effektiv jit-implementasjon dersom man ønsker et gui som oppleves som responsivt (i betydningen «ikke tar seg en gc-lur i ny og ne»). Og det er tydeligvis for enkelte en ufattelig kontroversiell påstand ...

[GeirGrusom]

Vel, søppeltømming er ikke O(1) men kan være mer effektivt enn eksplisitt deallokering, fordi data kan slettes og minneområde kan ryddes opp uten at engang noen deallokering skjer.

Det er derfor referanser i java eller .NET ikke kan oversettes til pekere, fordi GC kan, og vil flytte rundt på objekter for å få plass til andre ting. Dette fører til at en allokering kan være nær sagt gratis (øke stackpekeren) sammenlignet med et system som ikke bruker GC.

 

Søppeltømming i ettertid kan utføres når det trengs (eller ikke i det hele tatt) og ikke når programmet ber om det. Derfor kan "dynamisk" GC være mer effektiv enn "statisk" GC, både fordi allokering kan være langt billigere, og opprydding skjer når det trengs, asynkront med hovedprogrammet.

 

edit: hvis Swing fører til massiv GC tid, så er det noe galt med Swing ville jeg tro... Jeg har veldig lite erfaring med Java, så jeg skal dog ikke uttale meg noe om det.

Endret 2. februar 2010 av GeirGrusom

[quantum]

...

Gc vs. alt mulig annet må du nesten ta opp med hr. zotbar.

 

Forøvrig er det vel ikke noe galt hverken med Swing eller Java generelt om «massive» datastrukturer fører til «massivt» forbruk av cpu-cycler til gc ... med kraftig forbehold om at jeg ikke aner hva du legger i «massivt».

[GeirGrusom]

Mine ord fra ditt innlegg ^^

Poenget er at det skal en del til før GC-en faktisk får såpass stor hikke at brukeren kan merke det.

[quantum]

Mine ord fra ditt innlegg ^^

Poenget er at det skal en del til før GC-en faktisk får såpass stor hikke at brukeren kan merke det.

«En del» er jo også et litt flytende begrep. Men dette kan som sagt noen ganger være merkbart, og det «bekrefter» da fordommene folk eventuelt har mot automatisk gc, nettopp fordi de faktisk kan merke at det forekommer en liten forsinkelse. Tror til og med jeg har brukt programmer hvor teksten "Garbage collecting ..." kommer opp på statuslinja, nærmest bare for å gni det inn ...

[GeirGrusom]

Hehe. Vel, jeg har aldri opplevd det, men på en annen side har jeg heller ikke aktivt sett etter det heller.

Er jo mulig å gjøre undersøkelser på dette, men jeg tror ikke jeg gidder å legge inn så mye arbeid kun for et off-topic innlegg.

[zotbar1234]

Du forstår at søppeltømming ikke er O(1), men ikke at det jevnt over tar lengre tid å rydde i en stor/kompleks datastruktur enn i en liten/simpel datastruktur?

 

Kunne du ta en titt i "Garbage collection" av Jones og Lins før vi fortsetter? Siden størrelsen på datastrukturen er uinteressant for en rekke gc-strategier.

 

Når det gjelder gc vs. andre «deallokeringsmønstre» så er det en diskusjon du har med deg selv, og det må du gjerne fortsette med, jeg lever fint med at du er veldig uenig i et eller annet jeg ikke har hevdet.

 

<teskjemodus>Poenget, atter en gang, var å belyse det enkle faktum at ytelsen til gc (såvel som eksplisitt deallokering, forøvrig) er svært avhengig av deallokeringsmønstrene til programmet</teskjemodus>.

[Giddion]

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?

Vel det får du vurdere selv, det var ikke mitt poeng å imponere, det var lett tilgjengelig dokumentasjon.

 

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.

Vel hvis det ikke hadde vært noen instruksjonsett etter pentium4 i listen så hadde du hatt rett,.... men faktumet er noe annet.

 

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.

Vel jeg kan ikke utale meg om hvor godt 'pre-kompilert' programmer er optimalisert i forholdt til jit, jit har vel en bedre mulighet, men om den muligheten blir utnyttet er noe annet.

 

Beklager at sitatet under er tatt litt ut av konteksten (snakkes om pre-kompilert vs jit)

<snip>

Begge tilnærminger medfører kompromisser, det tror jeg nok vi kan være enige om.

Helt enig, og det er veldig viktig å huske på .

[quantum]

Du forstår at søppeltømming ikke er O(1), men ikke at det jevnt over tar lengre tid å rydde i en stor/kompleks datastruktur enn i en liten/simpel datastruktur?

 

Kunne du ta en titt i "Garbage collection" av Jones og Lins før vi fortsetter? Siden størrelsen på datastrukturen er uinteressant for en rekke gc-strategier.

 

<teskjemodus>Poenget, atter en gang, var å belyse det enkle faktum at ytelsen til gc (såvel som eksplisitt deallokering, forøvrig) er svært avhengig av deallokeringsmønstrene til programmet</teskjemodus>.

 

Jeg vil råde deg til å ikke holde pusten mens du venter på at jeg skal lese bibelen. For f.eks. copy collecting spille størrelsen på live-minne en rolle for ytelsen (http://www.memorymanagement.org/articles/recycle.html), og denne strategien er i bruk i Java. Java har også generasjonsbasert søppeltømming, hvor hele poenget jo er å unngå å måtte scanne og behandle hele minnet hver gang, selvfølgelig fordi det tar lengre tid enn å scanne og behandle bare en del av minnet, som jo nødvendigvis da er en mindre datastruktur enn hele minnet er.

 

Jeg velger å tro at Suns implementasjon av ulike søppeltømmingsalgoritmer og justeringsparametre faktisk er motivert av en reell problemstilling, nemlig at ulike applikasjoner og ulike bruksmønstre rett og slett krever det for at ytelsen skal bli akseptabel, etter de formodentlig reelle forventningene og kravene brukerne av Java har. Jeg velger derfor å opprettholde min ufattelig provoserende påstand, nemlig at en god gc-implementasjon er vel så viktig som god jit.

[zotbar1234]

Jeg vil råde deg til å ikke holde pusten mens du venter på at jeg skal lese bibelen.

 

Hva i alle dager har kristent hatpropaganda i denne debatten å gjøre? Og hvorfor skulle jeg vente på det?

 

For f.eks. copy collecting spille størrelsen på live-minne en rolle for ytelsen (http://www.memorymanagement.org/articles/recycle.html), (...)

 

Ja, live-minne. Du skrev derimot "jevnt over [tar det] lengre tid å rydde i en stor/kompleks datastruktur enn i en liten/simpel datastruktur?" -- ser du forskjellen nå, eller skal jeg utheve? (tips: stor allokert datastruktur impliserer ikke stor live datastruktur).

 

Og nok en gang, hva, spesifikt for stort Swing-gui gjør at gc blir omstendelig?

 

(...) Jeg velger derfor å opprettholde min ufattelig provoserende påstand, nemlig at en god gc-implementasjon er vel så viktig som god jit.

 

Når ble denne påstanden provoserende?

[quantum]

Hva i alle dager har kristent hatpropaganda i denne debatten å gjøre? Og hvorfor skulle jeg vente på det?

 

Dette var ditt forslag, jeg har desverre ingen formening om hva hensikten skulle være.

 

Ja, live-minne. Du skrev derimot "jevnt over [tar det] lengre tid å rydde i en stor/kompleks datastruktur enn i en liten/simpel datastruktur?" -- ser du forskjellen nå, eller skal jeg utheve? (tips: stor allokert datastruktur impliserer ikke stor live datastruktur).

 

Som du selv påpeker skrev jeg stor datastruktur og liten datastruktur, ikke allokert datastruktur.

 

Og nok en gang, hva, spesifikt for stort Swing-gui gjør at gc blir omstendelig?

 

Blant annet størrelsen på datastrukturen copy collectoren må forholde seg til.

 

Når ble denne påstanden provoserende?

 

Igjen, det må nesten du svare på. Selv om det kanskje er like greit at du ikke gjør det.

[zotbar1234]

Hva i alle dager har kristent hatpropaganda i denne debatten å gjøre? Og hvorfor skulle jeg vente på det?

 

Dette var ditt forslag, jeg har desverre ingen formening om hva hensikten skulle være.

 

"bibel" var dine ord, ikke mine. Dermed, hva har bibelen med saken å gjøre?

 

Ja, live-minne. Du skrev derimot "jevnt over [tar det] lengre tid å rydde i en stor/kompleks datastruktur enn i en liten/simpel datastruktur?" -- ser du forskjellen nå, eller skal jeg utheve? (tips: stor allokert datastruktur impliserer ikke stor live datastruktur).

 

Som du selv påpeker skrev jeg stor datastruktur og liten datastruktur, ikke allokert datastruktur.

 

Ah, så stor datastruktur betyr nå stor live datastruktur hos deg. Veldig interessant. Er det noen andre egne definisjoner du har introdusert? (nyttig å vite for å unngå misforståelser i framtiden).

 

Og nok en gang, hva, spesifikt for stort Swing-gui gjør at gc blir omstendelig?

 

Blant annet størrelsen på datastrukturen copy collectoren må forholde seg til.

 

Størrelsen på datastrukturen er ikke et Swing-spesifikt aspekt. Jeg spør nok en gang, hva gjør at gc av stort Swing-gui blir omstendelig?

 

Når ble denne påstanden provoserende?

 

Igjen, det må nesten du svare på. Selv om det kanskje er like greit at du ikke gjør det.

 

Jeg skal svare på hva du mente med dine utsagn? Skal dette være en dårlig vits?

 

"provoserende" var et begrep du introduserte her. Jeg vet ikke hvorfor. Ej heller har jeg mulighet til å vite hvorfor du valgte å beskrive påstanden som provoserende.

 

Så, hvorfor gjorde du det? Spesifikt hva er provoserende med "(...) gc-implementasjon er vel så viktig som god jit"?

[quantum]

Hva i alle dager har kristent hatpropaganda i denne debatten å gjøre? Og hvorfor skulle jeg vente på det?

 

Dette var ditt forslag, jeg har desverre ingen formening om hva hensikten skulle være.

 

"bibel" var dine ord, ikke mine. Dermed, hva har bibelen med saken å gjøre?

 

Ja, live-minne. Du skrev derimot "jevnt over [tar det] lengre tid å rydde i en stor/kompleks datastruktur enn i en liten/simpel datastruktur?" -- ser du forskjellen nå, eller skal jeg utheve? (tips: stor allokert datastruktur impliserer ikke stor live datastruktur).

 

Som du selv påpeker skrev jeg stor datastruktur og liten datastruktur, ikke allokert datastruktur.

 

Ah, så stor datastruktur betyr nå stor live datastruktur hos deg. Veldig interessant. Er det noen andre egne definisjoner du har introdusert? (nyttig å vite for å unngå misforståelser i framtiden).

 

Og nok en gang, hva, spesifikt for stort Swing-gui gjør at gc blir omstendelig?

 

Blant annet størrelsen på datastrukturen copy collectoren må forholde seg til.

 

Størrelsen på datastrukturen er ikke et Swing-spesifikt aspekt. Jeg spør nok en gang, hva gjør at gc av stort Swing-gui blir omstendelig?

 

Når ble denne påstanden provoserende?

 

Igjen, det må nesten du svare på. Selv om det kanskje er like greit at du ikke gjør det.

 

Jeg skal svare på hva du mente med dine utsagn? Skal dette være en dårlig vits?

 

"provoserende" var et begrep du introduserte her. Jeg vet ikke hvorfor. Ej heller har jeg mulighet til å vite hvorfor du valgte å beskrive påstanden som provoserende.

 

Så, hvorfor gjorde du det? Spesifikt hva er provoserende med "(...) gc-implementasjon er vel så viktig som god jit"?

 

1. Igjen, det var ditt forslag at jeg skulle lese gc-bibelen til Jones & Lins. I dagligtale er det - til din informasjon - vanlig å omtale utfyllende, viktige og definitive verk om et tema som «bibel». Bibelen, den med alle evangeliene og testamentene som du muligens tenker på, skrives med stor forbokstav.

 

2. Jeg påpekte ganske enkelt at du tilla meg å ha skrevet noe annet enn det jeg gjorde.

 

3. Jeg gjentar det jeg har skrevet flere andre steder i denne tråden nok en gang; Bruk av Swing impliserer ofte at programmet er interaktivt. Det er da spesielt viktig at gc ikke tar lang tid (av gangen). I eksempelvis en webcontainer er det ikke så viktig. Swing har også et relativt stort fotavtrykk, men dét har jeg - i motsetning til hva du synes å ha fått for deg - ikke hevdet tilfører noe «Swing-spesifikt» til ryddeproblematikken.

 

4. Nok en gang, det var du som reagerte på det jeg skrev om jit vs gc. Kan desverre ikke forklare deg hvorfor.

 

Siden du nå har hengt deg opp og går i ring henviser jeg evntuelle videre spørmål til det jeg har skrevet tidligere i tråden, og avslutter her.

[MailMan13]

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.

Vel hvis det ikke hadde vært noen instruksjonsett etter pentium4 i listen så hadde du hatt rett,.... men faktumet er noe annet.

Jeg ser forskjellige x86 prosessorer opp til Pentium 4 pluss de vanlige utvidelsene, mulig jeg er blind dog, har skjedd før. MMX og SSE inneholder såvidt meg bekjent ikke RAX-R15.

Endret 3. februar 2010 av MailMan13

[GeirGrusom]

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.

Vel hvis det ikke hadde vært noen instruksjonsett etter pentium4 i listen så hadde du hatt rett,.... men faktumet er noe annet.

Jeg ser forskjellige x86 prosessorer opp til Pentium 4 pluss de vanlige utvidelsene, mulig jeg er blind dog, har skjedd før. MMX og SSE inneholder såvidt meg bekjent ikke RAX-R15.

Det var vel også snakk om en inline assembler, og ikke selve compileren også...

[Giddion]

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.

Vel hvis det ikke hadde vært noen instruksjonsett etter pentium4 i listen så hadde du hatt rett,.... men faktumet er noe annet.

Jeg ser forskjellige x86 prosessorer opp til Pentium 4 pluss de vanlige utvidelsene, mulig jeg er blind dog, har skjedd før. MMX og SSE inneholder såvidt meg bekjent ikke RAX-R15.

Håper jeg har rett nå

SSE4.1 og 4.2 finnes ikke etter det jeg kan se i p4, men kom først med Core i7.

[GeirGrusom]

P4 hadde vel bare SSE 1 og SSE 2 etter det jeg kan huske...

Men det fantes 64-bit versjoner av Pentium 4 som fortsatt mangler i Delphi ^^