Link all'Articolo: http://www.hwupgrade.it/articoli/business/2412/amd-opteron-6100-le-prime-cpu-a-12-core_index.html

Con le cpu della famiglia Magny-Cours AMD propone per prima architetture a 12 core per sistemi server, dotate di memory controller DDR3 quad channel; assieme ai processori al debutto anche le nuove piattaforme Socket G34, dall'anno prossimo utilizzate anche con le cpu Bulldozer

Click sul link per visualizzare l'articolo.

Molto bene!

Raddoppio dei core mantenendo il consumo medio invariato. Hanno fatto la magia?

Ancora non è passato nessun fanboyello intel a dire: amd svegliati, l'i7 è meglio intel rulez :confused: :confused:
Strano, hwupgrade non è più quello di una volta!:sofico:

Ancora non è passato nessun fanboyello intel a dire: amd svegliati, l'i7 è meglio intel rulez :confused: :confused:
Strano, hwupgrade non è più quello di una volta!:sofico:

Oppure qualcuno che dice che finchè non ci sono giochi che scalano su 12 core non servono a niente !!!

l'Opteron 4180 è proprio una bella bestiola, non viene nemmeno uno sproposito per essere tra le novità =)

Ancora non è passato nessun fanboyello intel a dire: amd svegliati, l'i7 è meglio intel rulez :confused: :confused:
Strano, hwupgrade non è più quello di una volta!:sofico:



Opteron 6174 12 2,2 GHz 2 processore opteron a listino
Intel Xeon X5670 6 2.93GHz 2 processore xeon a listino


eccoti i 2 opteron a 12 core che perdono in cinebench con 2 XEON 6+6

http://images.anandtech.com/graphs/amd12core_032610044429/22159.png


24 core fisici core perdono in calcolo brutale contro 12 fisici e 12 logici

l'unico vantaggio è nei programmi che non sfruttano l'HT

e non contiamo il fatto che Intel ha anche gli Xeon 8+8

c'è solo da aspettare la release di 3D max 2011 per vedere come andranno le cose li

Oppure qualcuno che dice che finchè non ci sono giochi che scalano su 12 core non servono a niente !!!

:asd: :asd:

Ah già i giochi.... avevo dimenticato i giochi :doh:

eccoti i 2 opteron a 12 core che perdono in cinebench con 2 XEON 6+6

http://images.anandtech.com/graphs/amd12core_032610044429/22159.png


24 core fisici core perdono in calcolo brutale contro 12 fisici e 12 logici



C'e' anche da dire che gli opteron hanno un tdp di 80w e gli xeon di 95w inoltre gli opteron costano 1165$ contro 1440$ degli xeon..
Il punteggi passano da 14,81 a 15,35.. solo un 3% di miglioramento...
In un server prediligo il valore del rapporto prestazioni/consumi/prezzo piuttosto che quello della potenza bruta.

Ciauz

C'e' anche da dire che gli opteron hanno un tdp di 80w e gli xeon di 95w inoltre gli opteron costano 1165$ contro 1440$ degli xeon..
Il punteggi passano da 14,81 a 15,35.. solo un 3% di miglioramento...
In un server prediligo il valore del rapporto prestazioni/consumi/prezzo piuttosto che quello della potenza bruta.

Ciauz

bè questi proci sono indirizzati anche a workstation, specialmente gli xeon 6+6, dove si tende a prediligere la potenza bruta; per i server intel ci saranno gli 8+8, anche se non ho ancora trovato i costi indicativi

sicuramente anche questi opteron sono ottimi processori e la scelta la si fara in base al programma, pero fa un po specie vedere 24 core fisici che perdono in calcolo bruto con la controparte mista.

Originariamente inviato da: AceGranger

eccoti i 2 opteron a 12 core che perdono in cinebench con 2 XEON 6+6

http://images.anandtech.com/graphs/...44429/22159.png


24 core fisici core perdono in calcolo brutale contro 12 fisici e 12 logici


C'e' anche da dire che gli opteron hanno un tdp di 80w e gli xeon di 95w inoltre gli opteron costano 1165$ contro 1440$ degli xeon..
Il punteggi passano da 14,81 a 15,35.. solo un 3% di miglioramento...
In un server prediligo il valore del rapporto prestazioni/consumi/prezzo piuttosto che quello della potenza bruta.

Ciauz



c'è anche 1 ghz di differenza tra le cpu

Incredibile il consumo di diverse linee di questi nuovi processori. :eek:

Io mi chiedo se il processore CPU Opteron 4122 avesse un ACP non superiore a 65W, per 99 dollari, quando sarà disponibile qualcosa di equivalente pure in ambito desktop, dato che le attuali soluzioni desktop, di pari prezzo, hanno un consumo più elevato.

