mboost-dp1
Learn Assembly First, Last, Or Never?
But if you want to really be a top programmer, you are going to have to confront it sooner or laterlolno
De der gamle fjolser som gatekeeper alting er til at dø af grin af.
Hvis man vil skrive højkvalitets kode, i et givent sprog, bør man have en hvis forståelse for hvordan en computer faktisk eksekver koden i sidste ende. Der er skræmmende mange udviklere der ikke har den fjerneste anelse. Det er let at falde i den tro at en moderne computer har uendelig meget RAM og uendelig hurtig CPU, og det er da også praktisk talt den måde det opleves i dag. Men, hvis man vil skrive høj-kvalitets kode, er man nød til, blandt andet, at forstå hvordan en computer virker.
... og for at lære det kan assembler da være en mulighed. Jeg skal ikke kunne sige om det er den bedste måde. Men at skrive et program eller to i et maskinnært sprog er bestemt en god øvelse.
... og for at lære det kan assembler da være en mulighed. Jeg skal ikke kunne sige om det er den bedste måde. Men at skrive et program eller to i et maskinnært sprog er bestemt en god øvelse.
Nej. Du har brug for at forstå hvordan det sprog du bruger fungere, og måske hvordan sprogets kompiler håndtere din kode, ikke mere.larsp (3) skrev:Hvis man vil skrive højkvalitets kode, i et givent sprog, bør man have en hvis forståelse for hvordan en computer faktisk eksekver koden i sidste ende.
Programmører der forsøger at være smartere end kompileren skriver ikke højkvalitetskode -- de skriver skrammel
Programmering handler om at skrive kode der er letlæselig, nemt at vedligeholde, og har en god arkitektur så man kan tilføje ny funktionalitet uden at skabe bugs in det eksisterende produkt.
Hvorimod performance (og CPU/memory usage) er stort set irrelevant for 99.99% af alt software der skrives i dag.
#4 Hvis du kopierer en buffer 17 gange i noget IO håndtering, fordi du vil lave letlæselig og elegant kode, dumper du, mester. For det vil reducere IO performance unødvendigt. Zero copy netværks drivere er en ting for en god årsag, og det er ikke nemt.
Ja, i den kode run-of-the-mill programmører laver i dag behøver man ikke tænke på den slags. Men jeg talte om højkvalitets kode, og skulle nok have tilføjet, højkvalitets "system" kode.
Ja, i den kode run-of-the-mill programmører laver i dag behøver man ikke tænke på den slags. Men jeg talte om højkvalitets kode, og skulle nok have tilføjet, højkvalitets "system" kode.
#5
I 99.99% af alt kode der skrives i dag er den slags bekymring slet ikke nødvendigt.
Bedre at du lærer det når det er nødvendigt, og imens fokusere på at lære at skrive letlæselig og elegant kode.
Derudover så ville en god programmør abstrahere sådan kode ud så man slet ikke risikere at kopiere bufferen, hvis sprogets IO APIs ikke gør det som standard.
I 99.99% af alt kode der skrives i dag er den slags bekymring slet ikke nødvendigt.
Bedre at du lærer det når det er nødvendigt, og imens fokusere på at lære at skrive letlæselig og elegant kode.
Derudover så ville en god programmør abstrahere sådan kode ud så man slet ikke risikere at kopiere bufferen, hvis sprogets IO APIs ikke gør det som standard.
Men f.eks. Python:
vs.
begge dele er letlæseligt, men sidstnævnte er hvad man forventer af en professionel programmør (well, not really, en professionel havde brugt et CSV bibliotek)
import { readFile } from 'fs/promises';
const file = await readFile('myfile.csv'); // entire file in memory
// split line by CRLF, etc.
vs.
import fs from 'fs';
import readline from 'readline'
const fileStream = fs.createReadStream('myfile.csv');
const buffer = readline.createInterface({ input: fileStream, crlfDelay: Infinity })
for await (const line of buffer) {
// ...
}
begge dele er letlæseligt, men sidstnævnte er hvad man forventer af en professionel programmør (well, not really, en professionel havde brugt et CSV bibliotek)
#7
Python?
C:\Work\Python>\Python\Python311\python.exe z1.py
File "C:\Work\Python\z1.py", line 1
import { readFile } from 'fs/promises';
^
SyntaxError: invalid syntax
C:\Work\Python>\Python\Python311\python.exe z2.py
File "C:\Work\Python\z2.py", line 1
import fs from 'fs';
^^^^
SyntaxError: invalid syntax
Python?
C:\Work\Python>\Python\Python311\python.exe z1.py
File "C:\Work\Python\z1.py", line 1
import { readFile } from 'fs/promises';
^
SyntaxError: invalid syntax
C:\Work\Python>\Python\Python311\python.exe z2.py
File "C:\Work\Python\z2.py", line 1
import fs from 'fs';
^^^^
SyntaxError: invalid syntax
#7 Jeg kan heller ikke køre den kode. Også, ; efter import er ikke normal praksis i python. typescript, javascript?
Men det jeg tænker du er ude på, er at undgå at læse hele filen i et hug, og i stedet læse den som stream.
Det er et udmærket eksempel på hvad jeg mener. Hvis man vil skrive kode der skal håndtere meget store filer er det vigtigt at have en forståelse for hvad der sker når man læser en fil. Aka, en forståelse for hvad computeren gør og dens begrænsninger, og ikke bare for hvad sproget semantisk betyder.
Men det jeg tænker du er ude på, er at undgå at læse hele filen i et hug, og i stedet læse den som stream.
Det er et udmærket eksempel på hvad jeg mener. Hvis man vil skrive kode der skal håndtere meget store filer er det vigtigt at have en forståelse for hvad der sker når man læser en fil. Aka, en forståelse for hvad computeren gør og dens begrænsninger, og ikke bare for hvad sproget semantisk betyder.
Sarkasme incomming:
Hay ChatGPT Skriv en "Hello world" script i Assembly og dan en Acsii tegning af en cool kat.:
Selvfølgelig! Her er en "Hello world" script i x86 Assembly, efterfulgt af en ASCII-tegning af en cool kat:
```assembly
section .data
message db 'Hello, world!', 0
section .text
global _start
_start:
; Skriv besked til standard output
mov eax, 4
mov ebx, 1
mov ecx, message
mov edx, 13
int 0x80
; Afslut program
mov eax, 1
xor ebx, ebx
int 0x80
```
ASCII-tegning af en cool kat:
```
/\_/\
( o.o )
> ^ <
```
Hvis du vil køre Assembly-koden, skal du først oversætte den til et kørbart program ved hjælp af en assembler, f.eks. NASM. Når du har genereret den eksekverbare fil, kan du køre den på dit system.
Bemærk, at denne kode er til x86-arkitekturen og vil variere afhængigt af den specifikke assembler og operativsystem, du bruger.
Hay ChatGPT Skriv en "Hello world" script i Assembly og dan en Acsii tegning af en cool kat.:
Selvfølgelig! Her er en "Hello world" script i x86 Assembly, efterfulgt af en ASCII-tegning af en cool kat:
```assembly
section .data
message db 'Hello, world!', 0
section .text
global _start
_start:
; Skriv besked til standard output
mov eax, 4
mov ebx, 1
mov ecx, message
mov edx, 13
int 0x80
; Afslut program
mov eax, 1
xor ebx, ebx
int 0x80
```
ASCII-tegning af en cool kat:
```
/\_/\
( o.o )
> ^ <
```
Hvis du vil køre Assembly-koden, skal du først oversætte den til et kørbart program ved hjælp af en assembler, f.eks. NASM. Når du har genereret den eksekverbare fil, kan du køre den på dit system.
Bemærk, at denne kode er til x86-arkitekturen og vil variere afhængigt af den specifikke assembler og operativsystem, du bruger.
Jeg har ingen ide om hvad computeren gør, elller hvordan filebuffers fungere. Det er simpelthen ikke nødvendigt.larsp (9) skrev:Det er et udmærket eksempel på hvad jeg mener. Hvis man vil skrive kode der skal håndtere meget store filer er det vigtigt at have en forståelse for hvad der sker når man læser en fil. Aka, en forståelse for hvad computeren gør og dens begrænsninger, og ikke bare for hvad sproget semantisk betyder.
Men det kræver ikke meget hjerne at forstå at 1GB data i memory ikke rigtigt fungere. De fleste lærer det ved at deres program er super langsomt og crasher :P
#9 og #10
Angående eksemplet med store filer, så er det rigtigt at problemet med at læse en meget stor fil fra disk til memory ikke kræver den store viden om OS IO subsystemer (hvilket dog ikke har meget med assembler programming at gøre).
Men dem med viden omkring OS memory subsystemer (hvilket dog heller ikke har meget med assembler programming at gøre) husker at overveje den tredie løsning.
1) læs hele filen til memory med en IO funktion og process det hele i et hug
2) læs klumper (linier/blokke) af filen til memory med en IO funktion og process en klump af gangen
3) map filen til memory og process som om det var memory og lad OS paging læse fra fil til memory som nødvendigt
Afhængig af fil størrelse, OS etc. er der en ganske pæn sandsynlighed for at #3 er det hurtigste.
Angående eksemplet med store filer, så er det rigtigt at problemet med at læse en meget stor fil fra disk til memory ikke kræver den store viden om OS IO subsystemer (hvilket dog ikke har meget med assembler programming at gøre).
Men dem med viden omkring OS memory subsystemer (hvilket dog heller ikke har meget med assembler programming at gøre) husker at overveje den tredie løsning.
1) læs hele filen til memory med en IO funktion og process det hele i et hug
2) læs klumper (linier/blokke) af filen til memory med en IO funktion og process en klump af gangen
3) map filen til memory og process som om det var memory og lad OS paging læse fra fil til memory som nødvendigt
Afhængig af fil størrelse, OS etc. er der en ganske pæn sandsynlighed for at #3 er det hurtigste.
arne_v (14) skrev:
Men dem med viden omkring OS memory subsystemer (hvilket dog heller ikke har meget med assembler programming at gøre) husker at overveje den tredie løsning.
1) læs hele filen til memory med en IO funktion og process det hele i et hug
2) læs klumper (linier/blokke) af filen til memory med en IO funktion og process en klump af gangen
3) map filen til memory og process som om det var memory og lad OS paging læse fra fil til memory som nødvendigt
Afhængig af fil størrelse, OS etc. er der en ganske pæn sandsynlighed for at #3 er det hurtigste.
Glimrende ide til et lille skriv.
https://www.vajhoej.dk/arne/articles/mmf.html
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