Evgeny_CD, Архитектор (14.06.2018 22:06, просмотров: 240) ответил sav6622 на Што... опять ?!? ... "В процессорах Intel «математический баг». Под ударом ОС Windows, Mac OS, Linux"-
- У меня есть свое ощущение про то, как это работает, по личному опыту. Но оно у меня бездоказательно, т.к. не пыталась доказательства собирать. Если интересно, то ниже излагаю: Ксения(5668 знак., 15.06.2018 11:20 - 11:33)
- бред. скорости кэшей - сотни гигабайт в секунду. 2 килобайта даже тыщу раз в секунду туда-сюда - это 4 мегабайта/сек. даже если контекст сваливается в L2 кэш, то 400GB/s делим на 4MB/s = 0.001%. а ведь далеко не каждый поток переключается Mahagam(11 знак., 15.06.2018 14:58)
- Какой бы ни была фантастичной скорость кэшей, но быстрее чем один регистр за такт в эту память не скопировать. Т.е. тормозит не скорость доступа в память, а скорость передачи в нее содержимого регистра, т.к. такая передача строго тактирована. - Ксения(15.06.2018 16:08 - 19:52)
- ну отлично, регистр 256 бит = 32 байта. процессор у нас суперскалярный - хреначит по нескольку команд за такт. итого 64 байта за такт можно выпихивать из ядра. на частоте 4.0GHz это какой поток будет? Mahagam(292 знак., 15.06.2018 20:07, ссылка)
- Есть тонкость, связанная с когерентностью кеша. И с остановкой работы конвейера памяти. Evgeny_CD(289 знак., 15.06.2018 20:31)
- 1. DSP-процессоры (а современный х86_64 таки DSP) давно научились совмещать операции загрузки с другими. Даже занюханный C2000 умеет в какой-нибудь MACF32 || MMOV32, не говоря про какой-нибудь C66x. lloyd(118 знак., 15.06.2018 16:27)
- это таки байты, а не биты. и цифры получены измерением. а значит - это вот прям из реальности, а не теории. как они получены? а? Mahagam(538 знак., 15.06.2018 16:17 - 16:20)
- ну отлично, регистр 256 бит = 32 байта. процессор у нас суперскалярный - хреначит по нескольку команд за такт. итого 64 байта за такт можно выпихивать из ядра. на частоте 4.0GHz это какой поток будет? Mahagam(292 знак., 15.06.2018 20:07, ссылка)
- Гы-гы... Латентность кэшы играет. Гигабайтом слил контент, потом данные будут ждать пока Л1 перельёт в Л2 итыды... На круг получаются под сотню тактов задержки. Ясенхрен, что от задачи зависит, но, как дочь диспетчера кэша, говорю, не всё у нас mse homjak(60 знак., 15.06.2018 15:08)
- там на картинке латентности указаны. да, ждать долго, аж целых 10 наносекунд. а потом всего одну миллисекунду работать. - Mahagam(15.06.2018 15:11)
- 1мС, это если переписываемые данные в кэше неактуальные. А если кэшь с механизмами "исключительности", то всё ещо непроще. - mse homjak(15.06.2018 19:04)
- там на картинке латентности указаны. да, ждать долго, аж целых 10 наносекунд. а потом всего одну миллисекунду работать. - Mahagam(15.06.2018 15:11)
- Какой бы ни была фантастичной скорость кэшей, но быстрее чем один регистр за такт в эту память не скопировать. Т.е. тормозит не скорость доступа в память, а скорость передачи в нее содержимого регистра, т.к. такая передача строго тактирована. - Ксения(15.06.2018 16:08 - 19:52)
- Снимаю шляпу! - PlainUser(15.06.2018 14:18)
- Спасибо! Основательно. Мне показалось, что там еще есть подветка бага с восстановлением чужого контекста. Evgeny_CD(157 знак., 15.06.2018 11:56)
- Однако, Вы губоко вникли в проблему. Респект. - Крок(15.06.2018 11:35)
- бред. скорости кэшей - сотни гигабайт в секунду. 2 килобайта даже тыщу раз в секунду туда-сюда - это 4 мегабайта/сек. даже если контекст сваливается в L2 кэш, то 400GB/s делим на 4MB/s = 0.001%. а ведь далеко не каждый поток переключается Mahagam(11 знак., 15.06.2018 14:58)
- У меня есть свое ощущение про то, как это работает, по личному опыту. Но оно у меня бездоказательно, т.к. не пыталась доказательства собирать. Если интересно, то ниже излагаю: Ксения(5668 знак., 15.06.2018 11:20 - 11:33)