io mi domando come mai avviene questo:
http://images.anandtech.com/graphs/amd12core_032610044429/22220.png
http://images.anandtech.com/graphs/amd12core_032610044429/22221.png

io mi domando come mai avviene questo:
http://images.anandtech.com/graphs/amd12core_032610044429/22220.png
http://images.anandtech.com/graphs/amd12core_032610044429/22221.png

I compilatori truccati intel (truccati come un travestito :asd: :asd: )

Stavo aspettando di vedere anke la proposta AMD per mettere su una workstation a 8 o 12 core, NON ci credo ke possono prendere un opteron 6 core a 2,6Ghz a 188$!!!!

Con un dual socket metto un paio di questi processori ed ho 12 core a 2,6Ghz spendendo quanto un normale processore di fascia alta per soluzioni desktop....

I compilatori truccati intel (truccati come un travestito :asd: :asd: )

è quello che pensavo anche io però poi mi danno del fanboy...

io mi domando come mai avviene questo:
..azzo!

è quello che pensavo anche io però poi mi danno del fanboy...

Non è una novità che intel abbia i compilatori taroccati settati in modo da far rallentare le cpu NON genuine intel

http://www.hwupgrade.it/forum/showthread.php?t=2119003

I compilatori truccati intel (truccati come un travestito :asd: :asd: )

è blender che non lavora correttamente con l'HT, e il porting è anche peggiore del nativo, visto che peggiorano anche gli xeon.

blender è stato usato per l'indisponibilita di 3D max 2011

è blender che non lavora correttamente con l'HT, e il porting è anche peggiore del nativo, visto che peggiorano anche gli xeon.

blender è stato usato per l'indisponibilita di 3D max 2011

boh...però da quel che vedo il dual xeon x5570 2.93 passa da 35.1 a 33.5 quindi direi che migliora anche se non di molto...

Non è una novità che intel abbia i compilatori taroccati settati in modo da far rallentare le cpu NON genuine intel


Non c'entra niente, Blender non è compilato con il compilatore Intel.

Non c'entra niente, Blender non è compilato con il compilatore Intel.

Ti credo sulla parola...:)

Ma dove lo hai letto?

Si, ma indipendentemente dal compilatore, gli Opteron x12 sotto Linux volano con blender. Se dovessi fare una tonnellata di rendering con blender, avendo già comprato la licenza, io comprerei un sistema Opteron x12 con Linux. Risparmio la licenza windows, risparmio su processori e mother board e vado anche più veloce! Quale persona sana di mente farebbe il contrario?

boh...però da quel che vedo il dual xeon x5570 2.93 passa da 35.1 a 33.5 quindi direi che migliora anche se non di molto...

e no, guarda bene, ci mete 33 secondi in linux e 35 in windows, quindi peggiora.

l'altro migliora, ma la cosa non è normale

blender è un buon programma, ma eviterei di paragonarlo a 3D Max, Maya, Vray etc. etc.; qui è stato usato giocoforza per mancanza della release di 3D max 2011 e lo stesso blender è un'alpha...


Se dovessi fare una tonnellata di rendering con blender, avendo già comprato la licenza

:mbe: blender è senza licenza, è open...

non è molto usato in campo professionale ne tantomeno cinematografico; e fino ad ora non scalava nemmeno bene con tante CPU al pari di Vray o Mental ray e guardando i bench e i problemi con l'HT le cose non sono migliorate, anche se si tratta pur sempre di una versione alpha

Bisogna stare bene attenti al tipo di applicazioni che si vanno ad utilizzare, d'altronde intravisto anche dalla recensione di Anandtech.
In molti occasioni penso che un dual 8 core 6136 2.4GHz possa essere meglio del pari prezzo dual 12 core 6168 1.9GHz.

Certo che 2x346 mmq è impressionante.

e no, guarda bene, ci mete 33 secondi in linux e 35 in windows, quindi peggiora.

l'altro migliora, ma la cosa non è normale

blender è un buon programma, ma eviterei di paragonarlo a 3D Max, Maya, Vray etc. etc.; qui è stato usato giocoforza per mancanza della release di 3D max 2011 e lo stesso blender è un'alpha...




:mbe: blender è senza licenza, è open...

non è molto usato in campo professionale ne tantomeno cinematografico; e fino ad ora non scalava nemmeno bene con tante CPU al pari di Vray o Mental ray e guardando i bench e i problemi con l'HT le cose non sono migliorate, anche se si tratta pur sempre di una versione alpha

