[Железо] Вопросы про ядра и потоки

1. Значит, что там 4 одновременно исполняемых потока. И каждая пара из них выполняется на одном исполнительном устройстве.

2. Нет.

3. Может. А может и нет.

1. тыц;
2. нет;
3. на одном.

>будет работать на одном?
скорее в каждый n-ый отрезок времени, т.к. сия софтина будет скакать с ядра на ядро

> там 4 одновременно исполняемых потока. И каждая пара из них выполняется на одном исполнительном устройстве.

Да с чего бы каждая? На каждом «исполнительном устройстве» - по паре, это да.

> скорее в каждый n-ый отрезок времени, т.к. сия софтина будет скакать с ядра на ядро

Ага, и прощай процессорный кэш и турбобуст. Глупости пишите.

ахаха - порвало в клочья

>Ага, и прощай процессорный кэш и турбобуст

Привет, L3. а турбобуст вообще через одно место работает.

Так и вижу как в многоядерных системах программы порхают с ядра на ядро как бабочки на лугу и водят хороводы. Красота.

>> скорее в каждый n-ый отрезок времени, т.к. сия софтина будет скакать с ядра на ядро

Ага, и прощай процессорный кэш и турбобуст. Глупости пишите.

В общем случае, он прав.

1. man HyperThreading. Вкратце: система будет исполнять 4 потока, как будто у нее 4 ядра (потоки на одном ядре переключаются так: когда выполняющийся поток запрашивает дорогостоящую операцию, например, обращение к оперативке, то потоки переключаются).

2. Нет

3. Если прога не распараллелена - на одном.

Можно ссылку на документацию?

> Привет, L3

Ну да, L2 и L1 не нужны.

а турбобуст вообще через одно место работает.

tell me moar

> Можно ссылку на документацию?

Ссылку на здравый смысл тебе не дать? Если есть свободный процессор, ядро отправит готовую к выполнению задачу на него, вне зависимости от того, на ккаком процессоре эта задача выполнялась ранее.

А вот для того, чтобы удержать задачу на процессоре, придумали affinity mask.

согласен - красиво:
http://ompldr.org/vYTBlYg/22.08.2011-23:01.png
а вот с привязкой только к первому ядру - http://ompldr.org/vYTBlYw/22.08.2011-23:02.png
как видишь задача одна и та же (смотри пид в топе)

лучше соответствующий кусок кода из ядра привести, так убедительнее будет )

> лучше соответствующий кусок кода из ядра привести

Слишком много труда для объяснения очевидной вещи.

> Если есть свободный процессор, ядро отправит готовую к выполнению задачу на него

Ok, почитал про scheduling domains в ядре. Действительно на системах с дешевой «переброской» задач (с hyper threading, например) ядро будет делать частую балансировку. На нормальных NUMA такого не будет.

Я не проверял как оно в линуксе, но в венде однопоточная игрушка грузить только одно ядро, а не скачет с одного на другое. пр выходе из старых игрушек всегда в истории 100% загрузка одного ядра. Да и зачем ей(задаче) скакать если ее с этого ядра никто не вытесняет?

> Да и зачем ей(задаче) скакать если ее с этого ядра никто не вытесняет?

А если вытесняет?

> на системах с дешевой «переброской» задач (с hyper threading, например) ядро будет делать частую балансировку. На нормальных NUMA такого не будет.

Опуская критерий «нормальности», даже на NUMA будет балансировка. Не такая частая, как на обычном multicore, но всё равно будет.

Добавлю в тему свой вопрос.

Имеет ли смысл на 4м пне с HT пускать make с ключем -j2? Мне порой кажется, что с ним процесс сборки идет дольше чем без него...

-j2 всегда имеет, даже на одноядерном. Не забывай, что во время компиляции много операций чтения/записи на диск. Но вообще, с HT даже с -j3 должен быть прирост. У меня на нетбуке было быстрей.

Агась, спасибо, учту на будущее.

HT - смысл в том, что в процессоре (ядре) дофига модулей и редкий код использует их все, те, которые не используются одним потоком, можно занять другим, который их использует.

n ядер - как бэ n процессоров, но они висят на общей шине и имеют общие кеши L2 (Core 2 *)/L3 (Core i*), поэтому производительность не совсем равна n поцам.

Ну да, L2 и L1 не нужны.

L1 и так при переключения контекста выносится.

А зачем вытеснять, когда 2ое ядро свободно и можно новую задачу(вытесняющую) повесить на него?

а если задач больше чем ядер? ;)

Если так то да. Я исходил из того что «скорее в каждый n-ый отрезок времени, т.к. сия софтина будет скакать с ядра на ядро» это касается случая когда тяжелая софтина запущена почти монопольно, игра например.
А если куча процессов и мало ядер, то есть affinity. По идее грамотный шедулер должен автоматически мягкую привязку потока к ядру делать при запуске. Мягкую имею ввиду что без особой нужды не перебрасывать

ну если генерить кучу прерываний, то скакать будет как ненормальная :3
можешь приколоться с циклами типа while true;do bla-bla-bla;done )

Не знаю, как у остальных, но у меня, судя по конькам, любой более-менее тяжёлый процесс _постоянно_ скачет с ядра на ядро.

Надо будет попробовать. На венде примерно знаю поведение, т.к. программил много под нее, а в линуксе не очень знаю

ну можно даже с glxgears поиграцо:
если сделать окно их скажем в 20х20, то нагрузка почти полностью на одном ядре
если же почти фуллскрин, то нагрузка размазывается, т.к. первому ядру становицо тяжко, а второе простаивает, потому часть нагрузки на второе ядро отправляецо

>> Ну да, L2 и L1 не нужны.

