Mi sono quindi lasciato tentare da un acquisto su eBay: un Intel SS4200-E con 4 dischi Seagate da 750 GiB per la ragionevolissima cifra di 250$ (usato meno di un anno). Trattasi di un NAS progettato e realizzato su stardard aperti (è di fatto un PC) con un case molto più ingombrante e pesante dei “normali” NAS SOHO, ma che da anche una notevolissima sensazione di solidità.

<

I supporti per dischi, sorprendentemente con apertura 'ad ala'.

Nonostante manchi la comoda funzione di hotswap dei drive (la sostituzione è comunque semplice e totalmente tool-less), il sistema è davvero notevole: scheda madre con socket LGA 775, processore Celeron M 420 a 1.6 GHz (core Yonah a 32-bit), 512 MiB di RAM DDR2-667, scheda di rete Gigabit, 4 porte USB (2 frontali e due posteriori), 2 porte e-sata sul posteriore. Inoltre le prestazioni sono di tutto rilievo, come riportato in diverse recensioni e forum (sul forum di OpenFiler si parla di 60-70 MiB/sec tanto in lettura che in scrittura).

Unici veri problemi di questo sistema sono la piattaforma software fornita e la CPU, andiamo a scoprire perché.

Il software è un soluzione Linux based prodotta da EMC e chiamata Lifeline: pur non essendo affatto male, il sistema operativo risulta molto limitato per l’assenza di servizi ormai standard come la gestione integrata di torrent e diverse tecnologie di distribuzione di file multimediali su rete domestica, senza contare gli altri servizi che ho poc’anzi descritto. Inoltre il DOM (Disk-on-module) da soli 256 MiB non permette grandi spazi di manovra.

Il DOM dell'SS4200E, contenente il software EMC Lifeline.

La CPU non è certo un problema in termini di potenza di calcolo: il vero problema è rappresentato dal fatto che, nonostante sia una CPU pensata per notebook, non dispone della tecnologia di variazione dinamica della frequenza di lavoro (denominata Speedstep da Intel), il che porta l’unità a consumare molta più energia del necessario (e comunque molta di più di soluzioni a 4 dischi basate su integrati con architettura ARM, ad esempio).

Come risolvere i problemi sopra indicati? Per quanto riguarda il sistema operativo ho ordinato un DOM da 2 GiB dalla Cina, all’incirca 25 dollari, sul quale credo installerò una verisone stringata ai minimi termini di Ubuntu server a cui poi aggiungerò il necessario per mettere in piedi i servizi di cui sopra. La CPU, invece, è stata rimpiazzata con un Celeron E1500 (50k KRW), ovvero un derivato della serie Core 2 Duo (Conroe 65nm) e frequenza di 2.2 GHz. Tale CPU porta diversi vantaggi tutti insieme: non solo ha un core in più (che mi sarà molto utile per le VM) ed è un processore a 64-bit, ma supporta anche la tecnologia EIST (Enhanced Intel SpeedStep Technology) cosa che lo rende un processore estremamente efficiente sotto il profilo energetico (dissipa solo 8W a riposo).

Il modding comprende anche un adattatore da IDC-10 a DB9 per poter sfruttare la porta seriale on-board, visto che l’SS4200E è una unità headless. In realtà la macchina è dotata di uno slot PCI-Express 1x, ma lo spazio all’interno del case è ridottissimo e dovrei dotarmi di un PCI-Express extender per poter usare una scheda video all’esterno del case.

Non volendo affidare ad una sola unità i miei dati più importanti, utilizzerò uno dei dischi USB che si libereranno come backup della partizione “seria” dell NAS Intel, in modo da garantirmi un margine di sicurezza maggiore.

Ancora la modifica è un work-in progress perché non ho un cavo null-modem per l’installazione del sistema operativo, ma presto vi farò sapere come è andata a finire.

Ottimo, mi pare ovvio visto che lui non fa una benemerita fava (da intendersi come baccello, son pur sempre toscano io) dalla mattina alla sera e prende un sacco di soldi dalle tasche dei contribuenti ogni mese.

Vediamo allora se riesco a spiegare io, a questo mostro di ignoranza, che cosa vuol dire che l’Italia è una Repubblica fondata sul lavoro.

L’articolo 1 della nostra Costituzione repubblicana mette in evidenza la necessità del fatto che tutti lavorino, perché senza il lavoro dei cittadini non è possibile mantenere lo stato sociale. I cittadini, lavorando, creano ricchezza e mettono il paese in grado di competere sul piano dell’import-export. Inoltre, sempre lavorando, i cittadini guadagnano una certa quantità di denaro ogni mese sulla quale devono pagare le tasse (in prima persona o per interposta persona), tasse che confluiscono nelle casse di questa grande macchina che viene chiamata “Stato” e che garantisce (o dovrebbe garantire) servizi di prima e secondaria necessità quali: acqua, elettricità, sanità, trasporti, giustizia, “welfare”, stipendi di parlamentari e senatori, etc. Tali servizi sono forniti a tutti, in egual misura (eccettuati gli stipendi, si intende), e tutti sono liberi di usufruirne proprio perché vige il principio che tutti lavorano e partecipano al benessere del paese, inteso nel senso lato di comunità dei cittadini.

Quindi, caro minestra Brunetta (ché di ministro abbiamo proprio poco, titolo a parte), ecco spiegato il significato dell’articolo primo della Costituzione, in parole credo comprensibili anche ad uno come lei. E non è che ci voglia una laurea per arrivarci (anche se io sto prendendo un dottorato all’estero).

I have been lazily following the Go language project for a while now, when it
was suddenly discussed in this post of “Appunti Digitali” (in italian), that
pointed at this post
on Dalke Scientific.

It really got me that S.Python manages to beat Go so
badly, so I decided to run my own tests on my trusty old IBM X-41 (Pentium-M 1.5
GHz).

I compiled the Go toolchain and S.Python, then ran the
test exactly as I found them on the Dalke page. The results are following
hereby:

$ time ./8.out
100000

real 0m5.197s
user 0m1.508s
sys 0m1.352s

$ time
/usr/local/bin/python2.6 test.py
100000

real 0m3.315s
user 0m1.556s
sys 0m0.148s

What really struck me is that
the time spent in userland is roughly the same for both programs. What really
kills the Go execution time is that it spends almost as much time in kernel
mode. I wondered why…

Then I remembered that, in the Google Tech Talk,
Pike said something about the Go runtime managing threads for the user, and I
automatically thought that it would associate user threads with OS threads in
some way (as is the norm). In fact that is what gccgo does (uses NTPL).

On
the other hand, reading Stackless Python documentation, I found this page
regarding Tasklets. The page clearly states: “Tasklets are
characterized by being very lightweight and portable, and make great
alternatives to system threads or processes.”

So I am prone to believe
that S.Python Tasklets are managed by the Python VM itself, requiring no
user-to-kernel mode transitions and no other kernel interaction… because they
are not real threads (as opposed to Go goroutines).

This, with the fact
that Go is mainly intended to cut compile time (not so much running
time), makes me believe the comparison to be pretty unfair, and I think Go
provides quite a performance!

Regarding certain unsafe situations, they
are definitely a problem. Still, I believe that they will be taken care of
quickly: Go is a brand new language and rough edges are to be expected here and
there, but it has quite some room for growth.

Update:

I modified the test program so that each goroutine/Tasklet calls a second
function that loops 1000 times and cumulates the result of “sum = sum+1″.

The results are as expected: the compiled code is one order of magnitude faster
than Stackless Python interpreted code! I also replaced range with xrange, as suggested by Cesare
Di Mauro, but that did not change things much… nor did it when I tried psyco
(a JIT compiler for Python).


$time ./test2 && time /usr/local/bin/python test2.py
100000

real 0m19.567s
user 0m15.697s
sys 0m0.160s


The source code for Python is:

import stackless
from optparse import OptionParser
 
parser = OptionParser()
parser.add_option("-n", type="int", dest="num_tasklets", help="how many",
default=100000)
 
def f(left, right):
    loop()
    left.send(right.receive()+1)
 
def loop():
    sum = 0
    for i in xrange (1,1000):
        sum=sum+1
 
def main():
    options, args = parser.parse_args()
    leftmost = stackless.channel()
    left, right = None, leftmost
    for i in xrange(options.num_tasklets):
        left, right = right, stackless.channel()
        stackless.tasklet(f)(left, right)
    right.send(0)
    x = leftmost.receive()
    print x
 
stackless.tasklet(main)()
stackless.run()

And the test code for Go is:

package main
 
import (
        "flag";
        "fmt";
)
 
var ngoroutine = flag.Int("n", 100000, "how many")
 
func f(left, right chan int) {
        loop();
        left < - 1+<-right;
}
 
func loop() {
        var sum int;
        sum = 0;
        for i := 0; i < 1000; i++ {
                sum = sum + 1
        }
}
 
func main() {
        flag.Parse();
        leftmost := make(chan int);
        var left, right chan int = nil, leftmost;
        for i := 0; i < *ngoroutine; i++ {
                left, right = right, make(chan int);
                go f(left, right);
        }
        right <- 0;             // bang!
        x := <-leftmost;        // wait for completion
        fmt.Println(x);         // 100000
}

EDIT: Mi sono ovviamente sbagliato con la numerazione e questo e’ l’episodio 8! Grazie Rouge!

I totally agree: a Prime Minister should have no running issues with justice and if some come to the surface he (or she) has to resign!