Øker til 1333FSB

[snorreh]

Hei.

 

Med Intel Fortran 9.0 kompilerer vi kun 1 fil (den med PROGRAM) med opsjonen /QxW. Resten kompilerer vi med /QxN. Vi har flere tusen brukere i over 40 land og har aldri opplevd noe problem med denne fregamngsmåten.

Noen foretrekker Intel og noen foretrekker AMD, begge er happy med vår software.

5221259[/snapback]

Jeg kjenner også til programvare som er kompilert med Intel Fortran 9.0 med mange tusen brukere verden over som yter elendig sammenlignet med tilsvarende programvare. Likevel er det få brukere som klager, siden de fleste ikke vet bedre, men jeg kan love deg at de som er blitt gjort klar over dette er alt annet enn happy. Problemet er at når man først har bundet seg til en Fortran-kompilator så er det, spesielt med uhåndterlig og lite portabel kode, vanskelig å bytte plattform seinere dessverre.

 

Til AMD/Pathscale tilhengere vil jeg si at det går an å skifte mening. Selv var jeg en ihuga tilhenger av AMD før, så jeg har tenkt i de baner selv. Nå er jeg av den oppfatningen at det ikke er så stor forskjell.

5221259[/snapback]

Nei, forskjellen er sikkert ikke så stor i en Intel Fortran-verden der AMD-systemer yter langt under pari sammenlignet med Intel-systemer. Digit-Life sa det ganske bra her:

http://www.digit-life.com/articles2/cpu/in...000-part-m.html

In general, 64-bit AMD processors demonstrate lesser performance gain for the EM64T code versus 64-bit processors from Intel. Of course, in no way it can speak of the "64 bit" implementation efficiency in this or that case. It just means that the EM64T version of Intel compilers generates code, which is more optimized for P4, rather than for K8. There is actually nothing surprising about it. It would have been strange to have the opposite situation

 

Men et par punkter er:

 

1. Intel har samme kompilator på win-32,win-64,Linux og Mac-OS. Dvs. har man en kode på en platform - er det veldig lett å flytte den over, oppsettet er identsik. Kompilatoren er invariant med 4 ulike operativsystemer. Vi har bl.a. sett at .asm koden er helt identisk.

5221259[/snapback]

Vel, men de fleste alternative kompilatorer støtter også kildekode laget med Intel-kompilatorer noe som gjør det veldig lett å flytte over til en skikkelig kompilator der ytelsen er bra uansett prosessor og plattform.

 

2. Intel har VTune, som gjør det enkelt å finne hot-spots og forbedre ytelsen.

5221259[/snapback]

AMD har CodeAnalyst som gjør nøyaktig det samme og mer til. Det hadde sikkert vært meget interessant for deg å se hvor lite effektiv en kode som blir godkjent av VTune er ifølge CodeAnalyst. Kode som blir godkjent av CodeAnalyst er derimot ikke like inkonsekvent mhp. å gi god ytelse på alle prosessorer som VTune er ifølge mine egne erfaringer iallefall.

 

3. Intel har PGO og SSP, noe jeg ikke har sett hos andre Fortran kompilatorer enda. Dette er ikke aktivert i den AMD-64 testen som det refereres til.

5221259[/snapback]

Kanskje fordi det ikke har så stor effekt på ytelsen? GCC har støttet PGO i flere år såvidt jeg kjenner til.

 

4. Intel er plug in til Microsoft sin debugger.

5221259[/snapback]

Det er noe Compaq (DEC) Visual Fortran hatt i alle år. Absoft støtter også dette såvidt jeg vet, og ettersom PathScale er krysskompatibel med Absoft så regner jeg med at Lahey sin PathScale-port også vil støtte dette.

 

5. Intel har omfattende dokumentasjon (Intel Press).

5221259[/snapback]

AMD har omfattende dokumentasjon:

http://developer.amd.com/documentation.aspx#devguides

http://www.devx.com/amd/Door/16009

 

Det finnes sikkert en tilsvarende god liste for AMD - slik at forskjellen, når alt kommer til alt, ikke blir som natt og dag, slik enkelte hevder. Vil ikke komme med noen spesifikke resultater i dette forumet, kan bare nevne at det er visse ting i Intel sine bibliotek fremstår foreløpig  som enestående - også i forhold til Pathscale.

 

