Il 11 settembre 2017 13:17:41 CEST, maxlinux duemila <maxlinux2...@gmail.com> ha scritto: >in effetti hai ragione riguardo alla latenza, cmq stavo pensando, a >operazioni lunghe + adatte ad un cluster che a un multiprocessore >Del tipo... compilazione in parallelo con gradler, compressione di >video con ffmpeg, rendering di video con blender. Questi programmi >sono adatti al calcolo in cluster, pur tenedo conto della inevitabile >latenza.
allora ne possiamo parlare, ma spesso le applicazioni vanno riscritte appositamente per essere clusterizzabili (mpich ed il protocollo MPI sono un buon punto di partenza per studiare la cosa) soluzioni integrate per rendere trasparente il processo e creare una vera e propria VM "spalmata" su piu computers? personalmente non ne conosco e passo la palla ad altri > >Stavo anche pensando di non usare la porta ethernet, e usare >direttametne usb3 via otg (ethernet on usb) per aumentare la velocità >di trasferenza. può essere una buona idea, altrimenti si può pensare a usb-c o semplicemente ad un upgrade a ethernet 10gbps (costosissimo), magari in fibra, come si fa ormai in molti datacenters, ma forse usb3 è la via piu economica ed alla portata di tutti > >Poi per la navigazione in internet o riproduzione di film in 4k... non >mi preoccupa. Posso continuare a farlo dal portatile e i film non >guardo proprio, visto il scarso contenuto dei film di qualsiasi tipo >negli ultimi anni. gr8 > >CMQ la cosa che più mi preoccupa invece è la velocità di calcolo. >Secondo i benchmark l'architettura arm esce con le ossa rotte >comparata persino con un intel di bassa categoria. >Peró non vorrei che fosse per colpa del benchmark stesso. ARM è un'architettura RISC, quindi un set ridotto di istruzioni, che consuma molto meno, fa molto uso dei registri limitando le pull e le push dalla ram (tipicamente molto lenta) e occupando molta meno superficie di silicio, dando vita o a processori completi molto compatti ed economici (ma stracciati nei benchmarks classici), o a processori di dimensioni classiche dove nella superficie di un intel baytrail è possibile far entrare senza troppe difficoltà anche 96 core o piu. infatti arm è il futuro del mondo server (con le architetture ppc e mips che stanno nuovamente prendendo piede nei mainframe e nei supercomputer) personalmente come parrotsec stiamo provando ad investire molto in arm64 e in board come pine64, rock64 e alcune nuove orangepi, ma prima purtroppo nel mercato consumer, i produttori hanno freato una vera e propria mafia di drivers proprietari e hardware packs inutilizzabili, con kernel vecchi e con varie problematiche di performance, ma fidati, i benchmark di una board allwinner con debian non sono in nessun modo rappresentativi della qualità dell'architettura arm, che secondo me deve ancora vedere la sua vera rivincita o attraverso una nuova board progettata seriamente o attraverso tutte le legnate date ad allwinner e ad altri produttori simili che hanno progettato ottimi processori confezionando pessimi hardware packs per le comunità opensource dai, sugli smartphone i video in 8k non vanno affatto a scatti, mentre un pine64 lo metti in crisi con un 720p, e solo per una questione software non legata alla comunità opensource ma legata al produttore my 2 cents > >Qualcuno ha maggiori info a riguardo? > > >On 11/09/2017, Lorenzo "Palinuro" Faletra <palin...@parrotsec.org> >wrote: >> ma stai tenendo in considerazione latenza e throughput? >> >> questo tipo di clusters va bene solo per applicativi server con varie >> istanze che scalano orizzontalmente su questo tipo di configurazioni, >ma un >> macchinone virtuale nato dalla fusione di tanti piccoli nodi farebbe >un po >> schifo per applicativi interattivi poichè coinvolgere lo stack di >rete e dei >> sistemi operativi per virtualizzare trasmissioni che normalmente un >computer >> compie in modo diretto verso memoria e periferiche, comporta seri >> rallentamenti.... >> -- Lorenzo "Palinuro" Faletra Parrot Security GPG FINGERPRINT: B350 5059 3C2F 7656 40E6 DDDB 97CA A129 F4C6 B9A4 GPG Info: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x97CAA129F4C6B9A4 GPG Key: http://pgp.mit.edu/pks/lookup?op=get&search=0x97CAA129F4C6B9A4
