mboost-dp1
low level programmering- den snart tabte kunst?
arne_v (192) skrev:Jeg er heller ikke for begejstret for koden. Brugen af ftell, multiple fgets gør koden unødigvendigt svær at læse efter min mening.
Det er et underligt scenarie han har. Koden skal være binær-kompatibel, dvs. \0 kan godt forekomme og han kan derfor ikke bruge (de fleste) string operationer. Jeg ved så ikke hvorfor man så skulle være interesseret i hvor mange "linjer" (\n) der skulle være i en binær fil. Ydermere mener han at det også skal være lynhurtigt (så han skriver det med vilje grimt).
Det ville være meget simplere hvis han talte linjer/linjelængde og sådan, og kun gemte positionen af den længste linje undervejs. Så skulle han godt nok læse linjen en gang til og i worst case bruge ca. dobbelt så lang tid, men det ser jeg umiddelbart ikke som et så stort problem når det alligevel er rimelig hurtigt (de færre allokeringer man skal lave gør det måske hurtigere alligevel).
#201
Han skriver jo netop hvorfor:
Men jeg synes stadigvæk det er et godt eksempel på hvordan at C er mere verbose end andre sprog.
Han skriver jo netop hvorfor:
Tino skrev:My sinister side goal is showing how complex the C code has to be in order to get performance near C++. It is possible to write a simpler version in C that is 20% faster for /usr/share/dict/words, but it is then 4x slower for the random files. It would also be possible to write a faster non-portable version using memory mapping, but can’t really call that simple. C++ has both readability and speed. If I missed some obvious portable optimization in the C code, let me know…
Men jeg synes stadigvæk det er et godt eksempel på hvordan at C er mere verbose end andre sprog.
#202
Det er jo meget prisværdigt at han gerne vil lave portabel C kode.
Det ville være endnu mere prisværdigt hvis hans kode faktisk var portabel.
Jeg vil formode at den virke rkorrekt på hans Fedora.
Hvis man nu prøver med den her tekst fil:
A
BB
CCC
DD
E
(vi er vel enige om at der er 5 linier og at længste linie er 3 tegn)
Så giver GCC på Win32:
Og DEC C på OpenVMS:
Det er jo meget prisværdigt at han gerne vil lave portabel C kode.
Det ville være endnu mere prisværdigt hvis hans kode faktisk var portabel.
Jeg vil formode at den virke rkorrekt på hans Fedora.
Hvis man nu prøver med den her tekst fil:
A
BB
CCC
DD
E
(vi er vel enige om at der er 5 linier og at længste linie er 3 tegn)
Så giver GCC på Win32:
File had total of 6 lines.
Longest line found on line 3 with 5 characters.
The line was: CCC
Og DEC C på OpenVMS:
File had total of 3 lines.
Longest line found on line 1 with 13 characters.
The line was: ABBCCCD
#204
Jeg pastede dem ind i systemets standard editor og gemte.
Windows: notepad
Og pussigt nok siger den 6 linier uanset om der er linie skift efter E linien eller ej.
OpenVMS: EVE
Og det er ganske rigtigt ikke en \n delimited fil.
Men det er tekst filer man gemmer i native VMS editorer altså ikke.
Jeg pastede dem ind i systemets standard editor og gemte.
Windows: notepad
Og pussigt nok siger den 6 linier uanset om der er linie skift efter E linien eller ej.
OpenVMS: EVE
Og det er ganske rigtigt ikke en \n delimited fil.
Men det er tekst filer man gemmer i native VMS editorer altså ikke.
#206
Ligesom rigtigt mange systemer der ikke er *nix eller MS: et counted format.
2 bytes med linie længden i binært format (little endian)
linien
0 eller 1 nul bytes for at padde til et lige antal bytes
Det er særdeles usmart at forsøge at læse en tekst fil på VMS som en binær fil.
Ligesom rigtigt mange systemer der ikke er *nix eller MS: et counted format.
2 bytes med linie længden i binært format (little endian)
linien
0 eller 1 nul bytes for at padde til et lige antal bytes
Det er særdeles usmart at forsøge at læse en tekst fil på VMS som en binær fil.
#VMS tekst filer
Det angivne format er iøvrigt kun 1 ud af 5 formater for linier.
Der understøttes:
var: counted med længde prefix
vfc: counted med længde prefix og ekstra control bytes
stream: delimited med CR LF
stream_lf : delimited med LF
stream_cr : delimited med CR
Det brugte record format står i filens meta data.
Men default for de editorer som kommer med systemet er var formatet.
Diverse andre tools har andre defaults.
Det angivne format er iøvrigt kun 1 ud af 5 formater for linier.
Der understøttes:
var: counted med længde prefix
vfc: counted med længde prefix og ekstra control bytes
stream: delimited med CR LF
stream_lf : delimited med LF
stream_cr : delimited med CR
Det brugte record format står i filens meta data.
Men default for de editorer som kommer med systemet er var formatet.
Diverse andre tools har andre defaults.
#pointe
Og nu er vi faktisk ved at være tilbage ved noget af det som det hele startede med.
Portabel kode kan ikke antage at tekst filer kan læses binært med linieskift ved LF.
Linier er en abstraktion og tit kan man nøjes med at arbejde med abstraktionen, men laver man noget specielt så kan det være nødvendigt at vide hvordan den abstraktion faktisk er implementeret.
Og skal kode være portabelt skal man vide noget om forskellige implementationer.
Eksistensen af systemer med linier der ikke er i delimited format er derfor en low level ting som man bør kende ligesom:
* eksistensen af systemer som bruger ones complement fremfor twos complement for binære integers
* eksistensen af systemer hvor antal bits i en byte ikke er 8
* eksistensen af systemer hvor antal bits i integers ikke er et multipla af antal bits i bytes
* forskellen på big endian og little endian integer formater
* floating point egenskaber
* eksistensen af non-IEEE floating point formater
o.s.v.
Og nu er vi faktisk ved at være tilbage ved noget af det som det hele startede med.
Portabel kode kan ikke antage at tekst filer kan læses binært med linieskift ved LF.
Linier er en abstraktion og tit kan man nøjes med at arbejde med abstraktionen, men laver man noget specielt så kan det være nødvendigt at vide hvordan den abstraktion faktisk er implementeret.
Og skal kode være portabelt skal man vide noget om forskellige implementationer.
Eksistensen af systemer med linier der ikke er i delimited format er derfor en low level ting som man bør kende ligesom:
* eksistensen af systemer som bruger ones complement fremfor twos complement for binære integers
* eksistensen af systemer hvor antal bits i en byte ikke er 8
* eksistensen af systemer hvor antal bits i integers ikke er et multipla af antal bits i bytes
* forskellen på big endian og little endian integer formater
* floating point egenskaber
* eksistensen af non-IEEE floating point formater
o.s.v.
Ikke det mest naturlige valg, taget i betragtning af hvad Carriage Return faktisk oprindeligt var til.arne_v (217) skrev:MacOS pre-X og VMS med stream_cr format bruger CR til at adskille linier.
Det er jo nærmere specialiseret viden. Hvis alle skulle vide alting om alle operativ systemer, ville de aldrig få tid til at lære det som de faktisk skal arbejde med (eller få tid til faktisk at lave noget!).arne_v (215) skrev:Eksistensen af systemer med linier der ikke er i delimited format er derfor en low level ting som man bør kende ligesom: [...]
Jeg kan ikke se hvordan det at OpenVMS ikke bruger \n som standard, er relevant for en udvikler der ikke arbejder med OpenVMS.
Af de ting du har nævnt, er der jo intet der ikke kan læres hurtigt, når man skal bruge dem.
#218
Det kritiske er ikke at kende alle detaljerne.
Det kritiske er at forstå problem stillingen, således at man ikke designer programmer udfra nogle forkerte antagelser.
Det tager måske kun en time at sætte sig ind i emnet, men hvis det koster tusinder af timer at redesigne og reimplementere, så er det jo ikke morsomt.
Det kritiske er ikke at kende alle detaljerne.
Det kritiske er at forstå problem stillingen, således at man ikke designer programmer udfra nogle forkerte antagelser.
Det tager måske kun en time at sætte sig ind i emnet, men hvis det koster tusinder af timer at redesigne og reimplementere, så er det jo ikke morsomt.
Så du mener at folk skal lære om den platform de skal arbejde med, før de arbejder med den.arne_v (219) skrev:Det tager måske kun en time at sætte sig ind i emnet, men hvis det koster tusinder af timer at redesigne og reimplementere, så er det jo ikke morsomt.
Hey, det lyder meget som mit argument om at man skal specialisere sig i det man arbejder med!
Windcape (221) skrev:Så du mener at folk skal lære om den platform de skal arbejde med, før de arbejder med den.
Windcape (221) skrev:Hey, det lyder meget som mit argument om at man skal specialisere sig i det man arbejder med!
Ja.
Men de skal også være opmærksom på nogle problem stillinger i forbindelse med det originale design og ikke vente indtil man støder på en situtation hvor designet ikke duer.
arne_v (222) skrev:Men de skal også være opmærksom på nogle problem stillinger i forbindelse med det originale design og ikke vente indtil man støder på en situtation hvor designet ikke duer.
Hvilket er grunden til at jeg mener, at man godt kan være en god high level programmør, uden low level viden. Tilgengæld har jeg svært ved at gode low level programmøre, som der ikke har high level viden.
God high level programmering handler i høj grad om at bygge vedligeholdelses-venligt kode. Eg. design patterns mm. Det handler om at bygge kode, der understøtter ændringer af det uforudseelige. Det kræver ikke noget low level viden at erkende at man ikke kender alle scenarier og potientielle platforme.
Garvede low level folk derimod har ofte større problemer. De har en tendens (ligesom high level folk) til ikke at videreuddanne sig og holde sig ajour med den datalogiske/akademiske verden. Det betyder at de programmerer som de gjorde for 40 år siden og de har en tendens til at gå amok i "premature optimizations". De laver ofte kode der er umuligt at vedligeholde, er lang tid om det og koster i det hele taget ofte flere penge end de burde!
Lad os konkludere at folk burde udvikle sig indenfor deres fag (uanset hvilket) *mere* end de generelt gør! Jeg er faktisk ligeglad med om det er low level eller high ting de studerer. Bare de bliver ved med at studere.
illishar (224) skrev:Hvilket er grunden til at jeg mener, at man godt kan være en god high level programmør, uden low level viden.
En gang imellem vil man ende op med nogle dårlige designs eller fejlagtig kode fordi det høje abstraktionsniveau i nogle konkrete situationer ikke matcher virkeligheden særligt godt.
illishar (224) skrev:God high level programmering handler i høj grad om at bygge vedligeholdelses-venligt kode.
Det er normalt endnu mere vigtigt ved low level programmering. Som oftest er det langt mindre sekvindlysende end noget high level.
illishar (224) skrev:Lad os konkludere at folk burde udvikle sig indenfor deres fag (uanset hvilket) *mere* end de generelt gør!
Helt enig.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund