Citazioneio non sono assolutamente preparato a riguardo. mi sfugge un concetto banale banale, per chi volesse rispondere. Se le cpu si suddividono pariteticamente il carico di lavoro di un processo non studiato per il smp, perchè lo fanno al 50% a testa e non al 100% a testa? se un processo non è studiato per il dual core o smp va a sfruttare un solo processore/core, qui invece parlate di utilizzo di metà di ciascun processore/core... mi sembra che stoni la cosa... se invece ho un processo che sfrutta il smp o il muticore dovrebbe attingere a pieno carico alle risorse dei processori/core.... no? (cioè, sicuramente è no ma  non ho capito perchè )

Ciao Ciao!



Questo messaggio è stato aggiornato da andreagiommi il 22/06/2006  alle ore  10:28:59

infatti quello che dici è corretto: in linea di massima un processo che nn è fatto per smp sarebbe eseguito più rapidamente da una sola cpu per il semplice fatto che nn ci dovrebbero essere spostamenti di dati tra una cpu e l'altra...
per quanto riguarda i multicore invece mi sembra di aver capito che abbiano una 3 cache in comproprietà, quindi li il problema nn si porrebbe nei termini del caso smp e quindi suddividere il carico tra i due nn porterebbe a nessuno svantaggio (credo )

Premesso che le mie affermazioni che iniziano con "suppongo" sono da ritenersi - potrà sembrare strano... - come supposizioni, in quanto io non sono un programmatore ed in base a ciò posso solo avanzare ipotesi sulle loro tecniche di ottimizzazione del codice, evito repliche punto-punto per non rendere il confronto eccessivamente noioso.

Mi limito ancora una volta a ribadire che la mia riflessione si fonda(va) sulla considerazione dei limiti ineludibili imposti dalla banda di memoria.
L'aumento del fsb senza il corrispondente aumento della frequenza della ram ha risibile impatto sulle prestazioni complessive del sistema. Non vedo vantaggi nell'avere 2, 4, 8, o anche 64 processori sullo stesso sistema, se questi poi dovranno servirsi di un solo controller di memoria che ha una banda equivalente a quella di una sola di tali cpu.

Per funzionare a dovere, entrambe le cpu dovrebbero "rivolgersi" ad due controller di memoria distinti. In caso contrario - cioè quello della Tyan - tale controller introduce tempi morti nel accesso contemporaneo (che non può essere possibile già a livello di principio) di entrambe le cpu alla ram.

