Jump to content
Ménemszól.hu
  • 0

„Hallgatni akarunk a vásárlóinkra” - Windows 10


bgrassfield

Kérdés

http://index.hu/tech/2014/10/15/az_ufok_elraboltak_a_microsoft_vezetoit_es_androidokkal_helyettesitettek_oket/#

 

A kérdés az, hogy hajlandóak-e a kezdetektől követett CPU kezelést végre leváltani, hogy a legalsó hardware-szinten egyszálúvá váló végrehajtást ténylegesen többszálúvá váljon, mint a Linuxok és Unixok és minden más erre alapuló oprendszerek esetében? Ha igen, akkor megvan az esély arra, hogy értékelhető, a CoreAudioval megegyező minőségű interfész legyen az ASIO-ból.

Link to comment
Share on other sites

válasz erre a kérdésre

Recommended Posts

ezek közül semminek sincs semmi köze az MS programozóihoz (a "third party" külső fejlesztők programjait jelenti, nem az MS-ét), végképp nem az állítólagos szálkezelési problémához, amit először említettél.

 

kérdezem hát ismét: mire gondoltál azalatt?

Link to comment
Share on other sites

Én írtam a szálkezelést, nem DeMarco. :) 

 

Egyébként a következő a probléma: a Windowsban a task scheduler egy darab példányban fut, függetlenül attól, hogy mennyi processzormag áll rendelkezésre. Ez az összes Linux és Unix alapú (tehát OSX is)  oprendszerben helyesen van implementálva, tehát annyi példányban jön létre a scheduler, ahány processzormag létezik, és ezek fölé helyezkedik a process pool, ami csak annyit optimalizál, hogy az egy brancsba tartozó programok lehetőleg egy magon fussanak. A Windowsban ezzel szemben a task scheduler osztja el a programok között az összes erőforrást - ami üvegnyak effektust hoz létre, hiszen egy process felel az összes többi sebességéért, ám annak idő kell.

 

Erről itt lehet olvasni: http://msdn.microsoft.com/en-us/library/windows/desktop/dd405503(v=vs.85).aspx

 

A ThreadPool gyakorlatilag egy szálont fut, és legfeljebb 64 processzormagot tud meghajtani - egyedül. Köszi.

 

Pontosítás: Windows 7 után már több ThreadPool is létezik, amik egyenként továbbra is legfeljebb 64 unitot hajtanak meg, amiket ProcessorGroupnak hívnak. Tehát ha nem brutál szerveren fut a Windows 7 vagy későbbi változata, akkor továbbra is egy ThreadPool kegyeg a gépedben.

Link to comment
Share on other sites

Én írtam a szálkezelést, nem DeMarco. :) 

 

Egyébként a következő a probléma: a Windowsban a task scheduler egy darab példányban fut, függetlenül attól, hogy mennyi processzormag áll rendelkezésre. Ez az összes Linux és Unix alapú (tehát OSX is)  oprendszerben helyesen van implementálva, tehát annyi példányban jön létre a scheduler, ahány processzormag létezik, és ezek fölé helyezkedik a process pool, ami csak annyit optimalizál, hogy az egy brancsba tartozó programok lehetőleg egy magon fussanak. A Windowsban ezzel szemben a task scheduler osztja el a programok között az összes erőforrást - ami üvegnyak effektust hoz létre, hiszen egy process felel az összes többi sebességéért, ám annak idő kell.

 

Erről itt lehet olvasni: http://msdn.microsoft.com/en-us/library/windows/desktop/dd405503(v=vs.85).aspx

 

A ThreadPool gyakorlatilag egy szálont fut, és legfeljebb 64 processzormagot tud meghajtani - egyedül. Köszi.

 

Pontosítás: Windows 7 után már több ThreadPool is létezik, amik egyenként továbbra is legfeljebb 64 unitot hajtanak meg, amiket ProcessorGroupnak hívnak. Tehát ha nem brutál szerveren fut a Windows 7 vagy későbbi változata, akkor továbbra is egy ThreadPool kegyeg a gépedben.

köszi és elnézést, ezekben az "új" fórum layout-okban mindig átugrok a nevek felett :) fura volt így Windows 8 magasságában, hogy mire gondolhattál (nekem már a thread pool is per process-ként volt meg), de így már értem, hogy mit is nehezményeztél. 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...