Dual Core e HyperThreading: un possibile bug
Alcune analisi con processori Xeon DP hanno evidenziato un possibile problema del sistema operativo Windows XP, nella gestione di sistemi biprocessore con tecnologia HyperThreading attivata
di Paolo Corsini pubblicata il 08 Marzo 2005, alle 14:17 nel canale ProcessoriWindowsMicrosoft










Google Pixel 11 Pro XL: fotocamera al top, batteria indietro. Luci e ombre del nuovo flagship
Non sai programmare? Ecco cosa si può fare con un LLM e una GeForce RTX 5070 Ti
Recensione Samsung Galaxy Z Fold8 Ultra: il pieghevole più famoso diventa quasi perfetto
La missione per salvare il telescopio spaziale Swift è fallita, si cercano altre opzioni ma il tempo sta per scadere
La stella S301 è così vicina al buco nero Sagittarius A* al centro della Via Lattea da risentire della sua rotazione
Chery accelera sulla robotica: Aimoga si prepara alla quotazione in borsa
Voigtländer Nokton 23mm e 35mm f/1.2 in argento per Fujifilm X, in arrivo da settembre
Il Lunar Reconnaissance Orbiter della NASA ha ripreso il cratere creato dal secondo stadio del Falcon 9 sulla Luna
Prova a beffare il tribunale con un messaggio nascosto per l'IA: viene beccato e lo fa ancora
Pasticcio Freelander: usa l'immagine di una scocca della concorrenza sul sito ufficiale
A New York apre la clinica del fondatore di Spotify: scansiona il corpo, 25.000 in lista d'attesa
Control Resonant entra in fase Gold e rinvia l'uscita della copia fisica
HONOR Pad 20 Pro è ufficiale: un ottimo tablet di fascia media, arriverà in Italia?
Tesla Robotaxi sfonda dei dissuasori: il software era appena stato definito impeccabile
Call of Duty: Modern Warfare 4 presenta il nuovo cast della campagna single player nel trailer
Intel Arc più veloce fino al 5% su Linux: Mesa attiva la compressione anche per DXVK
Il tuo ETF ha molta più NVIDIA di quanto pensi: l'allarme della BCE









61 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoUn bel Service pack 3 (Intel Edition) e tutto torna a posto
in questo caso Ecstrim Ediscion allora
Se dal punto di vista di una dual-cpu con ht posso capire che non si possa a livello hw decidere l' ordine delle cpu (fisiche e logiche), da un punto di vista dual-core, quindi dove l' assegnazione é fissa, non sarebbe più semplice organizzare la cosa via hardware, dentro la cpu stessa, fare cioé cpu1-cpu2-cpu1ht-cpu2ht ?
Attualmente se ho capito é come se venissero assegnati come ordine questi: (ammettendo anche cpu=core)
1 - cpu1ht1
2 - cpu1ht2
3 - cpu2ht1
4 - cpu2ht2
Se invece proprio a livello hw avessimo
1 - cpu1ht1
2 - cpu2ht1
3 - cpu1ht2
4 - cpu2ht2
sarebbe risolto il problema. Quel che voglio dire, é che a livello di controller (immagino, sono digiuno di molti concetti) della cpu venga assegnato quell' ordine, che poi viene utilizzato dallo scheduler per smistare i thread.
problema
Secondo me in questo modo il problema nn può essere risolto, come ho scritto nel post precedente! Quando si danno in pasto ad un p4 con ht attivato 2 thread, questi nn vengono eseguiti in realtà contemporaneamente, bensì tramite tecniche di register renaming si passa dall'esecuzione di uno a quella dell'altro ogni qual volta vi sia da attendere un qualche tipo di fault da una memoria o altri conflitti. Quindi se vengono assegnati due grossi thread di calcolo al un singolo core le prestazioni saranno scarse in confronto all'esecuzione su core diversi... questo indipendentemente dall'"ordine" delle cpu dentro lo scheduler, semplicemente egli nn sa cosa il thread debba eseguire (come è giusto che sia, altrimenti si porterebbe l'ht a livello di codice cosa non bella)Re: problema
questo indipendentemente dall'"ordine" delle cpu dentro lo scheduler, semplicemente egli nn sa cosa il thread debba eseguire (come è giusto che sia, altrimenti si porterebbe l'ht a livello di codice cosa non bella)
E' chiaro questo...ma già assegnare le CPU in ordine diverso potrebbe aiutare... Comunque l'HT a livello di codice già esiste...vedi le SSE3...
x cionci
Secondo me è inutile assegnare le cpu in ordine diversoper i motivi scritti prima: non c'è determinismo nell'assegnamento di un thread ad una unità di esecuzione più performante o meno!
Nelle SSE3 ci sono 2 istruzioni per la gestione dei thread Monitor e MWAIT: servono solo per ottimizzare consumi e prestazioni nei casi in cui un thread si deve sospendere in attesa di un qualsiasi evento (es spin-wait) non sono indispensabili
comunque ringrazio coloro che mi hanno (forse) risposto
ci si sente prossimamente e statemi bene
x MaxArt
Qualche errore macroscopico:La prima cpu pipelined x86 è stata il 386 (pipe di 4 stage).
Il concetto di cpu superscalare invece è tutt'altra cosa: esistono all'interno dello stesso core più path di esecuzione delle istruzioni, quindi più pipeline lavorano affiancate. La prima cpu x86 superscalare è stata il Pentium, con un parallelismo pari a due (anche se il secondo path nn è in grado di eseguire il set completo di istruzioni)
se è cosi non rispondo.
e sull' uso di queste cpu su linux si sa qualcosa?
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".