[cfarm-users] bread

Martin Guy martinwguy at gmail.com
Wed May 28 12:16:26 CEST 2025


Parliamo techie stuff.


Ho trovato il processore che, con un single thread, è il più veloce al mondo

(sono costretto a single thread xche mira non sfutta affatto il 
parallellismo

che in questi giorni andrebbe fatto. I linguaggi pure functional sono dei

candidati ideali per il parallelismo fine grain. Siccome il risultato di 
ogni

elemento di ogni espressione è garantito che dipende soltanto dagli 
argumenti

e del testo della funzione, puoi evaluatare ogni lato di un `+' diciamo

in parallelo, poi quando entrambi tornano poi restituirne il risultato.


Ma mira non lo fa, e dovrebbe.


La mosca nell'unguente è che il garbage collector parte ogni tanto;

alloca le cellule libere dall'heap in sequenza poi, quando arriva al_

l'ultima fa un GC mark-and-sweep: scannerizza tutto lo stack

segnando ogni cosa che sembra un puntatore, cioè il suo valore

numerico è entro la parte della memoria dedicata al heap

ed è allineato a quantunque sia l'allineamento dei puntatori,

e segna quella come in-uso, avendo azzerato tutti gli "in-uso" bit

precedentemente. Poi quando arriva alla fine, alloca quelli che

non sono stati segnati come "usati" dallo scan mark.


Mi chiedo se segna anche dove punta il word in questione,

se anch'esso sembra un puntatore into the heap e così via,


C'è una sola architettura su cui funziona disastrosamente: sun4u.


Ci sono architetture e compilatori dove non devi accendere alcuna

ottimizzazione del codice; se no "impossible tag 247 in reduce" e

morte. Vuol dire che l'array parallelo al heap, i tag, che sono un byte

per ogni cellula del heap, dicono cosa c'è dentro questa cellula

(un intero, un numero a virgola mobile, un puntatore ad una funzione,

un bool, un char e altro) e un bit per dire se è usato o no. Ne usa solo

5 bit di quel byte; forse si potrebbe compattare se riusciamo a salvare

un bit.


sun4u invece d' Segmentation Fault (core dumped) and gdb is unusable

on Solaris, the only sun4u I had access to so you can't see where it's 
dumping.

Now qemu-system-sparc64 and a bit of web-scanning have given me a

debian buster:


wget 
https://cdimage.debian.org/cdimage/ports/9.0/sparc64/iso-cd/debian-9.0-sparc64-NETINST-1.iso
qemu-create sun4u-buster.img 16G

# minimum -m RAM to boot: 256 (well, not 128)

qemu-system-sparc64 -machine sun4u -m 1024 -nographic \
   -drive file=sun4u-buster.img,if=ide,bus=0,unit=0 \
   -drive 
file=debian-9.0-sparc64-NETINST-1.iso,format=raw,if=ide,bus=1,unit=0,media=cdrom,readonly=on 
\
   -boot d


that's it. The fastest single processor on the GCC Compile Farm is

an Apple Firestorm-M1, really an arm64 or some kind, on cfarm103

with cfarm104, another M1, a very close second, 97% of cfarm104

if I remember correctly.


Anyway, onward. final releases imminent.


    M



More information about the cfarm-users mailing list