Invariant.

5221259[/snapback]

Det er kun du som forsvarer Intel sine kompilatorer til tross for at jeg har dokumentert ganske grundig at de utvilsomt yter dårligere på alle andre prosessorer enn sine egne. Hvis Intel sine kompilatorer bidrar til at systemer med AMD-prosessorer yter 10-20% dårligere, så vil det naturligvis bety at forskjellene i ytelse mellom Intel- og AMD-systemer er fullstendig utjevnet. Bra for dem som har Intel-systemer, men ikke like bra for dem som har AMD-systemer (mindre valuta for investeringene). Når det gjelder Intel sine bibliotek så er de neppe særlig enestående - det er derimot åpne bibliotek som Hypre (LLNL), PETSc (ANL) og Trillinos (Sandia) etter min mening.

Endret 28. november 2005 av snorreh

[invariant]

Når det gjelder Intel sine bibliotek så er de neppe særlig enestående

 

Her ser jeg snev av en type arroganse jeg selv var i befatning av for noen år siden. Slikt kommer ingen tilgode. Både hos Intel og AMD/Pathscale finnes det glimrende forskere og ingeniører som gjør en fantastisk god jobb, de har en formidabel innsikt i både software og hardware.

 

Det er kun du som forsvarer Intel sine kompilatorer til tross for at jeg har dokumentert ganske grundig at de utvilsomt yter dårligere på andre prosessorer enn sine egne.

 

Her vil jeg anbefale at du prøver en sammenligning selv, dvs. ikke ta alle linker du leser for god fisk. Dokumentasjon er en ting - noe annet er det hvordan ting slår ut for den softwaren du har tenkt å selge selv. Det er her PGO og SSP kan gi utrolig gode resultater, nettop fordi du får en kompilator spesialsydd for akkurat din applikasjon. Ikke uvanlig å se 40% bedring her. Kom tilbake med flere innlegg når du har testet dette selv.

 

Invariant.

[snorreh]

Når det gjelder Intel sine bibliotek så er de neppe særlig enestående

 

Her ser jeg snev av en type arroganse jeg selv var i befatning av for noen år siden. Slikt kommer ingen tilgode. Både hos Intel og AMD/Pathscale finnes det glimrende forskere og ingeniører som gjør en fantastisk god jobb, de har en formidabel innsikt i både software og hardware.

5221766[/snapback]

Joda, men til forskjell fra Intel så er det neppe markedsføringsavdelingen som styrer kompilatorutviklingen til AMD/PathScale, osv. Hvis Intel sine kompilatorfolk er så fantastisk dyktige som du gir inntrykk av, hvordan forklarer du at de fortsatt ikke har fjernet denne tragiske CPUID-sjekken som ble avslørt allerede tilbake i 2001?

 

Det er kun du som forsvarer Intel sine kompilatorer til tross for at jeg har dokumentert ganske grundig at de utvilsomt yter dårligere på andre prosessorer enn sine egne.

 

Her vil jeg anbefale at du prøver en sammenligning selv, dvs. ikke ta alle linker du leser for god fisk. Dokumentasjon er en ting - noe annet er det hvordan ting slår ut for den softwaren du har tenkt å selge selv. Det er her PGO og SSP kan gi utrolig gode resultater, nettop fordi du får en kompilator spesialsydd for akkurat din applikasjon. Ikke uvanlig å se 40% bedring her. Kom tilbake med flere innlegg når du har testet dette selv.

 

Invariant.

5221766[/snapback]

Snakker om arroganse ja

 

Selvsagt har jeg testet dette selv, uttallige ganger, og min erfaring er at ytelsen avhenger mye av størrelsen på problemet man prøver å løse. På små problemer så kan slike ting slå kraftig ut, men på større, mer reelle problemer, så er ikke forskjellene så store. Jeg er mer opptatt av å oppnå konsekvent god ytelse uansett prosessor og plattform, og da hjelper det lite om Intel sine kompilatorer støtter PGO og SSP når de jevnt over yter dårligere på AMD-systemer enn andre kompilatorer - da holder jeg meg heller til alternativene som er det eneste fornuftige å gjøre etter min mening.

Endret 28. november 2005 av snorreh

[invariant]

Flott at du har testet PGO og SSP utallige ganger.

 

1. Hvilke kompilator-versjon (IVF) brukte du?

