Sun Microsystems on Melabit

50 anni con Apple

Wed, 01 Apr 2026 06:00:00 +0000

– La prima immagine di un Apple II pubblicata su Bit, che a cavallo fra la fine degli anni ‘70 e i primi anni ‘80 è stata la più importante rivista italiana dedicata ai personal computer (Bit n. 5, Novembre-Dicembre 1979).

Cinquant’anni fa ero un liceale brufoloso e non avrei saputo dell’esistenza di Apple fino ai primissimi anni ‘80, quando Bit iniziò ad ospitare le prime pagine pubblicitarie dedicate all’Apple II.

– Prima pagina pubblicitaria dedicata ad “Apple Computer” (Bit n. 6, Febbraio 1980, ultima di copertina).

Ma in quegli anni la parte del leone la faceva la sua principale concorrente, MCmicrocomputer, che fin dal primo numero del settembre 1981 dedicò ampio spazio all’azienda californiana.

Nel 1981 un Apple II da 48K con monitor da 11" e un disco floppy costava 5 milioni di lire, più di una FIAT Panda tanto per capirsi. Una cifra fuori dalla portata di uno studente universitario come ero io, che al massimo potevo permettermi un Commodore 64 comprato grazie ad una vincita al Totocalcio.¹

– Listino completo dei prodotti Apple a settembre 1981 (tratto da MC Microcomputer no. 1, Settembre 1981, pagina 84).

Però a Fisica di Apple II ce n’erano parecchi, perché li si poteva usare per costruire i primi strumenti di misurazione automatica o per digitalizzare le immagini.² Bastava fare un giretto nei vari laboratori per trovarne qualcuno, e se si era fortunati si riusciva anche ad usarli quando erano liberi.

Arrivò presto anche uno dei primi Macintosh 128K, che riuscii ad usare solo fugacemente perché venne rubato dopo un paio di giorni.

Poco dopo, al mio primo congresso, mi accorsi che uno degli oratori, Ken Gray, aveva usato il Macintosh per scrivere sia l’articolo che le slide. Fra un centinaio di partecipanti, tutti con i testi scritti con la macchina da scrivere e le immagini incollate, il suo lavoro spiccava e si distingueva a colpo d’occhio. Il Mac fece nascere una simpatia immediata fra noi due, tanto che mi chiese di trasferirmi a Chicago a lavorare con lui. Ma avevo già accettato di andare al Physikalisch-Technische Bundesanstalt (PTB) in Germania, e preferii mantenere la parola data.

E proprio al PTB arrivò la svolta, anche in campo Apple. Nel mio laboratorio di misure, assieme a strumentazione sofisticata e a uno o due Mac più vecchi, campeggiava un Macintosh II, il primo Mac espandibile (finalmente!), una workstation vera e propria che poteva competere con le macchine Sun e DEC. E questo di espansioni ne aveva, eccome! Non mi ricordo se era collegato ad un sistema di acquisizione e elaborazione di immagini da microscopio che era avanzatissimo per l’epoca (una volta tornato in Italia ho impiegato anni per riuscire a realizzarne una pallida copia).

Ma ricordo benissimo che c’era installata una scheda di conversione analogico-digitale che poteva essere usata per digitalizzare le misure sui nostri campioni, che era arrivata insieme alla prima versione del LabVIEW, il primo linguaggio di programmazione visuale, che proprio per quello girava solo ed esclusivamente sul Macintosh. Per motivi vari la scheda l’abbiamo usata poco, ma il LabVIEW diventò subito il divertimento preferito mio e di un amico danese. La sera, quando non c’era nessuno, passavamo ore ad usare il LabVIEW per le cose più assurde, più erano lontane dagli scopi originali del linguaggio meglio era.

I Macintosh del laboratorio erano configurati per usare il tedesco, e il System 6 di allora non permetteva certo di supportare utenti e linguaggi diversi. Ma nonostante il mio tedesco fosse zoppicante (molto zoppicante, in verità) io riuscivo ad usare senza troppi problemi il Mac perché mi ricordavo la posizione delle voci di menu che trovavo sui manuali o sulle riviste. Rispetto al sistema Unix proprietario e localizzato in tedesco che ero costretto ogni tanto ad usare, era davvero un altro mondo!³

