Forsida
Temaer
Sjangere
Nei til postkontor
Tema: Diverse; sjanger: Meninger
Skrevet av Andreas Nordal den 15. januar 2013 kl 17:54:46; Kommentarer: 0
Postkontorer har bare åpent når folk er på jobb. Det er mye bedre å ha kombinert postkontor og butikk. Aller helst kombinert med bensinstasjon!
Nå er det andre dag på rad at jeg ikke greide å komme hjem før 17.00. Samme sak skjedde rett før juleferien; etter flere mislykkede forsøk var det på hengende håret at jeg fikk henta pakkene før jeg reiste bort. Fra der jeg bodde før, er jeg vant med postkontor i butikk, og det er deilig kan jeg fortelle, hvis man handler en del på nett.
Til alle som jobber i sørvisnæringer: Bare drit i å jobbe på hverdager! Såkalte «fridager» (ikke alle har fri uansett) er jo åpenbart mer verd, for begge parter. Såpass at jeg tror du kan tjene minst like mye på å bare jobbe i helgene og ta fri resten av uka.
— Det derre der, det er tyyypisk norsk kundebevissthet, det…
RJ45: En studie i dårlig design
Tema: Diverse; sjanger: Meninger
Skrevet av Andreas Nordal den 18. mars 2012 kl 15:16:55; Kommentarer: 0
(klikk på bildet for større bilde)
Øverst: frisk RJ45
Midten: offer for forsiktig bruk, ingen spenst
Nederst: ødelagt RJ45
- Hvorfor er den forma som en krok?
- Hvorfor har den et svakt punkt?
- Hvorfor er det svake punktet lagd av plast?
Jeg bruker bærbar PC, og plugger kontaktene mye til og fra. Det gjør at jeg fort merker hvilke kontakter som ikke tåler slitasje fra normal bruk. Etter min erfaring er RJ45-plugger fantastisk sårbare. Det neste som er dømt til å ryke er lydutgangen på selve PC-en, men også USB-porter kan bli så utslitt at det er 0 elektrisk kontakt igjen.
Hvordan ødelegge en ethernet-kabel
- Dra den gjennom kabelsalaten, opp av skolesekken, eller noe så uskyldig som å «trekke kabel» fra A til B, og du kan banne på at den skjøre mothaka hekter seg borti noe.
- På grunn av materialtretthet som oppstår under selv ekstremt forsiktig bevisst bruk, blir mothaka løsere og løsere, og bare må knekke en gang. På bildet til høyre, er den midterste (blå) pluggen offer for ekstremt forsiktig bevisst bruk i snart et år, og synger på siste verset. Man kan ane en sprekk i det svake punktet.
En konsekvens av termofysikkens andre lov er at kabler blir til kabelsalat. Kan det ha vært det de tenkte på, de som fant opp RJ45? For størrelsen på krok-åpninga passer perfekt til diameteren til en typisk ethernet-kabel…
Den knekte enden kan du, hvis du er heldig, klare å bruke; du kan for eksempel holde den på plass i en veggkontakt ved å mose et bordbein inntil.
Hvordan RJ45 burde være
- Snu mothaka motsatt vei, så den slipper å være krok.
- La en lengre del av mothaka få bøye seg, ikke bare i ett (svakt) punkt.
- Lag mothaka av metall, takk. Det er den verd.
Ikke sånn. Rød ring markerer svakt punkt. |
Men sånn. Svart U-formet metallspenne, delvis stukket inn i et spor i plasten. |
Du trenger hvertfall ikke krok-funksjonaliteten til RJ45.
fsck er farlig
Tema: Programvare; sjanger: Meninger
Skrevet av Andreas Nordal den 7. oktober 2011 kl 18:13:45; Kommentarer: 0
Hvis korrupsjon i filsystemet skyldes maskinvarefeil, så vil fsck gjøre vondt verre. Det er min erfaring etter å ha mista 1,4 TB.
Fsck er programmet som skal «fikse» eventuelle feil i filsystemer, typisk i det man skrur en datamaskin på. Det skumle er at fsck er et idiotisk program som har 0 forutsetning for å gjøre de riktige valgene. Tenk deg et stavekontrollprogram som bare sletter alle setninger som ikke er grammatisk korrekte. Før du slipper fsck løs på livsverket ditt, bør du være sikker på at det er feilfritt...
Det skulle vise seg at jeg hadde en feil i SATA-koblinga mellom harddisk og hovedkort. Det hjalp ikke et fnugg å ha RAID1, for feilen skjedde selvfølgelig samtidig for koblingene til begge harddsikene, eller mer sannsynlig, at det fins en felles komponent på hovedkortet som kunne svikte. Det er statisk redundans i praksis, det.
Smartctl avslører feilen. Utklipp (min utheving):
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 147 145 021 Pre-fail Always - 9633 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 32 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 073 073 000 Old_age Always - 19734 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 22 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 4 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 28 194 Temperature_Celsius 0x0022 121 110 000 Old_age Always - 31 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 38935 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
Ifølge smartctl er kommunikasjonen med denne harddsiken upålitelig, mens selve harddisken fungerer utmerket. I praksis merkes feilen ved at filene kan være litt forskjellige hver gang, spesielt store filer. Det betyr at dataene kan reddes hvis man kjenner sjekksummen; det er bare å lese dem om igjen til det stemmer. Men tror du fsck leser om igjen når noe ikke stemmer? Etter første runde med fsck fikk jeg ikke engang montert filsystemet.
Hva er verst:
- helt tapte data
- korrupte data
- data som du ikke vet om er korrupt eller ikke
Man tror at «maskinvarefeil rammer ikke meg». Enda mindre hadde jeg fantasi til å mistenke denne feilkilden tilfeldigvis midt i en oppgradering av filsystemet fra ext3 til ext4, når det er minst et par andre ting som kan gå galt. Så jeg rapporterte det som en programvarefeil. Der står hendelsesforløpet utførlig beskrevet.
Hele katastrofen hadde vært en bagatell hvis jeg hadde forstått problemet med en gang. Det dummeste jeg kunne gjøre var å følge siste punkt på prosedyren, nemlig fsck. Som med de fleste katastrofer: Det er når man har uhell i uhellet at det går galt. I'm fsck'd.
Ikke partisjoner harddisken
Tema: Programvare; sjanger: Artikler
Skrevet av Andreas Nordal den 5. april 2011 kl 23:10:23; Kommentarer: 0
Hvis man likevel bare skal ha én partisjon på en harddisk, hvorfor ikke gjøre det enkelt?
Bortsett fra operativsystem-partisjonen, som faktisk må være en partisjon (for at BIOS og oppstartlaster skal funke), så er det ikke nødvendig å partisjonere eventuelle andre harddisker i datamaskinen.
Eksempel
I Linux kan man:
mkfs.ext4 /dev/sdd
I stedet for:
mkfs.ext4 /dev/sdd1
Da skriver man i /etc/fstab:
/dev/sdd /mnt/d ext4 defaults 1 2
Framfor:
/dev/sdd1 /mnt/d ext4 defaults 1 2
Dette funker faktisk: Denne nettsiden er lagra på to uformaterte harddisker i raid1.
Forklaring
Mens vanlig prosedyre er å formatere enkelt-partisjoner av harddisken, er det selvsagt også mulig å formatere selve harddisken. Det resulterende filsystemet vil da spenne absolutt hele harddisken, uten plass til partisjonstabell og alt det der.
Fordeler
- Unngå problemet med at MBR ikke støtter mer enn 2 TiB. Den gammeldagse partisjonstabellen skaper for tiden krise i harddisk-bransjen.
- Unngå «alignment»-problematikk på SSD-enheter. Sektor 0 er det smarteste stedet å starte filsystemet, fordi alle tenkelige blokkstørrelser går opp i 0.
Ulempe
- Du skal vite hva du gjør: Ettersom vi avviker fra alle standarder om harddiskpartisjonering, er det du, ikke operativsystemet, som må vite hva du har gjort med harddisken. Ikke forvent noe automatikk. Forvent snarere at et eller annet program får det for seg at harddisken er upartisjonert (som den jo er), og at du i ørska trykker «OK» på å la den «fikse det».
Konklusjon
Skal man først ha en ekstra harddisk, typisk for å få et stort filsystem til ren datalagring, så er man ikke interessert i å partisjonere harddisken i biter. Det er heller ikke vits i å lage den ene partisjonen for BIOS eller oppstartslasterens skyld. Dessuten skaper det bare trøbbel. Teknisk sett er det veldig smart å ikke partisjonere harddisken.
Fisk i fjæra
Tema: Diverse; sjanger: Prosjekter
Skrevet av Andreas Nordal den 26. mars 2011 kl 23:53:20; Kommentarer: 0
Jeg kom i skade for å lage en film. Den heter «Fisk i fjæra». Den er i samme sjanger som Nattkjole med urin og Hatten är din. Jeg håper ingen blir provosert av den.
Det jeg har gjort er å legge på norsk tekst på en somalsk musikkvideo. Ja, også litt grafikk da.
Bare så det er sagt, så er det faktisk mulig å redigere film på Linux også. Det var ikke fryktelig vanskelig. Jeg brukte disse programmene:
Krita var egentlig uegnet til mitt formål, som var å gjøre bakgrunnen av grafikkbildene gjennomsiktig. Det hadde vært 100 ganger lettere hvis «inverter utvalg»-funksjonen hadde funka. Jeg kunne sikkert brukt Gimp.
PHP duger ikke til interaktiv skripting
Tema: Programmering; sjanger: Meninger
Skrevet av Andreas Nordal den 24. februar 2011 kl 13:31:25; Kommentarer: 0
Hvorfor monger ssh-klienten når den startes fra PHP? Ikke gjør dette hjemme:
#!/usr/bin/php
<?php
system('ssh meg@domene');
?>
Det som tilsynelatende skjer da er at ssh bufrer unna all interaktivitet. Du får ikke se hva du skriver i kommandolinja før du har trykka enter, men da er det jo for seint. Og skal du redigere tekst over ssh? Da er du kjørt...
Slik skal det gjøres:
#!/usr/bin/python import subprocess subprocess.call(['ssh', 'meg@domene'])
goto kan være fornuftig
Tema: Programmering; sjanger: Artikler
Skrevet av Andreas Nordal den 11. april 2010 kl 21:22:18; Kommentarer: 0
For de som ikke kjenner goto: Goto forteller datamaskinen at den skal fortsette et annet sted i programmet. Slik vi kjenner det i programmeringsspråket C, er goto en videreføring av jump-instruksjonen, fra den tiden man programmerte i assembly (eller direkte maskinkode for den saks skyld), og er dermed blant de eldste programmeringskonseptene. En vanlig oppfatning er at goto er utdatert. Det var faktisk en hovedhensikt med såkalt strukturert programmering, et konsept i høynivå-programmeringsspråk, å eliminere behovet for å bruke goto.
Kritikere hevder at bruk av goto fører til «spaghettikode», det vil si kildekode som er vanskelig å følge fra start til slutt, for å ikke nevne baklengs, man ser jo ikke hvor man "kommer fra". Dette avhenger selvsagt av hva man gjør det til, så hvis man klarer å bruke goto på en ryddig og konsekvent måte, så er det kanskje tilgivelig.
Tilgivelig eller ikke, noen ganger er det veldig praktisk å bruke goto. Ja, jeg vil gå så langt som å hevde at det kan være fornuftig! Dette har jeg prøvd å vise med kodeeksempelet nedenfor, men først en hverdagslig analogi: Forestill deg at du følger en oppskrift som består av mange steg. Hvert steg kan gå galt, og hvis noe går galt, må du avblåse hele prosjektet og rydde opp. Mengden opprydding vil avhenge av hvor langt du kom før du avbrøt. Selvsagt står ikke oppryddingsprosedyrene i oppskriften for hvert steg som kan gå galt; de er irrelevante for selve algoritmen. Det er i algoritmen utfordringa ligger, mens feilhåndtering på en måte sier seg selv og har ingen ting å si for om resultatet blir riktig i det normale tilfellet. Så hvordan kan vi separere algoritme og feilhåndtering? En måte er å håndtere suksesstilfellet der og da som et slags spesialtilfelle. Suksess på suksess vil da i kildekode få en sinnssyk indentering. Det er ikke uten grunn at programmeringsspråk som C++ og Java har "exceptions", en alternativ kontrollflyt for å avbryte, som er til for å la feilhåndteringa skje et annet sted. Det mer primitive programmeringsspråket C har ikke exceptions, men så har vi jo det gamle velkjente skitne trikset.
De to hypotetiske programsnuttene nedenfor viser feilhåndtering henholdsvis med if/else og if+goto. De gjør nøyaktig det samme, nemlig å initialisere «struct karamell»:
//Denne delen hører med til begge eksemplene. #include <stdlib.h> #include <stdio.h> #include <string.h> struct karamell{ char * navn; void * buf; // : // · FILE * fp; };
//Eksempel 1: if/else struct karamell * k_init(char * filnavn){ struct karamell * k; k = malloc(sizeof(*k)); if(k == NULL){ perror("malloc"); }else{ //OK k->fp = fopen(filnavn, "rb"); if(k->fp == NULL){ perror(filnavn); }else{ //OK k->navn = strdup(filnavn); if(k->navn == NULL){ perror("strdup"); }else{ //OK // . // . // . // ......... // . // . // . // ......... // . if(posix_memalign(&(k->buf), 1024, 1024) != 0){ fputs("posix_memalign failed.", stderr); }else{ //OK /* Nothing bad happened, yet * we are in deep indentation! * We are treating the normal * case as the special case. * Here is where we do our work: * : * · */ return k; } free(k->navn); //cleanup // . // . // . // . } fclose(k->fp); //cleanup } free(k); //cleanup } return NULL; }
//Eksempel 2: if+goto struct karamell * k_init(char * filnavn){ struct karamell * k; k = malloc(sizeof(*k)); if(k == NULL){ perror("malloc"); goto die; } //OK k->fp = fopen(filnavn, "rb"); if(k->fp == NULL){ perror(filnavn); goto fopenfail; } //OK k->navn = strdup(filnavn); if(k->navn == NULL){ perror("strdup"); goto noname; } //OK // : // · if(posix_memalign(&(k->buf), 1024, 1024) != 0){ fputs("posix_memalign failed.", stderr); goto nobuf; } //OK /* Nothing bad happened -> no extra indentation. * The normal case is no special case! * Here we do our work: * : * · */ return k; //exceptional cleanup nobuf: // : // · free(k->navn); noname: fclose(k->fp); fopenfail: free(k); die: return NULL; }
Hva er problemet med det første kodeeksempelet?
- Legg en linjal langs der hvor det står "}else{", så ser du hvor dette bærer hen: Innrykket er en lineær funksjon av linjenummeret. Med andre ord: Innrykket sier deg ikke en dritt, kanskje heller får programmet til å se vanskeligere ut enn det er. Hvis programmet ditt ser slik ut, da er du kjørt. Og det er ikke primært fordi innrykk er en begrenset ressurs. For å sitere Linus Torvalds: "If you need more than 3 levels of indentation, you're screwed".
- Hvis det skulle gjøres noe nyttig med variabelen «k» i funksjonen k_init(), annet enn å returnere den (typisk er det en eller annen sinnssyk algoritme som skal implementeres), ville det være kjipt å starte med så lang indentering. Da er behovet for en ny funksjon allerede stort.
Den observante leseren vil legge merke til at disse kodesnuttene er så like at de vil kompilere ned til de samme instruksjonene. Jeg sjekka den gcc-genererte assembly-koden, og fant to ubetydelige forskjeller (en NOP og en ubrukt etikett i goto-versjonen).
Til slutt, hvis du tror jeg er den eneste som bruker goto på denne måten, og at ingen ville finne på å bruke goto like flittig som meg, ta et googlesøk på "linux/fs/ext2/dir.h", så skal du få deg en bakoversveis!
mp3 skader musikken din
Tema: Programvare; sjanger: Meninger
Skrevet av Andreas Nordal den 22. november 2009 kl 01:00:48; Kommentarer: 6
Dette skjer med musikken din når du lagrer den som mp3: Forskyvning fra starten og pause i overgangen mellom sangene. Det er lett å se og lett å høre!
Ryktene skal ha det til at det i praksis er vanskelig å høre kvalitetsforringelsen som oppstår når man lagrer lyd i mp3-formatet. De som mener dette har tydeligvis ikke tatt i betraktning mp3-formatets akilleshæl. Hvis du tester dette selv, tror jeg du vil være enig med meg i at man skal være 100% døv for å ikke høre forskjellen. Jeg forutsetter da at mp3-dekoderen ikke prøver å maskere problemet ved å mikse overgangene sammen.
Slik testet jeg
- Kjøpte Goliath 12 på CD.
- Rippet hvert spor av CD-en til FLAC.
- Hentet ut slutten av spor 8 (Rank1 - It's up to you) og starten av spor 9 (Thrillseekers - Synaesthesia) med Audacity og lagret som 8.wav og 9.wav.
lame -b 128 -f 8.wav -o 8.mp3 lame -b 128 -f 9.wav -o 9.mp3 oggenc -q -1 8.wav -o 8.ogg oggenc -q -1 9.wav -o 9.ogg
- Satte sammen 8.wav og 9.wav i Audacity. I et nytt stereospor under satte jeg sammen 8.mp3 og 9.mp3. Etikettesporet nederst markerer hvor mp3-filene skjøtes sammen. Skjermbildet ser du til høyre.
- Zoomet inn på overgangen mellom 8.wav og 9.wav og Tok skjermbilde. Gjorde det samme med 8.ogg og 9.ogg. Disse skjermbildene la jeg oppå hverandre med det øverste vinduet gjennomsiktig, og tok skjermbildet FLACerBestOgVorbisErLikeBra.png.
Forklaring til bildene
Bildene er skjermskudd fra lydredigeringsprogrammet Audacity, og viser skjøten mellom 2 sanger i forskjellige lydformater. All lyd i denne testen er i stereo, det vil si at hvert par av det som kanskje likner på separate lydspor, egentlig henger sammen som ett stereospor, der øverste spor styrer venstre høyttaler. At de henger sammen er synlig i det høye bildet til høyre (som er snudd på høykant for å få plass). Stereosporet som her var øverst er originalen, mens mp3 var under (nå: venstre).
FLAC er best, men Vorbis høres like bra ut
Som bildet nedenfor viser, passer lydbølgene fra slutten av den første sangen sammen med lydbølgene til den neste. Jeg kan forsikre at det også hørtes slik ut, dvs. overgangen var umerkelig. Det gjelder både wav- og ogg-filene. Nå lurer du kanskje på hvorfor jeg omtaler wav som flac, men wav-filene er bare ekstrakter av flac-filene som jeg rippa. Siden det er kvaliteten vi snakker om, er disse formatene ekvivalente (Wav er ukomprimert og FLAC er en tapsfri kodek). Siden alt stammer fra flac-filene, kan jeg konkludere med at overganger mellom sanger blir perfekt bevart når man ripper en CD til FLAC.
Nærbilde av overgangen, fra øverst til nederst:
Venstre kanal, FLAC
Venstre kanal, Vorbis
Høyre kanal, FLAC
Høyre kanal, Vorbis
Den store overraskelsen var Ogg Vorbis' overlegenhet over mp3. Mens mp3-filene ble kodet med 128 kb/s, noe som er ganske typisk, ble ogg-filene kodet med laveste kvalitetsnivå (-1), noe som resulterte i henholdsvis 54,4 og 56,2 kb/s. Ingen ville finne på å kode mp3 med så lav bitrate (bortsett fra youtube tenker jeg), og jeg skal innrømme at kvaliteten ble hørbart dårligere, men like fullt: Ikke en plancktid glipp i overgangen mellom sangene med Ogg Vorbis. Med tanke på at både Vorbis og mp3 bygger på diskret kosinustransformasjon, ble jeg litt overrasket, selv om alle vet at Ogg Vorbis er bedre enn mp3. Uansett er det viktigste for meg å unngå glipp i overgangen mellom sangene. Det er, i motsetning til all annen snikksnakk om lydkvalitet, så påfallende at man skvetter til selv om man ikke hører godt etter eller er i støyende omgivelser.
mp3-formatets akilleshæl
- Tidspunkt for start og slutt er udefinert
- Pre-ekko og post-ekko skaper grums henholdsvis på starten og slutten. Dette skyldes at komprimeringsalgoritmen, diskret kosinustransformasjon, ikke takler skarpe kontraster. Det er også derfor skarpe kontraster i et JPG-bilde blir grumsete.
Resultatet er at hele lydfila blir lenger enn den skulle vært, og at det er umulig å gjette presist hvor den egentlig skulle ha starta og slutta. Noen dekodere er bedre til å gjette enn andre; det som høres bra ut på musikkspilleprogrammet ditt, er kanskje noe annet for CD-brenneprogrammet for eksempel. Heldigvis for meg, gjettet Audacitys dekoder dårlig nok til at jeg fikk demonstrert fenomenet med disse bildene.
OPPDATERING 13. desember 2009 05:20
Fenomenet har (tydeligvis) ikke noe med bitrate å gjøre: Jeg ville undersøke hvordan mp3 med grisehøy bitrate takler overganger mellom sanger. Bitraten ble dessverre maksimalt 320 kb/s med lame (selv om jeg ba om 1000 kb/s). Den største filstørrelsen lame ville gi meg, fikk jeg med "lame --preset insane". Resultatet ble at med 320 kb/s mp3, fikk pre- og post-ekkoene stort sett så lave amplituder at de ikke syns på bildet (lavere enn et piksel), men like fordømt: Glippen i overgangen har akkurat like lang varighet.
Trykk på bildene nedenfor for å kikke nærmere på saken:
Derfor skal du rippe til FLAC
FLAC er tapsfritt, så ripper du en CD til FLAC, kan du trygt knekke den etterpå. FLAC tar vare på metadata, i motsetning til wav. Hvis tapsfri kompresjon ikke er tingen for deg, husk at alt (unntatt mp2) er bedre enn mp3. Som eksempel har jeg vist at Ogg Vorbis fungerer fortreffelig i overgangen mellom to sanger, mens mp3 er totalt udugelig på dette. Hvis du skulle finne på å brenne en lyd-CD, sørg for å bruke "disc at once"-modus (DAO), og ikke "track at once" (TAO). Det siste fører til 2 sekunders pause mellom hvert spor.
Raskeste måte å bytte to tall
Tema: Vitenskap; sjanger: Artikler
Skrevet av Andreas Nordal den 12. oktober 2009 kl 03:47:21; Kommentarer: 8
Å bytte om verdiene på to tall er en problemstilling som man ofte kommer over når man programmerer. Det er en viktig del av mange algoritmer, særlig sorteringsalgoritmer, og selvfølgelig en masse andre som man ikke skulle tro hadde noe med bytting av tall å gjøre. Dessuten er det en typisk operasjon som dataprogrammet kanskje gjør veldig mange ganger. Dette er så enkelt og viktig at det fins liten unnskyldning for å gjøre det feil.
Testprogram
Jeg har testet de 4 metodene i C/C++ som jeg syns var mest aktuelle (i håp om å finne den raskeste), samt 3 assembly-modifikasjoner av disse. Til sammen 7 tester nummerert fra 0 til 6. Følgende kildekode i C/C++ vil, som vi straks skal se, kunne kompileres til 4 forskjellige programmer.
/* testbenk.c */
#include <stdio.h>
#include <inttypes.h>
#ifdef __cplusplus
# include <algorithm> //std::swap
#endif
int main(){
#ifdef SWAP
int a=666, b=13;
register int32_t i=0;
do{//Bytt om a og b 2^32 ganger
# if SWAP==0
a ^= b;
b ^= a;
a ^= b;
# elif SWAP==1
# ifndef __cplusplus
# error "Dette er C++"
# endif
std::swap(a, b);
# elif SWAP==2
int temp = a;
a = b;
b = temp;
# elif SWAP==3
register int temp = a;
a = b;
b = temp;
# endif
}while(++i);
printf("%d %d\n", a, b);
#endif //defined SWAP
return 0;
}
Gransking av assembly
Når vi kompilerer, la oss gå veien om assembly, og titte på hva den stakkars prosessoren plages med:
gcc -S -DSWAP=0 testbenk.c -o swap0.s g++ -S -DSWAP=1 testbenk.c -o swap1.s gcc -S -DSWAP=2 testbenk.c -o swap2.s gcc -S -DSWAP=3 testbenk.c -o swap3.s
Her ser vi utdrag av hva kildekoden koker ned til av instruksjoner i hvert av de 4 tilfellene. Merk at assemblykode er forskjellig fra maskin til maskin; disse utdragene er fra den første testen (se resultater). Det som har med tallbytting å gjøre er markert med feit skrift.
Utdrag fra swap0.s:
movl $666, -8(%rbp)
movl $13, -4(%rbp)
movl $0, -20(%rbp)
.L2:
movl -4(%rbp), %eax
xorl %eax, -8(%rbp)
movl -8(%rbp), %eax
xorl %eax, -4(%rbp)
movl -4(%rbp), %eax
xorl %eax, -8(%rbp)
addl $1, -20(%rbp)
cmpl $0, -20(%rbp)
jne .L2
Utdrag fra swap1.s:
_ZSt4swapIiEvRT_S1_:
pushq %rbp
movq %rsp, %rbp
movq %rdi, -24(%rbp)
movq %rsi, -32(%rbp)
movq -24(%rbp), %rax
movl (%rax), %eax
movl %eax, -4(%rbp)
movq -32(%rbp), %rax
movl (%rax), %edx
movq -24(%rbp), %rax
movl %edx, (%rax)
movq -32(%rbp), %rdx
movl -4(%rbp), %eax
movl %eax, (%rdx)
leave
ret
movl $666, -4(%rbp)
movl $13, -8(%rbp)
movl $0, -20(%rbp)
.L4:
leaq -8(%rbp), %rsi
leaq -4(%rbp), %rdi
call _ZSt4swapIiEvRT_S1_
addl $1, -20(%rbp)
cmpl $0, -20(%rbp)
setne %al
testb %al, %al
jne .L4
Utdrag fra swap2.s:
movl $666, -12(%rbp)
movl $13, -8(%rbp)
movl $0, -20(%rbp)
.L2:
movl -12(%rbp), %eax
movl %eax, -4(%rbp)
movl -8(%rbp), %eax
movl %eax, -12(%rbp)
movl -4(%rbp), %eax
movl %eax, -8(%rbp)
addl $1, -20(%rbp)
cmpl $0, -20(%rbp)
jne .L2
Utdrag fra swap3.s:
movl $666, -8(%rbp)
movl $13, -4(%rbp)
movl $0, -20(%rbp)
.L2:
movl -8(%rbp), %edx
movl -4(%rbp), %eax
movl %eax, -8(%rbp)
movl %edx, -4(%rbp)
addl $1, -20(%rbp)
cmpl $0, -20(%rbp)
jne .L2
Optimalisering av assembly
swap4.s: Når det fornuftstridig viste seg under testene at såkalt registerswap var treigere enn vanlig temp-swap, tydet det på at koden i swap3.s ikke var optimal. Like fullt, det er mulig å se at swap3.s burde ha vært raskere enn swap2.s. Et bevis for dette er at ved å gjøre om "-8(%rbp)" til "-12(%rbp)" og "-4(%rbp)" til "-8(%rbp)" i swap3.s, og å variere bruken av registere litt i swap2.s, oppnår vi at den eneste forskjellen mellom disse 2 filene er 2 linjer ekstra i swap2.s, samtidig som virkemåten til begge programmene er bevart:
; swap2.s (modifisert)
|
; swap3.s (modifisert) aka swap4.s
|
Den modifiserte swap3.s ble lagret som swap4.s.
5: En skulle kanskje tro at xchg (exchange) hørtes ut som en ideell instruksjon for vårt formål. Med utgangspunkt i swap4.s lagde jeg swap5.s:
; swap5.s
movl -12(%rbp), %eax
xchgl -8(%rbp), %eax
movl %eax, -12(%rbp)
6: Ved hjelp av "inc" i stedet for "add" og å bruke registeret eax som tellevariabel, ble swap4.s forbedret til swap6.s:
movl $666, -12(%rbp)
movl $13, -8(%rbp)
movl $0, %eax
.L2:
movl -12(%rbp), %edx
movl -8(%rbp), %ebx
movl %ebx, -12(%rbp)
movl %edx, -8(%rbp)
incl %eax
cmpl $0, %eax
jne .L2
Testprosedyre
gcc -s swap0.s -o swap0 g++ -s swap1.s -o swap1 gcc -s swap2.s -o swap2 gcc -s swap3.s -o swap3 gcc -s swap4.s -o swap4 gcc -s swap5.s -o swap5 gcc -s swap6.s -o swap6 gcc -s swap7.s -o swap7
Hadde det ikke vært for at vi må bruke g++ i ett tilfelle:
for i in *.s; do gcc -s $i -o ${i%.?}; done
bash$ time ./swap1
666 13 #Uinteressant: Programmet virker.
real 0m27.270s #Uinteressant: Så lang tid det faktisk tok.
user 0m27.226s #Interessant: CPU-tid i user-mode.
sys 0m0.040s #Interessant: CPU-tid i protected-mode.
Kjøretiden ble målt som i eksempelet over. Som antydet, er det summen av CPU-tid som teller, altså user + sys. Når det står flere tall i samme celle i tabellen, er det fordi jeg har testet flere ganger. Tiden er i sekunder.
Resultater
| Maskin | 0: XOR-swap | 1: std::swap | 2: temp-swap | 3: registerswap (gcc) | 4: registerswap (fiksa) | 5: xchg-swap | 6: Så bra jeg kan i assembly |
|---|---|---|---|---|---|---|---|
| ny laptop: Intel Core 2 Duo T8100 2,1GHz (2 kjerner), GCC 4.3.2, Linux 2.6.27.29 x86_64 | 34,226s 34,066s | 27,266s 27,306s | 11,629s 11,805s | 12,485s 12,565s | 9,737s 9,781s | 72,569s 72,817s | 9,465s 9,397s |
| gammel stasjonær: AMD Athlon XP 2600+ 1,9GHz, GCC 4.3.0, Linux 2.6.27.25 i686 | 39,19s | 47,20s | 14,16s | 16,17s | 12,41s | 49,47s | 8.93s |
| ny server: Intel Xeon 3,2 GHz (4 prosessorer), GCC 4.2.4, Linux 2.6.24-24 i686 | 20,48s 20,35s | 40,77s 40,44s | 10,61s 10,72s | 8,18s 8,26s | 6,92s 7,13s | ||
| gammel server: Intel Pentium III Coppermine 936MHz (2 prosessorer), GCC 4.1.1, Linux 2.6.18 i686 | 87,34s 87,38s | 111,22s 109,07s | 36,85s 36,83s | 23,39s 23,79s | 18,41s 18,40s | ||
| gammel laptop: Intel Pentium 4 2,0GHz, GCC 4.3.2, Linux 2.6.27 i686 | 116,471s 116,219s | 105,799s 100,218s | 40,050s 37,802s | 28,274s 27,650 | 22,333s 21,786s | ||
| server: Intel Xeon 2,83 GHz, GCC 4.2.4, Linux 2.6.24 | 28,12s | 23,88s | 10,16s | 8,74s | 7,71s |
Diskusjon
0 (XOR-swap): Så elegant, men akk så treigt. XOR-swap fører til stans i prosessorens samlebånd, fordi hver instruksjon må vente på resultatet av den forrige. Grunnen til at moderne prosessorer kan ha klokkefrekvenser over et par hundre MHz er bruken av samlebånd.
1 (std::swap): Et funksjonskall tar ekstra tid, og indirekte adressering gir lang kode. Programmet swap1 ble forresten 8 byte større enn hver av de andre. Std::swap er rett og slett dømt til å være treig.
2-4 (temp-swap vs registerswap): Jeg kan ikke kåre noen vinner mellom disse 2. Selv om all fornuft sier at det skal være raskere å bruke et register til mellomlagring framfor å bruke RAM, stemte det ikke med mitt program i C. Jeg har vist at dette skyldes GCCs ugunstige plassering av variablene på stakken, og at registerswap faktisk ble raskere enn temp-swap ved å plassere variablene som i temp-swap. Ikke vet jeg om fenomenet skyldes cache-kollisjon eller hva det er. Det ser ut til å være reproduserbart på flere maskiner, men det hele kan jo være en tilfeldighet ved akkurat mitt program.
5 (xchg): Er dette en ubrukelig instruksjon?
6 (Så bra jeg kan i assembly): Dette vil funke i alle fall på i386.
Ring gratis med mobilen
Tema: Programvare; sjanger: Artikler
Skrevet av Stig Magnus Halvorsen den 3. oktober 2009 kl 03:31:48; Kommentarer: 0
Statistikk fra etter lansering av den første iPhone viser at det har vært en liten eksplosjon i bruken av internett på mobiltelefoner. Spesielt nå som de fleste nye telefoner kommer med innebygd WiFi og flere leverandører gir mye eller ubegrenset mobilnett for pengene. Hvorfor ikke da utnytte dette fullt ut? Gjør en det, vil det å ringe og å sende SMS bli nesten eller helt gratis!
Skype er et program som brukes til IP-telefoni og direktemeldinger. Ligner på MSN, men fokuset har ligger på funksjonen om å kunne ringe hverande gratis. Programmet har eksistert for datamaskin siden 2003, men er i senere år også blitt lansert for mobiltelefoner og bærbare håndholdte enheter. Dette i tillegg til å skaffe deg en skypekonto på skype.com er mer eller mindre alt du trenger!
Skype for mobil fungerer på iPhone, telefoner med Windows Mobile, Nokia N800/N810 og PSP. Skype er også til en rekke andre telefoner, sjekk om din telefon kan ha Skype Lite
Det er noen bakdeler med dette. En må installere et ekstra program på mobilen, en må enten ha et internettvennlig abonnement eller være innenfor WiFi-sone og de du vil ringe må også ha skype og være pålogget. Men om dette hadde blitt en standard med tiden, så vil det kun være til gode for almennheten. Det betyr bedre gratis kommunikasjon til folket og at abonnementstilbudene blir betraklige bedre pga konkurranse.