2. Hva slags instruksjons-sett genererte du for: SSE, SSE2, SSE3?

3. Hvilke kompilator-opsjoner brukte du?

4. Hva slo best ut SSP eller PGO?

5. Hvor mange test-case hadde du som del av kompileringen?

6. Hvor lenge kjørte hvert test-case?

7. Prøvde du kombinasjonen /Qipo /Qprof_use?

8. Sjekket du i assemblerkoden om du fikk nye funksjoner inlinet?

9. Monitorerte du cache miss før/etter PGO/SSP?

10. Ved inspeksjon av assemlekoden før/etter PGO/SSP fikk du noen tips til hva som kan gjøre koden din bedre?

 

PGO/SSP fungerer typisk dårlig for små programmer med få instruksjoner og data. Derimot er det for større applikasjoner som krever mye minne og som ikke er optimalt programmert (de fleste er ikke det, men kanskje ditt?), at vi ser en stor effekt.

 

Invariant.

[Anders Jensen]

Slo meg også at det var noe konterintuitivt at SSP skulle virke best på små datasett. For PGO så burde jo det være nesten komplett unyttig hvis hele det aktive instruksjonsområdet fikk plass i høyere nivå cache. Det er først når deler av koden kan plasseres utenfor høyere nivå cache til fordel for annen "varmere" kode at PGO bør ha nevneverdig effekt. Serlig for x86 hvor en bare har mulighet til indirekte å angi sannsynlighet for taken/untaken.

[invariant]

5221766[/snapback]

Snakker om arroganse ja

5221854[/snapback]

 

Forskjellen er at jeg, basert på det du har skrevet, har en bestemt holdning overfor dine innlegg, mens du er arrogant overfor noen utenfor dette forumet, nemlig prisbelønnede utviklere av software over hele verden.

 

Invariant.

[invariant]

Intel Fortran leder ikke under 64-bit Linux som er det som faktisk betyr noe i HPC-verden:

http://www.polyhedron.co.uk/pb05/linux/f90bench_AMD.html

 

For vår del stemmer ikke dette. Følgende gjelder for våre kunder.

 

1. Ingen av dem kjører 64-bit OS, dvs. alle kjører Win-32.

2. 95-97% av dem har Intel prosessor.

 

Dermed blir det nok denne testen:

 

http://www.polyhedron.co.uk/pb05/win32/f90bench_p4.html

 

som blir mest relevant. Bakgrunnen for at nesten alle har Intel prosessor vet jeg ikke, men jeg vet at den kommersielle overgangen til Win-64 ikke har tatt av riktig enda.

 

Så kjenner man til resultatene fra Pentium-D testen over, har man egentlig ikke noe valg. Har man lyst til å tjene masse penger selger man software utviklet med Intel Fortran.

 

Invariant.

 

P.S. Er det vanskelig å tjene penger i HPC-verden?

[Del]

Greit nok at du ikke vil si noe om koden du refererer til, men du kan da i alle fall røpe om de 40% dreier seg om Pentium/Xeon eller Itanium?

[invariant]

Greit nok at du ikke vil si noe om koden du refererer til, men du kan da i alle fall røpe om de 40% dreier seg om Pentium/Xeon eller Itanium?

5222800[/snapback]

 

Hei.

 

Ingen av vår kunder har Itanium prosessor.

 

Invariant.

[snorreh]

Flott at du har testet PGO og SSP utallige ganger.

 

1. Hvilke kompilator-versjon (IVF) brukte du?

2. Hva slags instruksjons-sett genererte du for: SSE, SSE2, SSE3?

3. Hvilke kompilator-opsjoner brukte du?

4. Hva slo best ut SSP eller PGO?

5. Hvor mange test-case hadde du som del av kompileringen?

6. Hvor lenge kjørte hvert test-case?

7. Prøvde du kombinasjonen /Qipo /Qprof_use?

8. Sjekket du i assemblerkoden om du fikk nye funksjoner inlinet?

9. Monitorerte du cache miss før/etter PGO/SSP?

10. Ved inspeksjon av assemlekoden før/etter PGO/SSP fikk du noen tips til hva som kan gjøre koden din bedre?

 

