ARGOMENTO:

@zio : una domanda

da dove vengono presi i dati xml ? da TN-Grid ?

Per essere un challenge interno la partecipazione mi risulta alquanto scarsa, per ora siamo solo in 27 ad aver fatto crediti…sotto gente!

@saba

Sì, prendo gli xml direttamente dal sito.

come faccio per tutte le statistiche che gestisco io

Bella lotta con 25 milioni...

valterc ha scritto:

Se qualcuno avesse voglia di fare dei badge per il challenge potrebbe partire da questa cosa che e` il prototipo dei badge che verranno prima o poi assegnati su TN-Grid.

zioriga ha scritto:

ci deve pensare l'ottimo Mantis

Ci posso provare ma avrei bisogno di qualche suggerimento su testo e colori .
Grazie

C'è una differenza mostruosa di performance tra win64 e linux64. A parità di computer, l'applicativo linux finisce il lavoro dai 2000 ai 4000 secondi prima di quello windows. Mi ritrovo con un core di fx 8350 (con win) che rende pochissimo più di un core di athlon 5350 (linux).
L'ho notata solo io, questa cosa, oppure è un problema comune (o magari già segnalato)?

Prima versione badge:













Senza allegarli al post, se confermati lascio agli Admin il compito di inserirli tra quelli ufficiali

Mantis-89 ha scritto:

Prima versione badge:

Senza allegarli al post, se confermati lascio agli Admin il compito di inserirli tra quelli ufficiali

Ottimi, li metterei pure io se ci sarebbe un metodo un pochino più facile per caricarli…( ho già bestemmiato più volte in svariate lingue e da allora gli ho tolti... ). Su Seti Germany hanno un sistema che li implementa automaticamente…sarebbe bello averlo pure noi quel metodo...

@Heden

si confermo quanto hai detto, o per lo meno con i miei PC

il più veloce sotto Win 8.1 impiega in media 2.3 ore
il più veloce sotto linux impiega 1.3

quindi circa 1 ora di differenza.
roba da provare con un Linux virtualizzato sotto Win.
ora provo

zioriga ha scritto:

@Heden

si confermo quanto hai detto, o per lo meno con i miei PC

il più veloce sotto Win 8.1 impiega in media 2.3 ore
il più veloce sotto linux impiega 1.3

quindi circa 1 ora di differenza.
roba da provare con un Linux virtualizzato sotto Win.
ora provo

Per quanto mi ricordo l'applicativo e` stato compilato (x86 e x64) sotto Linux (su una distro ubuntu 10.xx) con gcc e poi su windows con visual C, forse bisognerebbe provare a cross-compilarlo con mingw...

sto facendo delle prove.

sull'Intel I7 5960 con Win 8.1 le WU durano circa 2h 20m mentre un Linux VBoxato dovrebbero durare 1h 20m quindi sarebbe opportuno usare con questa CPU la VBox Linux

mentre su un AMD 8350 no dico ancora quanto durano perchè ci sarebbe uno svantaggio fortissimo ad usare la VBox Linux, aspetto di vedere i risultati

valterc ha scritto:

Per quanto mi ricordo l'applicativo e` stato compilato (x86 e x64) sotto Linux (su una distro ubuntu 10.xx) con gcc e poi su windows con visual C, forse bisognerebbe provare a cross-compilarlo con mingw...

Tra quant'è che possiamo avere una versione ottimizzata come per Denis@Home..? :asd:

Curiosità: il sorgente è aperto o riservato?

valterc ha scritto:

zioriga ha scritto:

@Heden

si confermo quanto hai detto, o per lo meno con i miei PC

il più veloce sotto Win 8.1 impiega in media 2.3 ore
il più veloce sotto linux impiega 1.3

quindi circa 1 ora di differenza.
roba da provare con un Linux virtualizzato sotto Win.
ora provo

Per quanto mi ricordo l'applicativo e` stato compilato (x86 e x64) sotto Linux (su una distro ubuntu 10.xx) con gcc e poi su windows con visual C, forse bisognerebbe provare a cross-compilarlo con mingw...

Per il momento (challenge) ho assegnato tutti e 8 i core a una debian su virtualbox, e sono passata da 9000 secondi a 5000.
Si possono avere i sorgenti per un confronto? Ho una certa esperienza in C. Forse, e sottolineo forse, posso dare una mano. Fammi sapere

Mantis-89 ha scritto:

Curiosità: il sorgente è aperto o riservato?

Se è closed, aspetto la fine del challenge (giusto per spirito di squadra) e stacco tutto.

@zioriga: nessuno svantaggio con virtualbox e 8350. Praticamente, va il doppio.

edit: perdonate il doppio post. Oggi ho le traveggole, vedo post fantasma

Attenzione che dalle mie prove sembrerebbe la differenza di performance sia legata al tipo di processore e quindi molto aleatoria, e dipendente da caso a caso

Nel mio caso la Vbox Linux impiega + del doppio che sul Vista nativo (su questo PC gira anche TThrottle per tenere bassa la temperatura, quindi gira tutto più lentamente, e non so se questo possa inficiare la performance della VBox - forse dovrei finalmente decidermi a cambiare il dissi e metterne uno migliore rispetto a quello base di stock)


Per quanto riguarda esperti di C/C++, mi faccio avanti anch'io, anche se autodidatta da molti anni

zioriga ha scritto:

Attenzione che dalle mie prove sembrerebbe la differenza di performance sia legata al tipo di processore e quindi molto aleatoria, e dipendente da caso a caso

Negativo, è un problema generale...

dopo un ora di run su Vista, posso affermare che in effetti sulla VBox Linux le WU viaggiano + rapidamente.

quindi hai perfettamente ragione Heden !!!!

zioriga ha scritto:

dopo un ora di run su Vista, posso affermare che in effetti sulla VBox Linux le WU viaggiano + rapidamente.

quindi hai perfettamente ragione Heden !!!!

Il problema di boinc in vm è che se assegni tutti i core il computer host diventa quasi inutilizzabile (ovviamente le wu sono a bassa priorità solo nel guest)... e purtroppo non ho macchine dedicate per lo scaccolo

questa del codice sorgente open, closed, upon request e` un topic bollente, in pratica una decisione non e` ancora stata presa....... Ho risollevato la questione con i responsabili scientifici e con il team di sviluppo, vediamo cosa mi dicono (c'è un meeting questo pomeriggio...)

valterc ha scritto:

questa del codice sorgente open, closed, upon request e` un topic bollente, in pratica una decisione non e` ancora stata presa.......

Io sono per i sorgenti open.
Anche perchè, con Horizon 2020, l'open in ambito scientifico diventerà un modello centrale (pubblicazioni, risultati, dati, ecc).
Ma sta a voi giudicare se è meglio o no.