Scusa... :p Non lo conoscevo e sono andato ora a leggere la recensione anandtech per intero... E ho scoperto che il NB AMD è a 64 bit, internamente, ed è per questo che le prestazioni della memoria salgono portando il NB fino al doppio del clock RAM... E' una brutta notizia per chi usa DDR3 ad alto clock, purtroppo...

Il differente risultato maturato con Blender non ha nulla a che fare nè con il supporto all'HT, nè lo stesso Blender la cui versione (2.5 alpha 2) è identica nelle diverse piattaforme testate. Il problema è il S.O. Windows che non riesce a garantire un flusso dati costantemente adeguato per i processori AMD. Forse la gestione di 12 cores fisici ha qualche bug ed ha bisogno di qualche patches correttiva da parte di Microsoft...

"...For some reason, the Linux version is capable of keeping the cores fed much longer. On Windows, the first half of the benchmark is spent at 100% CPU load, and then it quickly goes down to 75, 50 and even 25% CPU load. In Linux, the CPU load, especially on the Opteron 6174 stays at 99-100% for much longer."

Traduzione.

"...Per qualche ragione, la versione Linux è in grado di mantenere il carico di lavoro sui cores più a lungo. Su Windows, la prima metà del benchmark è eseguita al 100% di carico della CPU, e poi essa scende rapidamente sotto al 75, 50 e fino al 25% di carico della CPU. In Linux, il carico della CPU, in particolare sull'Opteron 6174 rimane al 99-100% per più a lungo."

Cosi a prima vista mi sembrano ottime CPU, sia come prezzo che come consumi, ma e una mia impressione o il software non
riesce ad andare dietro l'evoluzioni "multi cpu", mi sembra che questi processori siano ben poco sfruttati :)

Il differente risultato maturato con Blender non ha nulla a che fare nè con il supporto all'HT, nè lo stesso Blender la cui versione (2.5 alpha 2) è identica nelle diverse piattaforme testate. Il problema è il S.O. Windows che non riesce a garantire un flusso dati costantemente adeguato per i processori AMD. Forse la gestione di 12 cores fisici ha qualche bug ed ha bisogno di qualche patches correttiva da parte di Microsoft...

"...For some reason, the Linux version is capable of keeping the cores fed much longer. On Windows, the first half of the benchmark is spent at 100% CPU load, and then it quickly goes down to 75, 50 and even 25% CPU load. In Linux, the CPU load, especially on the Opteron 6174 stays at 99-100% for much longer."

Traduzione.

"...Per qualche ragione, la versione Linux è in grado di mantenere il carico di lavoro sui cores più a lungo. Su Windows, la prima metà del benchmark è eseguita al 100% di carico della CPU, e poi essa scende rapidamente sotto al 75, 50 e fino al 25% di carico della CPU. In Linux, il carico della CPU, in particolare sull'Opteron 6174 rimane al 99-100% per più a lungo."

quello è sicuramente il motivo principale, ma generalmente nei test di render non viene usato blender perchè nelle versioni passate non scalava bene al pari degli altri, e il problema dell'HT lo vedi anche nel test degli xeon , dove il 6+6 core migliora in win, mentre il 4+4 è leggermente migliore su linux; blender nei test vecchi che ho visto non ha mai gradito l'HT, non offriva i guadagno dato dagli altri motori di render

ottimo amd...sono cpu da server di grande valore...12 core integrati a prezzi competitivi e tdp tutto sommato notevoli...spero che il settore possa trainare il bilancio dell'azienda

Bisogna stare bene attenti al tipo di applicazioni che si vanno ad utilizzare, d'altronde intravisto anche dalla recensione di Anandtech.
In molti occasioni penso che un dual 8 core 6136 2.4GHz possa essere meglio del pari prezzo dual 12 core 6168 1.9GHz.

Certo che 2x346 mmq è impressionante.

certo ma penso che queste cpu siano per server eco. dove la parallelizzazione è tutto :O

Risultati ufficiali spec-FP_rate2006...

http://www.pctunerup.com/up/results/_201003/20100329132156_SPECfp_2P.jpg

Il maggiore vantaggio di queste CPU penso sia la possibilità di metterle su mobo con 4 soket e quindi la possibilità di avere un unico sistema con 48 cores e alla fine senza spendere nemmeno troppissimo!
(cosa che se non sbaglio con gli xeon non è possibile)

Peccato che non vengano sfruttati al massimo sotto windows...

Il problema è il S.O. Windows che non riesce a garantire un flusso dati costantemente adeguato per i processori AMD. Forse la gestione di 12 cores fisici ha qualche bug ed ha bisogno di qualche patches correttiva da parte di Microsoft...