Tornato a casa, iniziò il mio inverno Apple, che durò fino agli albori del nuovo millennio. I computer Apple erano diventati incompatibili con tutto: le tastiere e i mouse per PC non funzionavano su Mac e viceversa, idem per la RAM o le schede video e idem soprattutto per le cose più sofisticate, come le schede di acquisizione dati e immagini o le schede per il controllo degli strumenti che usavo ogni giorno. Anche trasferire un file via floppy da un PC a un Mac metteva a dura prova la pazienza (e la testardaggine) di un santo.

Poi, finalmente, arrivò Mac OS X.

Nei primi anni ‘90 avevo scoperto Unix, più che altro perché era l’unico modo per riuscire a fare certi calcoli piuttosto complicati.⁴ E quindi quando arrivò Linux, saltai immediatamente sul carro e iniziai ad usarlo ovunque.

Tecnicamente Linux era uno sballo, ma l’aspetto grafico era, diciamo così, zoppicante. Per cui, quando vidi in una vetrina un iBook G3 “Snow” con Jaguar e lessi su Macworld che il nuovo sistema operativo era basato su BSD Unix, decisi che doveva essere mio.

Lo stesso successe con l’iMac G4: lo vidi, me ne innamorai e lo comprai subito. E per settimane i colleghi venivano in ufficio, ammiravano il monitor e si mettevano a cercare il computer… 😂.

Da allora, e sono quasi venticinque anni, ho sempre usato prodotti Apple: Mac, iPod, iPad, iPhone, Apple Watch, dimentico di sicuro qualcosa. Del resto funzionano (quasi) sempre, perfino i familiari più coriacei nei confronti della tecnologia riescono ad usarli senza troppi problemi, sono eleganti, costano un po’ di più dei concorrenti ma durano anche molto di più. Non avrebbe senso cambiare, almeno per ora.

Certo, Apple ci mette del suo con certe decisioni discutibili: macOS Tahoe e Liquid Glass, la prossima dismissione di Rosetta, il fork a pagamento di Pages, Numbers e Keynote (senza dimenticare Freeform), le crescenti limitazioni sull’uso di Applicazioni di terze parti, la debacle di Siri, la ristrutturazione delle Impostazioni di Sistema che ha rese ostiche anche a chi, come me, le usa quasi ogni giorno.

Ma finché Apple non deciderà di impedire l’installazione di applicazioni di terze parti anche su macOS, come succede (non sempre) giustamente su iOS e iPadOS, sarà difficile abbandonare la casa madre. Perché, proprio come in un matrimonio con i suoi alti e bassi, cinquant’anni di vita passati quasi sempre a braccetto non sono facili da dimenticare.

E allora tanti, tanti, tanti auguri ad Apple per i prossimi cinquant’anni!

– Fonte: Ray Hennessy su Unsplash.

Se confrontate il prezzo dell’Apple II base riportato in questa immagine con quello della pubblicità su Bit, noterete che in meno di due anni il prezzo dell’Apple II base era aumentato di ben un milione di lire (più o meno 1.000-1.500 euro odierni) a causa dell’inflazione galoppante di quegli anni. ↩︎
Era proprio l’epoca del passaggio dai digitalizzatori umani, che passavano la vita chini su enormi immagini che digitalizzavano a mano, ai sistemi di digitalizzazione semiautomatici, che nei casi più semplici erano quasi sempre degli Apple II. ↩︎
Tutti i normali comandi di shell erano localizzati in tedesco, per cui il normale whoamiche serve per sapere il nome dell’utente che ha effettuato il login diventava wobinich. ↩︎
I PC erano tropo lenti. E come se non bastasse e nonostante i cartelli terroristici che lasciavo in giro, alcuni colleghi si ostinavano a spegnere il PC su cui eseguivo le simulazioni durante la notte. Non volevano “sprecare corrente”, dicevano 😱. ↩︎

MacBook Air M1 la non-recensione: prestazioni con Performance Test

Tue, 15 Mar 2022 06:00:00 +0000