PGO/SSP fungerer typisk dårlig for små programmer med få instruksjoner og data. Derimot er det for større applikasjoner som krever mye minne og som ikke er optimalt programmert (de fleste er ikke det, men kanskje ditt?), at vi ser en stor effekt.

 

Invariant.

5221953[/snapback]

 

1. Alle versjoner som har vært tilgjengelig siden CVF ble EOL'd.

2. Alle, men mest SSE & SSE2. Få tilgjengelige HPC-systemer som støtter SSE3 foreløpig.

3. Prøvd de fleste, hvordan det?

4. PGO.

5. Opptil flere for hver gang jeg testet en opsjon. Alltid reelle problemer, ingen benchmark problemer.

6. Timer, dager, uker alt ettersom.

7. Ja, jeg mener jeg var innom den også når jeg testet PGO.

8. Ja, med svært varierende resultat.

9. Ja, fikk fortsatt massevis av dem.

10. Både ja og nei, ingenting av reell nytte. Har prøvd flere koder som løser samme problem med forskjellige likningsløsere og fikk omtrent samme tips hver gang uten at det hjalp særlig.

 

Når jeg snakker om store program (les: reelle problem) så er det dem som krever 1GB RAM eller mer, mens små problem er de som krever mindre enn dette (les: benchmark-tester). Og koden jeg tester er selvsagt alltid optimalt programmert utifra problemene som løses - det er stort sett test av bibliotek/likningsløsere/algoritmer som kjøres her til daglig på alt fra 2/4/8-veis systemer, til større klynger og superdatamaskiner både nasjonalt og internasjonalt (les: HPC-verden). Vedrørende ytelse så ligger flaskehalsen stort sett alle andre plasser enn på kompilatorbryter-nivå - og ved siden av rein ytelse så er ofte nøyaktigheten og stabiliteten på løsningene minst like viktige. Intel-kompilatorer skårer kanskje ikke så bra på ytelse. men de gjør det over gjennomsnittet bra mhp. kvaliteten på resultatene der den spiser omtrent alt av kode, både god og dårlig.

[invariant]

9. Ja, fikk fortsatt massevis av dem.

 

Hei.

 

Dette er nyttig informasjon. Har du massevis av cache-miss finnes det hjelp hos Intel (og hos Pathscale kanskje?) sine tekniske ingeniøravdelinger som kan gi nyttige tips. Siden både software og hardware endrer seg hele tiden er det lurt å være i kontakt med de som skriver kompilatorene, kanskje kan du foreslå noe som Intel/Pathscale kan legge inn i sin kompilator?

 

 

Invariant.

Endret 28. november 2005 av invariant

[snorreh]

Intel Fortran leder ikke under 64-bit Linux som er det som faktisk betyr noe i HPC-verden:

http://www.polyhedron.co.uk/pb05/linux/f90bench_AMD.html

 

For vår del stemmer ikke dette. Følgende gjelder for våre kunder.

 

1. Ingen av dem kjører 64-bit OS, dvs. alle kjører Win-32.

2. 95-97% av dem har Intel prosessor.

 

Dermed blir det nok denne testen:

http://www.polyhedron.co.uk/pb05/win32/f90bench_p4.html

 

som blir mest relevant. Bakgrunnen for at nesten alle har Intel prosessor vet jeg ikke, men jeg vet at den kommersielle overgangen til Win-64 ikke har tatt av riktig enda.

 

Så kjenner man til resultatene fra Pentium-D testen over, har man egentlig ikke noe valg.

5222606[/snapback]

Ok, da forstår jeg godt at ytelse på andre systemer enn Intel-baserte ikke er så viktig for dere. AMD-systemer (les: Opteron) trives nemlig best ytelsesmessig på Linux x86-64 med PathScale-kompilatorer o.l. Innen HPC-verden så er Windows-plattformen så og si ikke-eksisterende. Her er også Opteron etterhvert blitt en enorm suksess først og fremst pga. ytelse/pris/watt. For deres kunder så er sikkert ikke dette særlig viktig, og når AMD-systemer ikke har noen ytelsesfordeler fremfor Intel-systemer lenger så må man jo temmelig dum for å velge noe annet enn Intel eller hva?

 

Har man lyst til å tjene masse penger selger man software utviklet med Intel Fortran.

 

Invariant.

 

P.S. Er det vanskelig å tjene penger i HPC-verden?

5222606[/snapback]