Non spiegherebbe perchè anche il sistema Opteron 2x2435 (8 core fisici) dimostri prestazioni del 50% superiori su SUSE. Con ogni probabilità è un problema di Blender (non dimenticate che è soltanto una versione alpha).

Ti credo sulla parola...:)

Ma dove lo hai letto?

La versione per Windows è compilata con Visual C++ 2008. Il runtime di Visual C++ 2008 è tra i requisiti. Nei sorgenti inoltre c'è il file di progetto per Visual Studio 2008.

se ho capito bene, questi processori vanno con il Socket G34 ke sarà compatibile anche con i processori opteron con arch bulldozer.

Se è così, oltre a costare relativamente poco ed avere ottime prestazioni e consumi contenuti, saranno compatibili con una piattaforma longeva, un valore aggiunto non da poco, dato ke una buona scheda madre dual socket per processori server non costa poco.

Sapete (magari ditemelo in privato) dove poter trovare queste mamme con Socket G34? è la mia prima workstation e non so' bene dove reperire questi componenti.

Il maggiore vantaggio di queste CPU penso sia la possibilità di metterle su mobo con 4 soket e quindi la possibilità di avere un unico sistema con 48 cores e alla fine senza spendere nemmeno troppissimo!
(cosa che se non sbaglio con gli xeon non è possibile)

Per i server a 4 socket Intel ha gli Xeon Dunnington, gli Itanium 2 e prossimamente gli Xeon Nehalem-EX.

Peccato che non vengano sfruttati al massimo sotto windows...

Su cosa ti basi? SQL Server 2008 scala benissimo su più core.

C'e' anche da dire che gli opteron hanno un tdp di 80w e gli xeon di 95w inoltre gli opteron costano 1165$ contro 1440$ degli xeon..
Il punteggi passano da 14,81 a 15,35.. solo un 3% di miglioramento...
In un server prediligo il valore del rapporto prestazioni/consumi/prezzo piuttosto che quello della potenza bruta.

Ciauz
E c'è da dire che c'è una differenza di 700Mhz che non è poco, bisognerebbe vedere come rende l'Intel downclockato a 2,2 ma credo che già 2,6 renderebbe già di meno dell'AMD.

Già, il problema a mio avviso è spesso il compilatore usato (oltre al so ovvio). Mi ha sempre lasciato un po' perplesso Visual Studio a livello di ottimizzazione utilizzata. Credo siano migliori GCC e ICC (Intel) riguardo la pura ottimizzazione del codice prodotto. Attenzione inoltre: normalmente le app windows e linux vengono compilate con ottimizzazioni generiche che rendono il codice compatibile con ogni (quasi) cpu. Io per i miei sistemi uso Gentoo Linux in quanto mi permette di compilare l'intero so e tutte le applicazioni per l'esatta architettura e cpu su cui il codice dovrà girare. Meno immediato installare un nuovo programma in quanto bisogna compilarlo ma decisamente più efficiente nell'utilizzo delle risorse.

Un benchmark ricordiamolo è alla fine un programma come tutti gli altri. Se avessi tempo farei qualche test anch'io con blender sul mio so.

Su cosa ti basi? SQL Server 2008 scala benissimo su più core.

Più che altro è una mia impressione guardando i vari test sotto linux e windows...mi sembra che usando compilatori gcc riescano sempre a dare qualcosa in più rispetto linux i vari AMD...ma forse è solo una mia impressione...

e no, guarda bene, ci mete 33 secondi in linux e 35 in windows, quindi peggiora.


appunto...33 in linux e 35 in windows quindi migliora passando da windows a linux...

tanto per dare un'idea di quanto influiscano/influivano una compilazione od un OS in genere:
fatto anni fa:
http://www.kino3d.com/forum/viewtopic.php?t=2301&postdays=0&postorder=asc&start=15
(il primo post)

Blender Intel Compiler Optimized aveva il suo thread ufficiale su Elisyun.

ok che intel ha già previsto un cambio di architettura (tic toc) però bulldozer comincia ad avvicinarsi sempre di più.
Ho come il sospetto che sarà un'architettura mista nel suo interno,la quale secondo me,sfrutterà parte della conoscenza ati al suo interno per accellerare le applicazioni.
In pratica un x86 molto particolare con un grado di parentela alle gpu ati.......
Difatti,tranne in ambito server,in ambito desktop si limitano alla difensiva.
Penso che questi 12 core saranno gli ultimi prodotti con architettura vecchia o forse i penultimi,i prossimi processori da server saranno costruiti su architettura bulldozer.
Anche già il nome mi da l'idea di qualcosa di grosso,lento ma molto potente..........probabilmente sarà un'architettura molto ma molto parallelizzata,in stile gpu.