Dopo aver valutato le prestazioni del MacBook Air M1 con Geekbench 5, questa volta tocca a PerformanceTest, un tool meno noto ma davvero molto interessante, perché permette una analisi molto dettagliata delle prestazioni del sistema. Ma non temete, qui mi limiterò solo a un riassunto dei risultati più importanti. Chi vuole può saltare i dettagli relativi all’installazione e all’uso di PerformanceTest e leggere solo la parte finale con i risultati dei test.

PerformanceTest: versione grafica e versione a linea di comando

PerformanceTest per Mac è un prodotto gratuito di Passmark Software ed è un vero peccato che il produttore faccia pochissimo per farcelo trovare con facilità, sepolto com’è in fondo della pagina dedicata alla descrizione generica del prodotto (e anche da lì ci vogliono altri due click per arrivare alla versione specifica per Mac).

La versione grafica di PerformanceTest si trova sull’App Store e gira su macOS 11.0 e versioni superiori, quindi di fatto solo su Big Sur e Monterey (Figura 1), mentre la versione a linea di comando (da eseguire quindi con il Terminale del Mac) ha bisogno almeno di macOS 10.14 Mojave (Figura 2).

Figura 1. Versione grafica di PerformanceTest.

Figura 2. Versione a linea di comando di PerformanceTest.

Le schermate delle due versioni sono praticamente identiche, la parte superiore della finestra mostra le principali informazioni di sistema mentre tutto il resto è dedicato all’elenco dei test disponibili e ai risultati corrispondenti. L’unica differenza è che la versione a linea di comando mostra anche i valori dei parametri utilizzati per eseguire i test (numero di processi, numero di ripetizioni, durata del test, tutte cose che vedremo meglio più avanti), mentre la versione grafica può utilizzare solo i parametri di default (o almeno io non sono stato capace di trovare il modo di configurarla), parametri di cui però non sappiamo nulla perché non sono riportati nella finestra del programma. Sull’Air M1 la schermata della versione grafica si estende in verticale per tutto lo schermo e finisce per essere nascosta in parte dal Dock; è vero che ci vuol poco per nascondere il Dock, ma è una piccola seccatura lo stesso.

Io ho preferito usare la versione a linea di comando, non solo perché è compatibile con un maggior numero di versioni di macOS e quindi mi ha permesso di provare quasi tutti i Mac a mia disposizione, ma anche perché può eseguire tutti i test in sequenza salvando i risultati su un file. Una bella comodità quando ogni ciclo di test dura mezz’ora o più e si devono ripetere più volte le stesse prove con valori diversi dei parametri.

Ancora più importante, però, è il fatto che, a differenza della versione grafica limitata ad usare solo i parametri di default, la versione a linea di comando di PerformanceTest consente di variare in modo molto completo le condizioni di esecuzione del programma, una cosa fondamentale per mettere seriamente alla prova i Mac sotto esame.

Come usare la versione a linea di comando

PerformanceTest a linea di comando non richiede installazione, basta scaricarlo da questa pagina, decomprimere il file pt_mac.zip, spostarsi nella cartella risultante PerformanceTest ed eseguire il programma pt_mac con gli opportuni parametri.¹

Andando nello specifico, se abbiamo scaricato e scompattato il file nella cartella Downloads, per lanciare pt_mac da Terminale con i parametri di default dobbiamo eseguire i comandi

$ cd ~
$ cd Downloads/PerformanceTest
$ ./pt_mac

Come sempre il simbolo del $ rappresenta il prompt del Terminale e non fa parte del comando. Il primo comando cd ~ serve solo per essere sicuri di partire dalla cartella Home del proprio account e non è strettamente necessario a meno che non abbiate già usato quello stesso Terminale per aggirarvi nei meandri del filesystem.

Arrivati a questo punto si apre la schermata principale del programma (Figura 2). Premendo il tasto A eseguiamo tutti i test disponibili, se invece vogliamo eseguire solo i test relativi alla CPU o alla memoria dobbiamo premere rispettivamente i tasti C o M. Con i parametri di default i test durano relativamente poco e alla fine ci viene chiesto se vogliamo salvare i risultati su cpubenchmark.net che, analogamente a quello che fa Geekbench, raccoglie i risultati dei test eseguiti con PerformanceTest. In caso di risposta positiva, alla fine dell’upload ci viene restituito l’URL dove ritrovare il nostro test.