L1 и так при переключения контекста выносится.

С чего это? Хотелось бы увидеть пруф.

> Не знаю, как у остальных, но у меня, судя по конькам, любой более-менее тяжёлый процесс _постоянно_ скачет с ядра на ядро.

Просто у тебя многоядерный процессор с шареным L2 кэшом. Угадал?

Да ну? Вот в оконном режиме:

Cpu0  :  0.6%us,  1.3%sy,  0.6%ni, 97.5%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  2.0%us,  0.7%sy,  0.3%ni, 96.7%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  : 82.7%us, 17.3%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  1.3%us,  0.3%sy,  0.0%ni, 98.0%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st

Cpu0  :  2.9%us,  2.2%sy,  0.6%ni, 94.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  1.3%us,  1.0%sy,  0.3%ni, 97.1%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu2  : 39.2%us, 59.1%sy,  0.0%ni,  1.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  1.6%us,  1.0%sy,  0.0%ni, 97.1%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st

не полноэкранный, а оконный почти во весь моник
читай внимательней

ОК. Нагрузка до:

Cpu0  :  0.0%us,  1.0%sy,  0.3%ni, 98.0%id,  0.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  2.3%us,  1.6%sy,  1.0%ni, 94.8%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  1.3%us,  1.0%sy,  0.0%ni, 97.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  2.0%us,  1.3%sy,  0.0%ni, 96.4%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st

Cpu0  :  0.9%us,  1.9%sy,  0.3%ni, 96.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.3%us,  0.7%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  : 76.8%us, 22.8%sy,  0.0%ni,  0.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  2.0%us,  1.3%sy,  0.3%ni, 95.8%id,  0.7%wa,  0.0%hi,  0.0%si,  0.0%st

Cpu0  :  3.0%us,  4.0%sy,  0.0%ni, 93.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.6%us,  2.4%sy,  2.1%ni, 94.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  : 23.8%us, 66.0%sy,  0.0%ni, 10.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  3.0%us,  6.3%sy,  0.0%ni, 90.4%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st

дефолт

Cpu0  : 11.6%us,  8.6%sy, 35.4%ni, 38.4%id,  0.0%wa,  0.0%hi,  6.0%si,  0.0%st
Cpu1  :  2.3%us,  1.8%sy,  7.4%ni, 87.4%id,  0.0%wa,  0.0%hi,  1.1%si,  0.0%st

Cpu0  :  6.3%us, 22.2%sy, 25.8%ni, 43.7%id,  0.0%wa,  0.0%hi,  2.0%si,  0.0%st
Cpu1  :  4.2%us, 14.8%sy, 16.0%ni, 63.7%id,  0.0%wa,  0.0%hi,  1.3%si,  0.0%st

Странно, почему оно вообще жрет процессорное время?

потому что отключена вертикальная синхронизация - вот оно и жрёт всё что может
или я не так понял вопрос?

У меня вот что пишет:

glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
74391 frames in 5.0 seconds = 14878.105 FPS

Интересно, а если и счетчик на GPU перенести?..

>Running synchronized to the vertical refresh. The framerate should be

approximately the same as the monitor refresh rate.

74391 frames in 5.0 seconds = 14878.105 FPS

поздравляю - у тебя не пашед синхронизация :3
счётчик...хз

Нет, с шаренным L3 кэшем

С чего это?

L1 работает с виртуальными адресами.

С чего это?

L1 работает с виртуальными адресами.

Intel придерживается другого мнения:

When a translation is used it is kept in the data translation lookaside buffers (DTLBs) for future reuse, as all load and store operations require such a translation to access the data caches.

>> L1 работает с виртуальными адресами.

Intel придерживается другого мнения:

Это мнение Intel по другому вопросу.

When a translation is used it is kept in the data translation lookaside buffers (DTLBs)

TLB - это просто другая вещь. http://en.wikipedia.org/wiki/CPU_cache - прочитай _всю_ главу про Address translation.

Intel придерживается другого мнения:

Они говорят о TLB - кэше для трансляции виртуальных адресов в физические. L1 работает на максимальной скорости, поэтому для каждой выборки некогда делать трансляцию из виртуального адреса в физический (программа же в своём адресном пространстве работает), поэтому L1 работает с виртуальными адресами.

> Это мнение Intel по другому вопросу.

When a translation is used it is kept in the data translation lookaside buffers (DTLBs)

Как раз таки по этому самому, ключевая часть фразы: all load and store operations require such a translation to access the data caches.

Там дальше объясняется, что к L1 кэшу пришлёпнули свой маленький TLB кэш, благодаря которому происходит трансляция линейного адреса в физический, а уже потом поиск кэшлайна в L1 кэше:

As mentioned before, there is a multi level TLB system in each core for the 4KB pages. The level 1 caches have TLBs of 64 and 128 entries respectively for the data and instruction caches.

> L1 работает на максимальной скорости, поэтому для каждой выборки некогда делать трансляцию из виртуального адреса в физический (программа же в своём адресном пространстве работает), поэтому L1 работает с виртуальными адресами.

TLB для L1I имеет размер всего 128 записей (в Nehalem). Поэтому поиск по нему очень быстрый. Да и вообще, если бы L1 работал с виртуальными адресами, как тогда поддерживать когерентность кэшей в многопроцессорной системе? Тоже через TLB всех процессоров?

> Там дальше объясняется, что к L1 кэшу пришлёпнули свой маленький TLB кэш

Это другой блок.

благодаря которому происходит трансляция линейного адреса в физический, а уже потом поиск кэшлайна в L1 кэше

Мде. То есть ты хочешь сказать, что содержимое виртуально-индексированного кэша сохраняется при переключении в другое адресное пространство? Ок, как скажешь.