Il fatto che AMD, nelle nuove architetture, abbia puntato ad eliminare alla radice il problema di tali colli di bottiglia (eliminando il NorthBridge ed introducendo il bus HT, inserendo il controller di memoria nella cpu stessa e migrando progressivamente - dal 754 al 939 - all'architettura dual channel memory) dimostra come il problema della bandwidth esistesse e fosse ben percepito come un fronte sul quale intervenire prima che i dual core facesso il loro ingresso sul mercato.

Ritenendo i lettori possano trarre sufficienti informazioni dai post finora pubblicati, considero totalmente inutile continuare a ribadire le mie convinzioni riguardo alle mainboard dual AthlonXP, che ho avuto il piacere di vedere all'opera di persona.
Le mie ultime esortazioni sono quindi rivolte:
- a mikepedo nell'acquistare e nel testare a dovere la mainboard Tyan in questione;
- a nix, se dovesse passare di qui, nel postare qualche test sulla sua Tyan dual Athlon;
- al moderatore Amigamerlin, nel postare anch'egli qualche dimostrazione a supporto delle proprie tesi, visto che ne ha l'opportunità avendo un sistema dual AthlonXP sottomano.



EDIT: ho scritto dual AthlonXP, mentre trattasi di AthlonMP.
x mike: una volta giravano voci di una possibile modifica per tramutare in MP un AthlonXP. Prova a cercare fra i thread più datati...

Questo messaggio è stato aggiornato da Superbox il 22/06/2006  alle ore  12:01:24

Citazione

Citazioneio non sono assolutamente preparato a riguardo. mi sfugge un concetto banale banale, per chi volesse rispondere. Se le cpu si suddividono pariteticamente il carico di lavoro di un processo non studiato per il smp, perchè lo fanno al 50% a testa e non al 100% a testa? se un processo non è studiato per il dual core o smp va a sfruttare un solo processore/core, qui invece parlate di utilizzo di metà di ciascun processore/core... mi sembra che stoni la cosa... se invece ho un processo che sfrutta il smp o il muticore dovrebbe attingere a pieno carico alle risorse dei processori/core.... no? (cioè, sicuramente è no ma  non ho capito perchè )

Ciao Ciao!



Questo messaggio è stato aggiornato da andreagiommi il 22/06/2006  alle ore  10:28:59

Perchè il sistema operativo (NT4,Win2K, winXp PRO) sono sistemi operativi che gestiscono l'SMP tradizionale.
Quindi il sistema operativo avverte la presenza della seconda CPU e la utilizza di conseguenza suddividendo il carico al 50%, se non diversamente specificato.

Il "diversamente specificato" è riferito ai programmi con la gestione SMP che determinano il numero di thred da assegnare ad ogni CPU. Nel caso di Photoshop e lightwave o per tutte quelle applicazioni che utilizzano l'SMP viene specificato il numero di treda da utilizzare (generlamente il doppio rispetto alla singola CPU). Ecco perchè i tempi di rendering e di applicazioni di filtri vengono dimezzati. In quel caso il taskmanager riporta l'utilizzo del 100% di entrambe le CPU. Provare per credere.

Non posso rispondere in merito al dual core ed al suo comportamento con il sistema operativo perchè non ho approfondito l'argomento. Posso comunque ipotizzare "driver" per la corretta gestione (come accade per gli AMD64 quando utilizzati a 32 bit) oppure aggiornamenti del sistema operativo stesso che prevedono l'utilizzo dei dual core.



Questo messaggio è stato aggiornato da Amigamerlin il 22/06/2006  alle ore  11:23:35

dual processor o dual core l'os dovrebbe comportarsi allo stesso modo.... quindi il nodo della questione è che il os è stupido... in quanto, se ad un processo non gli si dice quanti processori ci sono (e a lui che gli frega) e il sistema operativo suddivide le chiamate a cpu e memoria per ogni core/cpu presente il problema della non sfuttabilità del dual processor e dual core non esisterebbe... un carro che sia trainato da 2 buoi o da 4 buoi sempre lo stesso carro è... perchè in informatica un processo deve essere "costruito" dieversamente a seconda del numero di processori che ci sono?

D'altra parte se prendiamo il campo video, dove le schede video con la struttura a pipeline multiple e tmu funzionano similmente ad un multiprocessore.... e un gioco mica si chiede quante pipe ha la scheda per girare, ne il programmatore lavora su una specifica configurazione... boh! dubbi banali forse i miei.....

Ciao Ciao!



Questo messaggio è stato aggiornato da Amigamerlin il 22/06/2006  alle ore  13:20:42 -
EDIT. Scusate ho editato invece di quotare

Questo messaggio è stato aggiornato da Amigamerlin il 22/06/2006  alle ore  13:21:50

Da quanto rispondi (superbox) suppongo, che non hai avuto il tempo di leggere la documentazione tecnica linkata e posso comprenderlo.

In ogni caso, indipendentemente se sono opinioni, le stesse devono avere un minimo di fondamento altrimenti si discuterebbe sul sesso degli angeli.

Detto ciò evito di quotare nuovamente punto punto, limitando solamente a puntualizzare che:

1) Non vi è aumento di FSB ne tantomeno raddoppi.

2) I vantaggi di sistemi MULTICPU sono tangibili altrimenti gli stessi non avrebbero ragione di esistere con palese riferimento i cluster ed ai sistemi parallelati di calcolo.

3) In merito ai controller di memoria lascerei da parte problematiche tecniche realizzative ed eventuali suggerimenti costruttivi per coloro che fanno questo mestiere; non credo sia possibile ne per me ne per te disquisire sulle tecniche da adottare e le soluzioni da intraprendere. In ogni caso non è l'argomento del disquisire.

4) Non vi è dubbio che il problema della bandwidth esistesse, continua ad esistere ed è ben percepito ma non mi sembra che sia, unitamente al dual core l'argomento del disquisire se trattato nella sua globalità. Nello specifico, invece, tale problematica se vi è non si sente in quanto, come ripetuto più volte, i software che gestiscono l'SMP rendono il doppio o quasi.