Oppure qualcuno che dice che finchè non ci sono giochi che scalano su 12 core non servono a niente !!!


infatti tranne quel 5\6% che ha esigenze particolari non solo 12 core non servono a niente ma nella stragrande maggioranza dei casi non ne servono neppure 4...

Io con due core e internet+ emule+ wuze+ antivirus+ masterizzazione+ film tutto assieme non supero mai il 50% 60%
di occupazione di c.p.u....

Se poi diciamo che tra due\tre anni i 12 core li avremo quasi tutti per farcene niente, e farli ammuffire dentro il case, è un'altro discorso ma tant'è...

infatti tranne quel 5\6% che ha esigenze particolari non solo 12 core non servono a niente ma nella stragrande maggioranza dei casi non ne servono neppure 4...

Io con due core e internet+ emule+ wuze+ antivirus+ masterizzazione+ film tutto assieme non supero mai il 50% 60%
di occupazione di c.p.u....

Se poi diciamo che tra due\tre anni i 12 core li avremo quasi tutti per farcene niente, e farli ammuffire dentro il case, è un'altro discorso ma tant'è...

Qui si parla di sistemi server, non certo di desktop. Non ti fai un 4xOpteron a 12 core (48 in tutto) per vederci un film....

e brava AMD. Anche gli esa sembra facciano faville. Sicuramente se continua così alla prox tornata abbandono il C2D. Con gli i7, intel ha fatto troppo parlare di se per poco e niente altro...

appunto...33 in linux e 35 in windows quindi migliora passando da windows a linux...

e appunto...

le questioni sono 2

blender lavora gia male di suo con l'HT, il porting su win è peggio del nativo su linux, almeno negli xeon 4+4, quindi c'è poco da gridare al compilatore tarocco se fanno cosi schifo .

gli xeon 6+6 vanno peggio su blender nativo ( probabilmente piu core in HT amplificano la cosa ) e meglio sul porting....

insomma è anche per quello che blender non viene mai usato nei test di render.

i test di riferimento sono sempre stati cinebench e 3D max

Bene ,bene AMD sta' spingendo come si deve in ambito server ...la news di peso ,a mio avviso, piu' che il n° di core è il Direct Connect 2.0, dove hanno aggiunto quel "poco" che mancava al gia' ottimo Direct Connect 1.0
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/2P_S_WS_Comparison_PID_41460.pdf
http://enterprise.amd.com/downloads/4P_Power_PID_41498.pdf
Da posserore di un 2P NUMA posso dire che con 11-12 GB/s di banda aggregata RAM (DDR 400) ancora oggi Direct Connet 1.0 dice la sua e conferma con questa versione 2.0 la bonta' della gestione inter-core di AMD.
Intel ,non c'e dubbio, che con Nehalem abbia fatto decisivi passi avanti e un po' riprendendo il modello di bus AMD si e' avvicinata molto....aspettiamo un bel test comparativo con gli Xeon.:)

Trovo un po' noioso il discorso del quad channel (nelle edizioni a 12 core), anche se immagino non potevano fare diversamente.

Con gli intel è necessario accoppiare 3 schede ram alla volta, mentre con alcune linee di queste nuove cpu sono necessarie addirittura 4 schede.

Nelle schede madri si tente a proporre sempre soluzioni più compatte, ma dovendo mettere tanti slot, non si può proporre soluzioni ultra-compatte.

Trovo un po' noioso il discorso del quad channel (nelle edizioni a 12 core), anche se immagino non potevano fare diversamente.

Con gli intel è necessario accoppiare 3 schede ram alla volta, mentre con alcune linee di queste nuove cpu sono necessarie addirittura 4 schede.

Nelle schede madri si tente a proporre sempre soluzioni più compatte, ma dovendo mettere tanti slot, non si può proporre soluzioni ultra-compatte.

:mbe: sono per server e workstation.... che te ne fai di 48 core se poi sei limitato con la ram ? ben vengano queste soluzioni, ti permettono di arrivare a grossi quantitativi di RAM spendendo di meno acquistando moduli piu piccoli; è una delle cose piu allettanti del sistema di AMD

Dato i prezzi, che alcuni potrebbero trovare allettanti per usi diversi da quelli per cui sono stati progettati primariamente, pare un peccato. :p

Poi, volendo, si potrebbe pure pensare alle soluzioni rack, che di sicuro beneficierebbero di non avere tante cose in mezzo.