Hvis man har lyst til å tjene mest mulig penger på programvare så er det bare å se på Microsoft, SUN eller IBM - ingen av dem selger programvare utviklet med Intel Fortran.

 

Og nei, det er ikke mye penger å hente i HPC-verden - mest prestisje og ære kanskje?

Endret 28. november 2005 av snorreh

[snorreh]

9. Ja, fikk fortsatt massevis av dem.

 

Hei.

 

Dette er nyttig informasjon. Har du massevis av cache-miss finnes det hjelp hos Intel (og hos Pathscale kanskje?) sine tekniske ingeniøravdelinger som kan gi nyttige tips. Siden både software og hardware endrer seg hele tiden er det lurt å være i kontakt med de som skriver kompilatorene, kanskje kan du foreslå noe som Intel/Pathscale kan legge inn i sin kompilator?

 

 

Invariant.

5222999[/snapback]

Intel er allerede på saken. Vi får jevnlig besøk av representanter fra de fleste hold og som en del av avtalene vi har inngått så rapporterer vi også alle funn som en del av rutinen - slik de fleste gjør i HPC-verden. PathScale.kompilatorer blir stort sett kun brukt på de problemene hvor høy ytelse er aller viktigst som f.eks. reservoarsimuleringer, vær- og klimaberegninger osv. hvor tid er penger. Det er ikke på alle problemer den lar seg implementere skikkelig, så ellers er det en fin miks av alle de øvrige kompilatorene som har hver sine sterke og svake sider alt etter hvilken type kode som brukes. Det mangler ikke på utfordringer for å si det mildt

[invariant]

Og nei, det er ikke mye penger å hente i HPC-verden - mest prestisje og ære, men det teller vel ikke?

 

Klart det teller. Etterhvert har jeg funnet ut at en av veiene til å oppnå prestisje og ære bl.a. er ydmykhet: det er bra for karrieren!

 

Når alt kommer til alt er det vel håndtverket, software utvikling, som er det morsomste her, og jeg må ærlig talt inrømme at det høres utrolig spennede ut med Opteron på Linux x86-64 med PathScale-kompilatorer.

 

Når det gjelder Intel vs. AMD så er ikke forskjellen så stor, de samarbeider faktisk endel, f.eks. utvidet AMD SSE2 (Intel sin ide) fra 8 xmm register til 16 xmm register med x86-64. Sånt sett, og med tanke på prestisje og ære, så virker det litt overkill med sitatet i signaturen din. Kan du ikke ta dette bort?

 

Invarant.

Endret 8. desember 2005 av invariant

[Del]

for programmer med mange if-statement har jeg registrert en ytelses-økelse på opptil 40% med Intel sin PGO.

...

Det er her PGO og SSP kan gi utrolig gode resultater, nettop fordi du får en kompilator spesialsydd for akkurat din applikasjon. Ikke uvanlig å se 40% bedring her.

Jeg synes det blir vanskelig å forholde seg til slike uttalelser. Burde vært uproblematisk for deg å klargjøre at vi snakket om Pentium på win-32 på et langt tidligere tidspunkt. Det er i grunnen heller ikke greit (ved nærmere ettertanke...) at det eneste du vil si om koden er FP/minne når du går ut med så bred front, og generelle påstander. Uansett hva du driver med burde det være helt uproblematisk å være mer spesifikk på type problemer du har erfaring fra.

 

Jeg har hatt kjennskap, om enn lite erfaring, med både SSP og PGO, bare les manualen til IFC, så alt du har sagt så langt fortoner seg fortsatt for meg som ren reklame, ideelt bør et forumet være en plass for å dele erfaringer.

[invariant]

Hei.

 

Beklager hvis jeg har virket hemmelighetsfull, dette er pga. helt kommersielle hensyn. Og, jeg er en stor tilhenger av å dele erfaringer, så lenge det ikke går ut over kommersielle interesser. Du kan først og fremst se på mine innlegg som opplysing (), jeg synes det er flott at tilhengere/motstandere av en teknologi kan slippe til i et forum som dette.

 

Mitt tips er å teste ut ulike kompilatorer, profileringsverktøy og dokumentasjon selv, for det er ikke sikkert at det som passer bra for en applikasjon er tilsvarende bra for en annen.

 

Invariant.

Endret 8. desember 2005 av invariant

[Anders Jensen]