Tutto molto comodo ma anche piuttosto difficile da analizzare a posteriori. Molto meglio eseguire pt_mac specificando esplicitamente i parametri da utilizzare per i test. In questo caso pt_mac salva i risultati dei test su un file in formato yaml e non più su cpubenchmark.net, una cosa che apre la strada all’automazione di tutta la procedura, ad esempio attraverso uno script in bash. Io ho preferito fare tutto a mano perché il numero di test da eseguire non era così grande da non poter essere concluso in un paio di giorni sfruttando i momenti liberi delle varie macchine, ma se dovessi analizzare un gran numero di computer avrebbe senso investire un po’ di tempo nel preparare uno script come si deve.

Come sono stati eseguiti i test

Ho iniziato i test sul MacBook Air M1 utilizzando macOS Big Sur 10.6, ma poi ho ripetuto le misure anche con gli aggiornamenti successivi 10.6.1 e 10.6.2.

Per confronto, ho misurato anche le prestazioni dell’altro Air di casa, un modello del 2015 con processore i5 su cui è installato macOS Mojave 10.14.6, nonché quelle di due altri Mac su cui girano versioni compatibili di macOS, un vecchio ma sempre pimpante MacBook Pro i7 del 2011 customizzato, su cui gira Big Sur 11.6.2 e un iMac i5 del 2013 con Mojave 10.14.6. Purtroppo il mio Mac principale usa (ancora per poco, spero) High Sierra e quindi non ho potuto includerlo in queste prove.

Per quanto riguarda PerformanceTest, tutti i test sono stati eseguiti con la versione v10.2 Build 1000 del 21 Dicembre 2021, che è ancora l’ultima release disponibile. Tutte le prove riportate qui sono state eseguite con questi parametri

$ ./pt_mac -p 1 -i 5 -d 3 -r 3

dove -p indica il numero di processi da eseguire in parallelo, -i il numero di ripetizioni di ciascun test, -d la durata dei test e infine -r determina se eseguire tutti i test o solo quelli relativi alla CPU o alla memoria (maggiori dettagli sul significato di ciascuno switch si possono trovare qui). In questo caso specifico, il numero di processi -p è stato variato fra 1 e 32, raddoppiando ogni volta il numero precedente (quindi -p può essere uguale a 1, 2, 4, 8, 16, 32), mentre per semplicità tutti gli altri parametri sono stati mantenuti invariati. Ciò significa che ogni test è stato ripetuto per 5 volte (-i 5), eseguendo sempre dei test di tipo Long (-d 3) e analizzando sia la CPU che la memoria (-r 3).

Con questa configurazione un ciclo completo di test richiede almeno mezz’ora, inutile aspettare davanti al Terminale, meglio andare a prendere un caffè molto lungo o a fare una passeggiata. Perché mentre eseguiamo i test non possiamo assolutamente usare il Mac, anzi prima di lanciare pt_mac sarebbe preferibile chiudere tutte le applicazioni in esecuzione, o almeno quelle che non sono indispensabili.²

Durante i test la temperatura del processore M1 del MacBook Air, misurata tramite Hot, arriva fino a 80°, a dimostrazione del fatto che PerformanceTest mette davvero alla frusta le capacità della CPU. Dato che il processore M1 del MacBook Air è raffreddato solo in modo passivo (cioè senza ventole, rumorose e soggette a guasti), è chiaro che a questa temperatura interviene un sistema di throttling che diminuisce le prestazioni del processore e gli impedisce di riscaldarsi ulteriormente. Ben diversi i Mac con processori Intel: qui la temperatura della CPU può arrivare a 90-95°, ma ora le ventole si sentono, eccome se si sentono!

Quasi tutti i test sono stati eseguiti tenendo il MacBook Air M1 sempre collegato all’alimentazione elettrica. Ho provato anche a eseguire un paio di prove con la batteria e, come vedrete fra poco, ho fatto bene, perché i risultati sono interessanti e meriterebbero un maggiore approfondimento.