Nota:
Sono certo, ci scommetto la tua testa, che tra qualche anno qualcuno penserà di usare queste soluzioni come muletto, allora 4 schede di ram risulterebbe una seccatura. :p

e appunto...

le questioni sono 2

blender lavora gia male di suo con l'HT, il porting su win è peggio del nativo su linux, almeno negli xeon 4+4, quindi c'è poco da gridare al compilatore tarocco se fanno cosi schifo .

gli xeon 6+6 vanno peggio su blender nativo ( probabilmente piu core in HT amplificano la cosa ) e meglio sul porting....

insomma è anche per quello che blender non viene mai usato nei test di render.

Scusa ma quale porting e quale nativo? Sono tutti e due compilati sulle rispettive piattaforme per le rispettive piattaforme, non c'è il "nativo" e il "porting"...

Poi il problema con l'HT o è un problema dello scheduler di windows, oppure è un non-problema, nel senso che blender, per la natura dei calcoli che effettua, tiene impegnate le unità esecutive in modo che non c'è beneficio nell'uso dell'HT.

Ma tornando con i piedi per terra, da quello che dice anandtech quando espone il problema delle prestazioni mutilate dell'opteron magny cours su windows uno può pensare sostanzialmente che o è un problema dello scheduler di windows oppure un problema di stallo fra thread. Lo stallo fra thread è un po' inverosimile, tuttavia plausibile (non conosciamo come è fatto blender). Uno stallo che però non si verificherebbe sui 6+6 core di intel, e allora viene il dubbio che ci sia qualche problema con lo scheduler di windows.
Altra soluzione, sono le solite ottimizzazione ad-hoc per questo o quel produttore di cpu...

i test di riferimento sono sempre stati cinebench e 3D max

3dmax che miserabilmente va' in crash sui loro server...

Scusa ma quale porting e quale nativo? Sono tutti e due compilati sulle rispettive piattaforme per le rispettive piattaforme, non c'è il "nativo" e il "porting"...

Poi il problema con l'HT o è un problema dello scheduler di windows, oppure è un non-problema, nel senso che blender, per la natura dei calcoli che effettua, tiene impegnate le unità esecutive in modo che non c'è beneficio nell'uso dell'HT.

Ma tornando con i piedi per terra, da quello che dice anandtech quando espone il problema delle prestazioni mutilate dell'opteron magny cours su windows uno può pensare sostanzialmente che o è un problema dello scheduler di windows oppure un problema di stallo fra thread. Lo stallo fra thread è un po' inverosimile, tuttavia plausibile (non conosciamo come è fatto blender). Uno stallo che però non si verificherebbe sui 6+6 core di intel, e allora viene il dubbio che ci sia qualche problema con lo scheduler di windows.
Altra soluzione, sono le solite ottimizzazione ad-hoc per questo o quel produttore di cpu...



3dmax che miserabilmente va' in crash sui loro server...

blender è sempre stato su linux, chiamalo come ti pare ma su win fa piu schifo che su linux; e il problema si persenta anche con gli xeon che danno valori discordanti non solo con gli opteron.




3dmax che miserabilmente va' in crash sui loro server...

come è uscita cinebench 11.5 perchè la 11 non supportava i core non ultipli di 4 e come hanno dovuto usare una alpha di blender useranno 3D max 2011 quando uscira ad aprile, visto che di max le alpha non sono disponibili.

blender è sempre stato su linux, chiamalo come ti pare ma su win fa piu schifo che su linux;

Mmmh, non credo...

http://wiki.blender.org/index.php/Dev:Ref/Supported_platforms

Non spiegherebbe perchè anche il sistema Opteron 2x2435 (8 core fisici) dimostri prestazioni del 50% superiori su SUSE. Con ogni probabilità è un problema di Blender (non dimenticate che è soltanto una versione alpha).

Il software Blender non ha responsabilità se Windows inizialmente riesce a renderizzare sfruttando il 100% del carico dei cores, ma col passare del tempo il processamento dei dati scema a solo il 25%... Molto probabilmente ci sarà qualcosa a livello di driver di gestione dei processori multicores AMD integrati nel S.O. Microsoft (gestione risparmio energetico o sincronizzazione dei cores) che non permette di mantenere una costanza di dati elaborati. Problema che su piattaforma Linux non viene lamentata, pur essendo il codice di Blender allo stesso identico livello di sviluppo (2.5 alpha2) in entrambi i sistemi operativi.

Il software Blender non ha responsabilità se Windows inizialmente riesce a renderizzare sfruttando il 100% del carico dei cores, ma col passare del tempo il processamento dei dati scema a solo il 25%...

