blackprapor (01.06.2017 13:19, просмотров: 210) ответил Ксения на Уже показали. Ядер оказалось 18!-
- Не Ксения, но рассчитываю на её гостеприимность :) Гипертрейдинг это не маркетологическая хрень, а вполне красивая идея задействования простаивающих ресурсов ядра, чем "шире" ядро, т.е. больше функциональных устройств, тем сложнее одному потоку ANV(402 знак., 01.06.2017 19:35)
- Вот, весь вопрос в том, что и сколько из аппаратных штук можно задействовать одновременно blackprapor(847 знак., 02.06.2017 05:07 - 05:09)
- Да там, ИМХО, основной приход на кэш-миссах происходит. Пока из тормозной оперативки даныые в кэш подтянутся - можно 100500 инструкций выполнить. - LightElf(01.06.2017 22:01)
- Не факт, а вот то что железо способно выполнять два потока одновременно на разных ФУ это факт :) ANV(385 знак., 01.06.2017 23:38)
- У каждого процессора (или, если угодно, процессорного ядра) существует набор внутренних регистров (контекст), которые при переключении задачи (треда) нужно сохранять. Этих регистров овер-дохрена.. Каждый раз при переключении задачи ОС должна USSR(700 знак., 01.06.2017 14:17,
)
- Квант времени 20-120 мс какой процент времени от кванта это сохранение восстановление занимает, оно реально ощутимо? - blackprapor(01.06.2017 15:10)
- Бредовое изложение принципов гипертрейдинга. Вообщето ядро не просто сохраняет регистры, а в прямом смысле исполняет два потока одновременно. - =AlexD=(01.06.2017 15:01)
- стек задачи до внешней памяти может и не дойти, а осядет в кэше первого уровня, который весьма шустрый. - Mahagam(01.06.2017 15:00)
- А можно это переключение запретить, зафиксировав задачу на одном из ядер? А то уж я и аффинити использовала (см. ссылку) и приоритет задачи повышала (хотя не до критической секции), но время выполнения осталось практически неизменным. - Ксения(01.06.2017 14:54, ссылка)
- Можно "рекомендовать" планировщику задач не перекидывать потоки по ядрам после очередного выделения потоку кванта, но это только рекомендация, а не жесткое указание. blackprapor(385 знак., 01.06.2017 18:06)
- Это просто означает, что вы упёрлись в верхнюю планку производительности процессора. - =AlexD=(01.06.2017 15:02)
- Лет 10 назад прогнал на квартусе проект с включенным HT и без оного. С HT быстрее в 1,37 раза скомпилировалось. - POV_(01.06.2017 13:59, )
- Про ARM не скажу, но на моем 2-ядерном Core-i3 одновременный запуск 3-го и 4-го приложения удлиняет время выполнения примерно в 1.5 раза. Тогда как если бы это были обычные потоки, то по идее должно быть замедление в 2 раза. Получается ситуация Ксения(104 знак., 01.06.2017 13:43)
- Вообщето ваши цифры прямо говорят, что два потока гипертрейдинга примерно на 25% быстрее одного настоящего. - =AlexD=(01.06.2017 15:05)
- Вот не знаю насчёт маркетинговой хрени, но у меня "make -j4" работает существенно быстрее, чем "make -j2". Ну и кагбэ два ведра. SciFi(74 знак., 01.06.2017 13:29)
- Мне ваще пришлось make -j30 сделать, иначе проц был недозагружен (проект и все прочее на SSD!). Почему так - не понял, проц 8ядер+HT. - Argon(01.06.2017 14:00 - 14:04)
- Как оно может существенно быстрее работать, если максимум который может быть это 30%, в лучшем случае? - blackprapor(01.06.2017 13:32)
- А откуда цифирь? - LightElf(01.06.2017 14:27)
- 15 секунд и 12 секунд. 20% - это существенно. Хотя на ваш вкус может быть и нет. - SciFi(01.06.2017 13:46)
- А теперь ради чистоты эксперимента при том же количестве потоков при включенном и выключенном гипертрейдинге? Просто количество потоков ничего не характеризует. - blackprapor(01.06.2017 14:35)
- Не хочу у него в кишках ковыряться. "Работает - не трогай!" - SciFi(01.06.2017 14:37)
- А теперь ради чистоты эксперимента при том же количестве потоков при включенном и выключенном гипертрейдинге? Просто количество потоков ничего не характеризует. - blackprapor(01.06.2017 14:35)
- Я человек ещё молодой, неопытный, но могу предположить, что снижаются издержки на ожидание загрузки/выгрузки данных. На издержках можно много времени просрать. - mr-x(01.06.2017 13:40)
- Не Ксения, но рассчитываю на её гостеприимность :) Гипертрейдинг это не маркетологическая хрень, а вполне красивая идея задействования простаивающих ресурсов ядра, чем "шире" ядро, т.е. больше функциональных устройств, тем сложнее одному потоку ANV(402 знак., 01.06.2017 19:35)