Risultati

PerformanceTest salva sul file yaml i risultati ottenuti da ciascun test, nonché due parametri riassuntivi, il CPU Mark e il Memory Mark, che combinano in un modo piuttosto contorto i risultati dei test della CPU e quelli relativi alla memoria (Figura 3). Purtroppo non è possibile mostrare una schermata con i risultati completi dei test perché alla fine dell’analisi PerformanceTest salva i risultati su file e si chiude, tornando al prompt del Terminale.

Figura 3. Risultati (quasi completi) dei test.

Una volta concluse le prove sui quattro Mac che ho usato in questo ciclo di test mi sono ritrovato con un bel numero di file yaml, uno per ogni valore di -p, archiviati in cartelle diverse a seconda del Mac usato. PerformanceTest non permette di scegliere il nome del file e la cartella di archiviazione, per cui bisogna rinominare e archiviare tutto a mano, un’altra delle cose che potrebbero essere facilmente automatizzate con il buon vecchio bash. Ma tant’è, per questa volta fare tutto a mano non è stato troppo fastidioso.

Arrivati a questo punto l’idea era di aprire RStudio e cominciare ad analizzare i dati. E invece no. Per qualche motivo la libreria yaml di R non riusciva ad aprire i file generati da PerformanceTest (inutile dire che la stessa libreria non aveva problemi con qualunque altro file yaml che avessi sotto mano), per cui ho dovuto fare un passaggio intermedio con Python per convertire i file yaml in csv, aprendo poi questi ultimi in R. Il resto dell’analisi è filato via senza problemi. Per semplicità mi sono limitato ad analizzare solo il CPU Mark e il Memory Mark, ma non è detto che prima o poi non ci sia modo di fare uno studio più completo.

Cominciamo con i valori del CPU Mark ottenuti dai 4 Mac utilizzati (Figura 4).

Figura 4. CPU Mark in funzione del numero di processi in esecuzione nella CPU. Legenda: (iMac14,3, cerchi rossi) iMac i5 2013/Mojave 10.14.6, (MacBookAir10,1, quadrati blu) MacBook Air M1 2020/Big Sur 10.6.x, (MacBookAir7,2, rombi verdi) MacBook Air i5 2015/Mojave 10.14.6 i5 , (MacbookPro8,2, triangoli viola) MacBook Pro i7 2011/Big Sur 10.6.2.

Rispetto agli altri 3 Mac il MacBook Air M1 (identificato nel grafico dai quadrati blu) è di un altro pianeta, ma dai risultati ottenuti con Geekbench sappiamo che anche i Mac più moderni con processore Intel non avrebbero fatto una figura migliore.

La Figura 4 mostra chiaramente come il processore M1, ad ogni raddoppio del numero di processi, riesce a raddoppiare (o quasi) il suo livello di prestazioni. Una tendenza alla saturazione del CPU Mark si osserva solo quando PerformanceTest arriva ad eseguire 8 processi in parallelo, impegnando così tutti gli 8 core della CPU, perché una parte delle risorse del sistema deve essere comunque riservata alla gestione del sistema operativo (ecco perché è bene tenere il Mac il più possibile scarico durante questi test).

Una cosa piuttosto strana succede quando il numero di processi arriva a 16. Per quanto se ne sa, il processore M1 non supporta l’hyper-threading – la tecnologia di Intel che permette di simulare l’esistenza di due core logici per ogni core fisico³ – ma nonostante questo, con 16 processi in parallelo le prestazioni misurate dal CPU Mark invece di diminuire (a causa dell’overhead, cioè del tempo perso dal sistema operativo ad alternare i due blocchi di 8 processi su una sola CPU) si mantengono di fatto identiche a quelle con soli 8 processi, ad ulteriore conferma dell’efficienza dell’M1. Che però si arrende una volta arrivato a 32 processi in parallelo, ma questo potrebbe essere dovuto a qualche caratteristica dello stesso PerformanceTest.