Il SO non renderizza, non distribuisce il workload su più thread nè decide come i thread vengano sincronizzati. Tutto questo è responsabilità di Blender. Il SO non fà altro che schedulare i thread sulle CPU ed eseguire le richieste di sincronizzazione da parte dell'applicazione.

Il fatto che l'utilizzo scenda dal 100% al 25% può dipendere dal fatto che Blender non distribuisce il workload su più core in maniera ottimale o dal fatto che alcuni thread siano bloccati su delle primitive di sincronizzazione.

Inoltre non si può essere nemmeno certi che il divario di prestazioni sia dovuto al multithreading. Per farlo bisognerebbe misurare il tempo di esecuzione seriale del benchmark e vedere se le differenze tra Intel e AMD sussistono.

Molto probabilmente ci sarà qualcosa a livello di driver di gestione dei processori multicores AMD integrati nel S.O. Microsoft (gestione risparmio energetico o sincronizzazione dei cores) che non permette di mantenere una costanza di dati elaborati.

Senza fare del profiling è ipossibile a dirsi con certezza, ma è altamente improbabile che dipenda dal sistema operativo, dato che nelle altre applicazioni il problema non si manifesta. Parlare di un problema del sistema operativo quando il problema si riscontra solo con la versione alpha di una singola applicazione e senza dati più precisi, è infondato.

Problema che su piattaforma Linux non viene lamentata, pur essendo il codice di Blender allo stesso identico livello di sviluppo (2.5 alpha2) in entrambi i sistemi operativi.

1) Il fatto che un software sia multipiattaforma non implica che usi gli stessi algoritmi su piattaforme diverse.
2) Anche se usano gli stessi algoritmi, le API di threading sono differenti, quindi il codice non è lo stesso.
3) Il software è compilato con compilatori differenti.

Premetto che non ho seguito un granché la querelle su blender riguardo ai punti di percentuali più prestazionali in linux rispetto a windows che comunque andrebbe fatto su una release finale e non su un'alpha (stessa cosa varrebbe per una beta), ma:

1) Il fatto che un software sia multipiattaforma non implica che usi gli stessi algoritmi su piattaforme diverse.
2) Anche se usano gli stessi algoritmi, le API di threading sono differenti, quindi il codice non è lo stesso.
3) Il software è compilato con compilatori differenti.
1) In genere vengono usati gli stessi algoritmi, quando questo non accade, tentando di fare ottimizzazioni specifiche per piattaforma, significa di avere molto tempo a disposizione.
Comunque è facile accertarsene guardando se il rilascio sulle varie piattaforme è contemporaneo. Nel caso di ottimizzazioni specifiche c'è sempre una discrepanza di tempo (notevole) tra la disponibilità di un software per una piattaforma piuttosto che per un'altra.
2) Non ti seguo. Nei codici multipiattaforma, perfino nei casi di programmi in c++, vengono in genere usate librerie multipiattaforma, in modo che il tutto resti trasparente lato programmatore e poi il sistema operativo deciderà come gestire il tutto.
Quindi le differenze esistenti sono inevitabili.
3) Ok. Non sarebbe la prima volta che l'uso di compilatori differenti porta a risultati diversi (sebbene si tratti sempre di pochi punti percentuali).

Premetto che non ho seguito un granché la querelle su blender riguardo ai punti di percentuali più prestazionali in linux rispetto a windows che comunque andrebbe fatto su una release finale e non su un'alpha (stessa cosa varrebbe per una beta), ma:

1) In genere vengono usati gli stessi algoritmi, quando questo non accade, tentando di fare ottimizzazioni specifiche per piattaforma, significa di avere molto tempo a disposizione.
Comunque è facile accertarsene guardando se il rilascio sulle varie piattaforme è contemporaneo. Nel caso di ottimizzazioni specifiche c'è sempre una discrepanza di tempo (notevole) tra la disponibilità di un software per una piattaforma piuttosto che per un'altra.
2) Non ti seguo. Nei codici multipiattaforma, perfino nei casi di programmi in c++, vengono in genere usate librerie multipiattaforma, in modo che il tutto resti trasparente lato programmatore e poi il sistema operativo deciderà come gestire il tutto.
Quindi le differenze esistenti sono inevitabili.
3) Ok. Non sarebbe la prima volta che l'uso di compilatori differenti porta a risultati diversi (sebbene si tratti sempre di pochi punti percentuali).

2) il fatto che si usino librerie multipiattaforma non implica che il codice interno alla librerie sia identico anzi, la chiamata è identica ma il codice della libreria può essere fondamentalmente diverso

