Forum libero

Scritto da:
> > Il problema di questi progetti è sempre quello... cosa te ne fai?
>
> > supporta i programmi che ti servono?
>
> > Se uno ti manda un file Excel/Word sei in grado di aprirlo e lavorarci?
>
> Perfettamente d'accordo, ma il senso di un sistema operativo scritto in assembler per essere ultrasuperveloce dovrebbe essere un altro.

Sarebbe più veloce solo nelle system call, ma (a parte probabilmente minimi guadagni) non ti farebbe girare i programmi più velocemente, a meno che pure quelli non siano scritti in assembler.

> Se riesce ad essere accettabilmente veloce su un 486 (che all'epoca era dannatamente veloce, con Windows 3.1) chissà che può fare su un computer odierno o di dieci anni fa. Tempo fa ho provato a convertire un bluray con MakeMKV su un portatile del 2008 con Windows 7, e ci ha messo 14 ore: una versione di MakeMKV per Kolibri OS quanto impiegherebbe?

Secondo te MakeMKV passa più tempo a fare system call tipo (leggimi i prossimi 50MByte di dati in memoria) o ad elaborare i dati che sono in memoria per fare la conversione? Secondo me è la seconda... quindi sì, magari la chiamata per leggere 50MByte in ram durerebbe 3 millisecondi invece di 4... ma la conversione di quei 50 mega durerebbe 5 minuti come prima.

Tieni conto che i compilatori odierni (per esempio quello del C/C++) sono estremamente "furbi" e sono in grado persino di convertire il codice che hai scritto in istruzioni assembly che sono (a volte) anche più veloci di quelle che scriveresti tu se lo facessi a mano (a meno che tu non sia un maestro di assembly con un'approfondita conoscenza a livello hardware della macchina e di tutti i trucchi e trucchetti per riscrivere quello che vuoi fare in modo da sfruttare l'immensità di istruzioni assembly che ti fornisce l'architettura x86).
Questi sviluppatori sono stati creati nell'arco di decenni e sono stati ottimizzati fino all'osso. Non credo che uno sviluppatore che scrivesse oggi tutto in assembly riuscirebbe a creare codice più veloce.

Semmai il problema è che la gran parte dei software è ancora mono-threading, nonostante le CPU di oggi siano multi-core.
Ti faccio un esempio... un programma che ho fatto io funziona in due modalità: monothread e multithread. L'ho fatto così che l'utente possa scegliere in quale modalità farlo funzionare e vedere le differenze. Lo scopo di questo programma è scaricare delle pagine HTML dal WEB e convertirle in file PDF. Risultato: la versione multithread, su una CPU con 8 thread, è quasi 8 volte più veloce di quella mono-thread... a parità di RAM, CPU, e tutto. Questo significa che quello che la versione monothread fa in 8 ore, la multithread la fa in una. Il codice è quasi lo stesso, l'unica cosa che cambia è che nella versione multithread uso TUTTA la CPU anziché solo 1/8.

Un altro problema è che a volte i programmi potrebbero fare cose in contemporanea, ma le fanno invece sequenzialmente. Tipo... immagina di creare un installer che prima scarica dei pacchetti e poi li installa. Perché non fare il programma in modo che incominci l'installazione dei pacchetti già scaricati PRIMA di aspettare il download di pacchetti che non c'entrano nulla? Tanto durante il download la CPU è quasi del tutto libera... perché non sfruttare quei tempi morti?

Oppure, metti che hai una sorta di Wizard e stai aspettando che finisca un download, dopo nel Wizard ti trovi una pagina in cui ti chiede, chessò, di elbaborare qualcosa in un certo modo e devi scegliere come farlo... ecco, mentre aspetti il download il programma potrebbe fare quell'elaborazione per tutti i casi previsti e poi dirti semplicemente "quale scegli di voler tenere?"

Una volta ho ottimizzato una query su un database che impiegava _mezz'ora_ a completarsi (erano migliaia di query in realtà per la creazione di migliaia di fatture da inviare ai clienti)... dopo che ci ho messo mano io lo stesso lavoro lo faceva in 5 minuti. E questo senza nemmeno annusare l'assembly da lontano.

Un'altra volta ho messo mano ad un programma che inviava migliaia di etichette a stampanti di una grossa azienda, i file con i dati da inviare alle stampanti venivano messi in una cartella condivisa e c'era un programma che una volta ogni 5/10 secondi leggeva quella cartella e inoltrava le etichette alla stampante giusta.
Risultato: quando qualcuno voleva stampare un etichetta premeva sul pulsante "Stampa" e poi poteva succedere che poteva dover aspettare anche 10 secondi prima che l'etichetta arrivasse alla stampante. Può sembrarti poco ma quando ne devi stampare tante secca e non poco...

Io ho rifatto il programma sfruttando una funzionalità di Windows che è in grado di avvertirti quando una data cartella subisce una modifica (tipo quando qualcuno ci scrive dentro un file). In questo modo ora le etichette vengono stampate immediatamente, senza ritardi, e sono tutti contenti nonostante la mole di lavoro sia la stessa.

Chiaro che non puoi farlo sempre, e che spesso il cliente ti paga troppo poco per stare a sbatterti su queste cose (non puoi dirmi fammi questo lavoro in 1 ora quando solo per ottimizzarlo magari mi servono 3 ore)... quello che voglio dire è che spesso il collo di bottiglia è da un'altra parte. Poi.. non ha nessun senso velocizzare qualcosa che richiede 3 millisecondi ad eseguirsi... anche se riesci a farla durare 0.3 millisecondi, a meno che non la chiami migliaia di volte in loop non ha alcuna importanza. 3 millisecondi o 0.3 millisecondi per te avranno la stessa durata.

Quindi, la prossima volta che il SO che usi ti sembra lento... chiediti se magari gli sviluppatori hanno scazzato qualcosa o potevano fare le cose in modo migliore. Non sempre si può, ma molte volte sì.

> Certo che se gli sviluppatori non capiscono che al loro sistema puoi dare uno scopo come questo, rimane un affascinante giocattolino con cui scrivere file di testo e navigare in rete con un browser non aggiornatissimo (suppongo).

Il problema dell'assembly (oltre ad essere complicato da gestire a livello di programmazione e poi mantenimento, bugfix, ecc) è che è legato ad una data architettura. Se domani si passa tutto ad ARM, il loro bravo Kolibri dovranno riscriverselo da zero. Per quello che riguarda Windows basterà quasi solo dire al compilatore "genera codice ARM ora".

> Linux non è più così ostico... ma un po' lo rimane.

Io l'ho buttato via quando mi serviva un programmino stupido che però mi serviva davvero e non potevo installarlo perché le librerie sulla mia distro erano _troppo nuove_ per quel programma.

Ho provato a scaricare i sorgenti, ricompilarlo, ma mi dava sempre errori, ogni volta che ne aggiustavo uno me ne dava altri... non era possibile installare la versione vecchia di quelle librerie perché avrebbero sputtanato tutto il resto di Linux.... a quel punto, dopo averci perso una giornata intera, ho acceso la macchina Windows, scaricato il file ZIP con il programmino, e ha funzionato nel giro di 3 secondi. Niente lamenti circa librerie mancanti, troppo vecchie o troppo nuove, niente ricompilazioni, niente... è partito e basta.

> Lo uso tutti i giorni dopo l'ennesimo crash di Windows,

Anche io ero passato a Linux dopo che Windows (non ricordo che versione fosse) mi era crasciato e si era portato con sé un pezzo dei miei dati.

Ho installato Linux e tutto sembrava funzionare correttamente.
Poi mi sono reso conto che alcuni file che salvavo erano danneggiati...
Ho preso Memtest86 e ho fatto una scansione della RAM, ed è risultato che un chip della RAM era difettoso... Windows crasciava per quello... mentre Linux non crasciava, si limitava a rovinarmi i dati senza dirmelo. Stavo incolpando Windows di un problema hardware sulla mia macchina e pensavo che invece Linux funzionasse una meraviglia.

> Gimp ormai è come Photoshop di qualche anno fa, il problema è che gli sviluppatori non hanno capito che bisognava farlo uguale, invece hanno voluto fare un programma diverso e uando usi un programma diverso impieghi ore a fare quello che normalmente fai in minuti. Anni fa un tipo aveva fatto una versione di Gimp con i menu come Photoshop, gli sviluppatori non l'hanno accolta bene né sostenuta, in poche parole non hanno capito.

Ora GIMP non lo installerei nemmeno morto... ci sono alternative che hanno un prezzo onesto e fanno tutto quello che mi serve, con un'interfaccia decente... e ci sono pure millemila grafici online che ne consigliano l'uso, tipo i programmi di Affinity. Non ho problemi a pagare un programma se ha un prezzo ragionevole e mi è utile. Sono forse uno dei pochi che si è pure comprato una licenza di WinRAR anche se non ero obbligato a farlo...

**Modificato dall'autore il 22.08.2023 16:19**