In ogni caso, ha davvero dell’incredibile osservare come, grazie al processore M1, il piccolo Air si sia trasformato dalla cenerentola di casa Apple in quanto a potenza a un computer in grado di rivaleggiare ad armi pari con modelli ben più costosi.

Guardiamo ora i valori del Memory Mark (Figura 5). Qui non c’è molto da dire, il Memory Mark non cambia molto al variare del numero di processi e come sempre l’Air M1 dimostra la sua superiorità rispetto ai modelli Intel, con un indice doppio rispetto al MacBook Air i5 e migliore di quasi il 50% nei confronti degli altri due modelli esaminati.

Figura 5. Memory Mark in funzione del numero di processi in esecuzione nella CPU. Legenda: (iMac14,3, cerchi rossi) iMac i5 2013/Mojave 10.14.6, (MacBookAir10,1, cerchi blu) MacBook Air M1 2020/Big Sur 10.6.x, (MacBookAir7,2, cerchi verdi) MacBook Air i5 2015/Mojave 10.14.6 i5 , (MacbookPro8,2, cerchi viola) MacBook Pro i7 2011/Big Sur 10.6.2.

Qualche anomalia

L’Air M1 presenta due risultati decisamente anomali (indicati in Figura 5 con delle etichette rosse), nei quali il Memory Mark assume valori ben al di sotto di quello che ci si potrebbe aspettare. Il valore peggiore in assoluto si ottiene utilizzando la batteria, ma un’altra prova eseguita esattamente nelle stesse condizioni ha dato un risultato normale.

Di primo acchito si potrebbe pensare che l’anomalia sia collegata alla versione del sistema operativo usato, perché i due valori anomali si ottengono con la versione iniziale 11.6 di macOS Big Sur (Figura 6). Ma se è plausibile che gli aggiornamenti successivi di Big Sur abbiano introdotto qualche ottimizzazione nella gestione della memoria del processore, questa ipotesi non spiega perché il Memory Mark misurato con 8 processi in parallelo sia decisamente peggiore di quello con 16 processi.

Figura 6. MacBook Air M1: dipendenza del Memory Mark dalla versione di macOS Big Sur.

Inoltre, come si vede in Figura 7, con il CPU Mark succede esattamente il contrario: a parità di numero di processi il CPU Mark è sempre maggiore, seppur di poco, con macOS 11.6 rispetto ai due aggiornamenti successivi del sistema operativo.

Figura 7. MacBook Air M1: dipendenza del CPU Mark dalla versione di macOS Big Sur.

Molto più plausibile, invece, è che i valori occasionalmente bassi di Memory Mark siano collegati a qualche processo spurio rimasto a girare nella memoria del MacBook Air M1. È vero che proprio con questo modello ho cercato sempre di lavorare in condizioni controllate e ripetibili, ma è anche vero che ho eseguito un numero di test decisamente maggiore che con gli altri Mac, per cui potrebbe essermi sfuggito qualcosa. Questo dettaglio meriterebbe comunque un maggiore approfondimento, anche perché è importante poter valutare in modo quantitativo i miglioramenti e le ottimizzazioni introdotte dai vari aggiornamenti del sistema operativo e quanto questi si traducano in una maggiore efficienza del codice eseguito sulla macchina.

Per l’ultima puntata di questa serie, qualche impressione personale su Big Sur in relazione al MacBook Air M1.

Nelle versioni precedenti di PerformanceTest il programma veniva decompresso nella stessa cartella contenente il file .zip. Chi usa la versione v10.1 del programma (o versioni precedenti) dovrà modificare di conseguenza il percorso indicato nell’articolo. ↩︎
Devo ammettere di averlo fatto con MacBook Air M1 ma non con i Mac meno potenti, su cui girano delle applicazioni che sarebbe molto seccante dover interrompere. In ogni caso, le differenze sono così eclatanti che chiudere queste applicazioni non avrebbe cambiato granché i risultati. ↩︎
Anche i processori AMD supportano una tecnologia analoga. Del resto l’hyper-threading è solo il nome commerciale adottato da Intel per la tecnologia di simultaneous multithreading (SMT) sviluppata da Sun Microsystems già negli anni ‘90. ↩︎