5)Anch'io consiglio vivamente e spassionatamente a Mike di compare questa dual !!

6) Anch'io consiglio a Nix se dovesse passare di qui, nel postare qualche test sulla sua Tyan dual Athlon

7)In merito ai test li farò solo in relazione a Quake IV tempo ed impegni permettendo.

8)In merito alla dimostrazione delle mie tesi credo che il link della review di Hardware.Fr le confermi tutte pienamente (riduzioni di tempi di attesa in caso di software che gestiscono l'SMP ).

9)Confermo pienamente quanto scritto da Superbox in merito alla possibilità di trasformare due XP in MP.




Questo messaggio è stato aggiornato da Amigamerlin il 22/06/2006  alle ore  14:00:10

quando faccio i bench di super pi, io utilizzo un core a tavoletta (100%), ma col task manager mi segna 50% perchè avrei un'altro core da sfruttare ma sta quasi a riposo.

CitazioneAndreagiommi

dual processor o dual core l'os dovrebbe comportarsi allo stesso modo.... quindi il nodo della questione è che il os è stupido... in quanto, se ad un processo non gli si dice quanti processori ci sono (e a lui che gli frega) e il sistema operativo suddivide le chiamate a cpu e memoria per ogni core/cpu presente il problema della non sfuttabilità del dual processor e dual core non esisterebbe... un carro che sia trainato da 2 buoi o da 4 buoi sempre lo stesso carro è... perchè in informatica un processo deve essere "costruito" dieversamente a seconda del numero di processori che ci sono?

D'altra parte se prendiamo il campo video, dove le schede video con la struttura a pipeline multiple e tmu funzionano similmente ad un multiprocessore.... e un gioco mica si chiede quante pipe ha la scheda per girare, ne il programmatore lavora su una specifica configurazione... boh! dubbi banali forse i miei.....

Ciao Ciao!

Fortunatamente hai fatto le dovute premesse in merito alle tue perplessità nei post precedenti !!

Allora i driver per i Chipset a cosa servirebbero ? Se fosse come dici tu non avremmo mai probelmatiche di driver. Ne basterebbe uno universale. Stesso dicasi per le schede video che istruiscono il layer competente (DirectX - Opengl ) sulle feature che è possibile utilizzare.

Altrimenti... dimmi ... perchè Photoshop rende il doppio se utilizzato su sistemi SMP?

Dimmi ... perchè viene dichiarato il supporto SMP per windows 2000 Windows XP PRO ed è dichiaratamente non SMP Win98 Me e WinXP Home?

Dimmi ... perchè viene dichiarato addirittura il numero delle CPU supportate dal sistema operativo ( 2CPU  per windows 2000 e Windows XP PRO e 4CPU per NT4.0 Server e windows 2003)


Dimmi ... perchè esistono kernel Linux / Freebsd /unix che utilizzano SMP e kenel Monoprocessori?

Mi daresti gentilmente risposte per questi quesiti?



EDIT: Aggiunte alcune precisazioni

Questo messaggio è stato aggiornato da Amigamerlin il 22/06/2006  alle ore  14:39:46

Citazionequando faccio i bench di super pi, io utilizzo un core a tavoletta (100%), ma col task manager mi segna 50% perchè avrei un'altro core da sfruttare ma sta quasi a riposo.

Controlla se di SuperPI esiste una versione con il supporto per il multiprocessore.
Cerca su internet magari un utility del genere c'è.
In ogni caso puoi fare dei test con Photoshop, lightwave 3D, 7Zip, TMPEGencoder etc.
Tutti software questi che utilizzano l'SMP.

Mi raccomando manteniamo positivo il clima del forum e tentiamo i rispettarci sempre l'un l'altro nonostante le divergenze di opinioni

lo so, lo so, era solo per far capire che se task manager segna 50% non è perchè usa il 50% dei due core o cpu, ma perchè ne sfrutta uno appieno e basta. comprimere divx 6.1 o 6.2 usa entrambi i core, così come dicevi tu tmpenc

Citazione

Citazione

