[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