nom dokładnie i jeszcze test dla wykazania różnic między poszczególnymi kombinacjami byłyby miłym dodatkiem do testu

to na koncu mojej wypowiedzi masz przeciez sugestje ze tak moze byc ale to i tak wypaczone zostaja wyniki trzech rdzeni.. tak czy inaczej test jest nie do konca obiektywny no i powinno byc napisane ktore rdzenie zostawaly wylaczone albo jaki mialo wplyw na wydajnosc wylaczanie poszeczegolnych.

dodane.
mozliwe sa kobinacje
4 rdzenie 4mb l2 na poszczególne dwa (kazdy rdzenie dysponuje wspóldzielonymi z drogim 4mb l2)
3 rdzenie 4mb l2 na jeden i 4mb l2 na dwa pozostałe (jeden rdzen sysponuje 4mb l2 pozostałe dwa dziela sie również 4mb)
2 rdzenie 4mb l2 na dwa rdzenie (dwa rdzenie dziala sie 4mb l2)
2 rdzenie 4mb l2 na rdzen. (dwa rdzenie kazdy dysponuje 4mb l2)

Amras, tu chyba by trzeba wpierw upewnić się, które rdzenie są wyłączane, boz tego co widać z biosu, można to rzrobić na kilka kombinacji...

jezeli sie nie mysle w artykule pominieto bardzo istotny aspekt pamieci l2 ktora po wylaczeniu dwuch rdzeni powoduje powstanie nam dwurdzeniowego monstra z pamiecia l2 po 4mb na rdzen.. w specyficznych przypadkach tak duza pamiec podreczna ma prawo spowodowac przyspiesznie konfiguracji dwurdzeniowej na tyle by wyprzedzic 4rdzeniowa. stawiedzono to nawet w jednym z testow pclaba dotyczacym 4rdzeniowki intela... nalezalo by porownywac raczej wylaczajac dwa rdzenie posiadajace fizycznie te sama pamic l2, jeednak przy 3 rdzeniach test bedzie juz nie mozliwy..

zrozumiałem z tego testu tylko tyle, że wiele aplikacji wielowątkowych jest napisanych na skróty i nie działają prawidłowo. chwilowa zadyszka z przechodzeniem na wielordzeniowość a także i między innymi na 64 bity z pewnością utrudni optymalizację oprogramowania, ale to będą według mnie problemy przejściowe, a nie stała bariera.

Świetny artykuł, czytelny i jasny.

Kentsfield ma 2x4MB cache (po 4MB na parę rdzeni) i właśnie to jest jedyny powód wyłączania rdzeni. Ale wg mnie starczy ustawić koligacje w Menedżerze urządzeń a nie "wycinać"...

OpenMP troche pomaga w algorytmach przetwarzania danych.
Myśle że dlatego WinRar tak łądnie się skluje i będzie skalował jeszcze.

Moim zdaniem problem sprawiają same języki programowania, takie jak C i C++, które były opracowywane z myślą o systemach jednoprocesorowych. Wpółbieżność realizuje się w nich przez odwołania do funkcji systemowych, nie jest ona częścią samego języka.
Przykładami produkcyjnych, a nie akademickich języków programowania które wspierają współbieżność są ADA 95 oraz ADA 2005, używane przez amerykański przemysł lotniczy (np. Boening) i przez Departament Obrony USA.
Wadą języka ADA jest niepopularna składnia podobna do składni Pascala, i mała ilość ofert pracy w Polsce.
Proponuję zajrzeć do książki Cormena "Wprowadzenie do Algorytmów" żeby zobaczyć jak powinny działać współbieżne języki programowania.

Czy ten test jest miarodajny? Jak wygląda sprawa cache po takim "wyłączaniu" jąder?

Poza tym, że tytuł "wycinanie jąder" źle mi się kojarzy, to artykuł fajny.

Odpowiedni kompiler zalatwi sprawe wielowatkowosci... programista specjalnie nie musi sobie zawracac tym glowy... problem jest raczej nieco inny... skompilowany program bedzie musial byc dostarczany w wielu wersjach... dla AMD, dla Intela, oraz dla 1, 2 i 4 rdzeni... co daje jakies 8 mozliwosci... mysle, ze dlatego nie doczekalismy sie jeszcze prawdziwie wielowatkowych aplikacji dla mas.

P.S. Ja tam 2 rdzeniowca "dorobię" się pewnie dopiero za ~2lata więc się nie przejmuję... Ale artykuł bardzo fajnu

Nobla za tytuł artykułu!!! Może ja tam jestem starym zbokiem, ale po jego przeczytaniu parsknąłem śmiechem

pożądny art!

tirinti ROX GHz rox

edit: a moze na odwrot ?

przewroty tytuł

Niestety, portale zamieszczają opiniotwórcze artykuły a potem na forach ludzie piszą głupoty.

Np RS ostatnio twerdził że Windows 2003 nie wspiera NUMA, tylko Vista.

NUMA w Windows2003

powyżej materiał źródłowy Microsoft.
To troche jak w Wyborczej.

Właśnie "megatasking" bardziej by mnie interesował bo zazwyczaj robię kilka rzeczy naraz i np. z chęcią pograłbym sobie w jakąś wymagającą grę jednoczesnie kodując filmy do xvid. Ale myślę że nawet teraz mógłbym to odczuć bo mam w tej chwili otwartych 19 zakładek w Operze - odświerzenie naraz wszystkich (Ctrl+F5) powoduje małą przywieszkę...

Ciekawe dlaczego wszyscy powtarzają tą bzdurę o tym ze NT powstał w DEC. To że pan to powtarza to mnie nie dziwi.

Polecam obejrzeć Operating System Evolution w którym jest wywiad z człowiekem stojącym za powstaniem NT.
Dla tych co średnio znają angielski, lub wogóle Rob Short razem z kilkoma innymi osobami pracował w DEC nad nowym procesorem RISC (nie systemem, tylko procesorem) gdy w pewnym momencie uslyszeli ze ich projekt został przerwany i ich biuro przeniesione do innego stanu. Postanowili wedy opuścić DEC i zrządzeniem losu trafili do Microsoftu. Tam zaczeli nowy projekt związany z NT. Projekt składał się z dwóch grup, programowej i sprzętowej i zakładał stworzenie nie tylko systemu ale również nowego sprzętu na którym ten system miał pracować. Wg nich pecety nie nadawały się do tego. Stworzyli na własne potrzeby własny hardware (na filmie widać płytę główną tego systemu) na który wtedy powstawał NT. Potem dopiero zrezygnowali ze swojego sprzętu i postanowili przenieść NT na procesory Intela, głównie dlatego, że uznali że Intel był lepszy od nich w wymyślaniu nowego sprzętu I dopiero później podjeli próbę przeniesienia NT na DEC Alpha, 64 bitowy procesor (4 lata po rozpoczęciu projektu).

Tak więc DEC nie miał nic wspólnego z NT po za paroma osobami które pracowały nad sprzętem w DEC'u i potem pracowały nad sprzętem w Microsofcie. Software powstawał zupełnie od zera w Microsofcie.