Citazioneio non sono assolutamente preparato a riguardo. mi sfugge un concetto banale banale, per chi volesse rispondere. Se le cpu si suddividono pariteticamente il carico di lavoro di un processo non studiato per il smp, perch� lo fanno al 50% a testa e non al 100% a testa? se un processo non � studiato per il dual core o smp va a sfruttare un solo processore/core, qui invece parlate di utilizzo di met� di ciascun processore/core... mi sembra che stoni la cosa... se invece ho un processo che sfrutta il smp o il muticore dovrebbe attingere a pieno carico alle risorse dei processori/core.... no? (cio�, sicuramente � no ma  non ho capito perch�:D)

Ciao Ciao!



Questo messaggio � stato aggiornato da andreagiommi il 22/06/2006  alle ore  10:28:59

Perch� il sistema operativo (NT4,Win2K, winXp PRO) sono sistemi operativi che gestiscono l'SMP tradizionale.
Quindi il sistema operativo avverte la presenza della seconda CPU e la utilizza di conseguenza suddividendo il carico al 50%, se non diversamente specificato.

Il "diversamente specificato" � riferito ai programmi con la gestione SMP che determinano il numero di thred da assegnare ad ogni CPU. Nel caso di Photoshop e lightwave o per tutte quelle applicazioni che utilizzano l'SMP viene specificato il numero di treda da utilizzare (generlamente il doppio rispetto alla singola CPU). Ecco perch� i tempi di rendering e di applicazioni di filtri vengono dimezzati. In quel caso il taskmanager riporta l'utilizzo del 100% di entrambe le CPU. Provare per credere.

Non posso rispondere in merito al dual core ed al suo comportamento con il sistema operativo perch� non ho approfondito l'argomento. Posso comunque ipotizzare "driver" per la corretta gestione (come accade per gli AMD64 quando utilizzati a 32 bit) oppure aggiornamenti del sistema operativo stesso che prevedono l'utilizzo dei dual core.



Questo messaggio � stato aggiornato da Amigamerlin il 22/06/2006  alle ore  11:23:35

dual processor o dual core l'os dovrebbe comportarsi allo stesso modo.... quindi il nodo della questione � che il os � stupido... in quanto, se ad un processo non gli si dice quanti processori ci sono (e a lui che gli frega) e il sistema operativo suddivide le chiamate a cpu e memoria per ogni core/cpu presente il problema della non sfuttabilit� del dual processor e dual core non esisterebbe... un carro che sia trainato da 2 buoi o da 4 buoi sempre lo stesso carro �... perch� in informatica un processo deve essere "costruito" dieversamente a seconda del numero di processori che ci sono?

D'altra parte se prendiamo il campo video, dove le schede video con la struttura a pipeline multiple e tmu funzionano similmente ad un multiprocessore.... e un gioco mica si chiede quante pipe ha la scheda per girare, ne il programmatore lavora su una specifica configurazione... boh! dubbi banali forse i miei.....

Ciao Ciao!



Questo messaggio � stato aggiornato da Amigamerlin il 22/06/2006  alle ore  13:20:42 -
EDIT. Scusate ho editato invece di quotare

Questo messaggio � stato aggiornato da Amigamerlin il 22/06/2006  alle ore  13:21:50

nel caso del video il tuo errore è che nn consideri i driver... quelli si occupano di gestire le pipeline che la scheda possiede
nel caso cpu, qualcuno deve pur dire che tipo di architettura usare (1 o più core), e nn certo lo può dire il sistema operativo, che è stupido sì dato che lui si occupa di processi, il resto nn gli compete : i processi sono fatti da uno o più thread... se tu programmatore vuoi sfruttare il parallelismo, sei tu che ti devi fare carico di suddividere il carico di lavoro per avere dei vantaggi. esempio stupido: se in un videogioco banalmente si dividesse video da audio, sarebbe un parallelismo da ciucci, perchè una cpu sarebbe pressocchè intasata e l'altra a mezzo servizio. per questo il SO nn può in sostanza intervenire -> lui nn sa cosa deve fare
quindi a priori si debbono fare delle scelte
in aggiunta, se un programma scritto per smp venisse fatto girare su un monoprocessore, i risultati dovrebbero essere in linea teorica peggiori che se fatto in un solo thread, è per questo cheal momento nn c'è un grande sviluppo di questi software