3) il compilatore Intel disabilita le simd per i processori non Intel e in un render non sono pochi punti percentuali

Premetto che non ho seguito un granché la querelle su blender riguardo ai punti di percentuali più prestazionali in linux rispetto a windows che comunque andrebbe fatto su una release finale e non su un'alpha (stessa cosa varrebbe per una beta), ma:

1) In genere vengono usati gli stessi algoritmi, quando questo non accade, tentando di fare ottimizzazioni specifiche per piattaforma, significa di avere molto tempo a disposizione.
Comunque è facile accertarsene guardando se il rilascio sulle varie piattaforme è contemporaneo. Nel caso di ottimizzazioni specifiche c'è sempre una discrepanza di tempo (notevole) tra la disponibilità di un software per una piattaforma piuttosto che per un'altra.
2) Non ti seguo. Nei codici multipiattaforma, perfino nei casi di programmi in c++, vengono in genere usate librerie multipiattaforma, in modo che il tutto resti trasparente lato programmatore e poi il sistema operativo deciderà come gestire il tutto.
Quindi le differenze esistenti sono inevitabili.
3) Ok. Non sarebbe la prima volta che l'uso di compilatori differenti porta a risultati diversi (sebbene si tratti sempre di pochi punti percentuali).

QUOTO in pieno.

1) Gli algoritmi fondamentali di renderizzazione in un software non cambiano in modo sostanziale. Inoltre è soprattutto nelle release Alpha che i softwares, offerti in versioni multipiattaforma, son molto simili tra loro. Solo nelle successive versioni, release candidate, vengono poi ottimizzati per dare il meglio.
Inoltre il problema delle cattive prestazioni su Windows di questi processori non si evidenzia solo con Blender Alpha, ma anche con Cinebench 11.5 nel quale 12 cores AMD @2,2ghz stanno dietro a 6 cores Intel @2,93ghz seppur affiancati dalla presenza di ulteriori 6 cores logici i quali non possono avere la stessa efficienza dei corrispettivi fisici. Sempre su piattaforma Windows, purtroppo in questi test (http://www.anandtech.com/show/2978/amd-s-12-core-magny-cours-opteron-6174-vs-intel-s-6-core-xeon/1) non è stata utilizzata una piattaforma Linux come con Blender per confronto, AMD colleziona altri cattivi risultati su:
a) SAP ERP 6.0 Enhancement package (-16%);
b) Oracle Charbench Calling Circle 10g Release 2 10.2 (-44%);
solo su:
c) vApus + real-world "Nieuws.be" Database, il risultato vede un +20% a favore di AMD in quanto tale software non riesce ad avvantaggiarsi appieno della funzione HyperThreading degli Xeon Intel.

2) Infatti, una volta affidato il tutto alle librerie (nello specifico multipiattaforma) sarà il sistema operativo a dover gestire il tutto. Il kernel di Windows 2008 Server è relativamente "giovane" e poco rodato ed efficiente e non sono io ad affermarlo, ma circa una settimana fà Dave Probert che è il Kernel Architect di Microsoft (http://www.diggita.it/story.php?title=Windows_poco_efficiente_con_le_CPU_multi-core), rispetto a quelli Linux che da anni gestiscono piattaforme hardware multicores a livello server e per i quali i 24 cores fisici di un sistema AMD sono più che alla portata.

3) Possibile che parte della responsabilità risieda nei compilatori utilizzati. In tal caso i test sarebbero poco inutili nel verificare la bontà e l'efficienza architetturale di una nuova piattaforma hardware. Assolutamente inutili nel caso in cui disattivino SIMD non riconosciute come "amiche"...

2) il fatto che si usino librerie multipoattaforma non implica che il codice interno alla librerie sia identico anzi, la chiamata è identica ma il cosice della libreria può essere fondamentalmente diverso

Si ma le differenze saranno limitate al massimo al richiamare api diverse in fuzione del sistema operativo, difficile che si mettano a fare ottimizzazioni specifiche, ci vuole molto tempo, aumenterebbe in modo rilevante la possibilità di maggiori bug in funzione della piattaforma utilizzata ed i tempi di rilascio di nuove librerie multipiattaforma ne soffrirebbero.

Si ma le differenze saranno limitate al massimo al richiamare api diverse in fuzione del sistema operativo, difficile che si mettano a fare ottimizzazioni specifiche, ci vuole molto tempo, aumenterebbe in modo rilevante la possibilità di maggiori bug in funzione della piattaforma utilizzata ed i tempi di rilascio di nuove librerie multipiattaforma ne soffrirebbero.

ciò non toglie che il codice eseguito sia diverso: api diverse--> codice diverso