Tillater meg å være så frekk at jeg poster noe som er on-topic. RWT har gjort en systemtest av Bensley, riktignok en versjon med "bare" 1066FSB. Den viser ca 40% til 120% ytelsesøkning over et Nocona basert system. Legger vekt på at dette er en systemtest og ikke en CPU- eller kjerne test.

 

edit: skader vel ikke å legge ved linken heller..

http://www.realworldtech.com/page.cfm?Arti...RWT112905011743

Endret 29. november 2005 av Anders Jensen

[Boralis]

Snakker om arroganse ja      Selvsagt har jeg testet dette selv, uttallige ganger, og min erfaring er at ytelsen avhenger mye av størrelsen på problemet man prøver å løse. På små problemer så kan slike ting slå kraftig ut, men på større, mer reelle problemer, så er ikke forskjellene så store. Jeg er mer opptatt av å oppnå konsekvent god ytelse uansett prosessor og plattform, og da hjelper det lite om Intel sine kompilatorer støtter PGO og SSP når de jevnt over yter dårligere på AMD-systemer enn andre kompilatorer - da holder jeg meg heller til alternativene som er det eneste fornuftige å gjøre etter min mening.

 

Vel ikke vet jeg,men dette stemmer dårlig med tidligere utsagn fra deg, der du selv sier at du ikke vil "ta" i et Inteloppsett og langt mindre annbefale det.

Utifra dette finner jeg det "rart" at du da har testet dette så grundig,men om du har det finner jeg derimot ikke din konklusjon som særlig overraskende .

[Anders Jensen]

Snakker om arroganse ja      Selvsagt har jeg testet dette selv, uttallige ganger, og min erfaring er at ytelsen avhenger mye av størrelsen på problemet man prøver å løse. På små problemer så kan slike ting slå kraftig ut, men på større, mer reelle problemer, så er ikke forskjellene så store. Jeg er mer opptatt av å oppnå konsekvent god ytelse uansett prosessor og plattform, og da hjelper det lite om Intel sine kompilatorer støtter PGO og SSP når de jevnt over yter dårligere på AMD-systemer enn andre kompilatorer - da holder jeg meg heller til alternativene som er det eneste fornuftige å gjøre etter min mening.

 

Vel ikke vet jeg,men dette stemmer dårlig med tidligere utsagn fra deg, der du selv sier at du ikke vil "ta" i et Inteloppsett og langt mindre annbefale det.

Utifra dette finner jeg det "rart" at du da har testet dette så grundig,men om du har det finner jeg derimot ikke din konklusjon som særlig overraskende .

5224527[/snapback]

Å bli overrasket av konklusjonen til forumets klareste bias er vel ikke mye sannsynlig nei. Bare signaturen i seg selv sier jo sitt, og det er kanskje ikke den øverste linja som bør bekymre mest. Hva vet jeg, men uansett ettersom nye folk kommer til dette forumet så blir en jo nokså kjapt påminnet om at det er mye bias ute å går. Invariant har vel funnet ut ett og annet i denne tråden om dette og det var vel ikke så lenge siden Del fikk kvesset tennene på liknende vis heller. Vi to, snekker'n, skal kanskje ikke være for ivrig med å kaste stein heller

[invariant]

Kult med litt innsikt i forumets liv.

 

Hvis jeg skulle komme med litt kritikk av Intel selv så må det være HT.

Tanken bak HT er at ofte så står mange execution ports ledige, det er vel

en 6-7 execution ports i en Xeon/Pentium 4/D, og hvis et program venter

på data, f.eks. pga. stall e.l., så kan en annen tråd bruke noen execution

ports siden de likevel er ledige. Kjører man 2 tråder som er litt sloppy

programmert samtidig, vil en se at HT har en formidabel effekt. Er man

en god programmerer som kan sin SSE2, er dette ikke lurt. Et program

som bruker alle execution port effektivt kan ikke kjøre i paralell med et

annet program som gjør det samme. Skrekkeksempelet var en optimal

modul vi hadde, en tråd tok 2 minutter, to tråder samtidig tok 28 minutter...

(PC med HT) Vanligvis skulle man forvente at 2 tråder tok omlag 3 minutter,

men ikke hvis du kan din SSE2. Man må passe seg hvis man lager for

optimal kode...

 

Invariant.