Да, я понимаю что передаются маски, вопрос в выставленных битах.
первые два бита - это два логические ядра одного физического, следующие два - это следующий проц и так далее.
Похоже сейчас на Windows это так (и здесь явно отражена такая нумерация), но на Линуксе и в старых версиях Windows по другому. Скажем, в этом документе от Microsoft пишут
Intel's recommendation is to list the first logical processor on each of the physical HT processors before listing any of the second logical processors.
и про свою нумерацию ничего не вижу. Когда оно поменялось - сходу не подскажу, но в любом случае в серьёзном коде в случаях, когда отображение номеров процессоров на физические ядра существенно, надо явно получать топологию от ОС (как писал выше, в Линуксе топология выставлена через sysfs, в Windows можно получить через GetLogicalProcessorInformation) и не закладывать какую то конкретную нумерацию. И в Линукс, и в Windows порядок может быть другим на процессорах от других производитетелей и/или c другими архитектурами.
Кстати, значения affinity меня смущают. Система же при нумеровании логических CPU на интеловских процессорах сначала проходит по всем физическим ядрам, выбирая по одному логическому процессору, а потом делает второй проход - т.е. на i7-10850H с 6 физическими ядрами процессора 0..5 находятся на разных ядрах, 6 живёт на одном ядре с 0, 7 с 1 и т.д. Бенчмарк это учитывает?
PS Хотя то, что написал выше, справедливо на Линуксе (там это легко посмотреть через /sys/devices/system/cpu/cpu<номер>/topology/thread_siblings_list), а вот на Windows 11 на ноуте простенький тест с GetLogicalProcessorInformation говорит, что логические процессоры на одном ядре идут подряд - хотя во времена Pentium 4 точно было не так.
только в случае гипертредированных ядер у нас кеш общий на два ядра, а вот для физических он раздельный и при чтении мы само собой должны получать "правильное" значение, и как-то железо должно это согласовывать
Выглядит так. Я бы в том же VTune сравнил для разных вариантов каунтеры по зачитыванию модифицированных данных из L3 (скажем, MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_HITM ).
Вообще то ELF файлы в память отображаются именно mmap'ом ;)
иначе любое обновление используемых библиотек или запущенных демонов заканчивалось бы ошибкой
Если бы при обновлении пакетный менеджер пытался просто открывать и писать в файл с бинарником, так бы и происходило. Но он всё таки действует умнее и сначала удаляет существующий файл. Надеюсь, не надо объяснять, как в UNIX обрабатывается удаление открытого файла.
Скорее просто нюансы планирования - после прерываний система ставит поток туда, куда удобнее. От перегрева это не особо спасает - никто не мешает задать affinity, тогда поток будет всегда на одном ядре; ну и всё таки ожидается, что процессор нормально работает когда все ядра загружены вычислениями. Перегрев фиксится троттлингом частоты.
Так в том то и дело, что полиморфизм нужен уже для того, чтобы работать через один и тот же API с файлами на разных FS. Сокеты и т.п. оверхеда не добавляют - они просто не реализуют часть методов.
Я же предлагаю вынести абстракции в код прикладных программ, и то, реализовывать их только там, где это необходимо.
Может ещё и явно в пользовательском коде вызывать разные read/write для разных файловых систем? Для них же разные реализации в ядре, приходится косвенный вызов делать...
Тут как и с счётным кодом важно, является ли код latency bound (скажем, проход по связному списку, случайно разбросанному по адресам) или throughput bound (когда предсказуемо читаем память подряд, как в примере в статье). В первом случае ускорение будет.
Просто некий unsigned long, который в разных устройствах может означать разные вещи. Параметры операции - так и вовсе список из переменного числа произвольных аргументов.
Во первых, свои модели - скажем, БК 0010 или Микроша - были разработаны и производились в классических советских учреждениях, кооперативы эти не занимались. Во вторых, к производству элементной базы кооперативы никакого отношения не имели - соотвественно, полноценной рыночной цепочки, когда спрос на компьютеры формирует спрос на производство и развитие микропроцессоров, не было. Рынка компьютерных игр и вообще софта для домашних компьютеров тоже не было - всё просто копировали друг у друга - отсюда и явное превосходство Спектрума в плане софтварной экосистемы.
Да, я понимаю что передаются маски, вопрос в выставленных битах.
Похоже сейчас на Windows это так (и здесь явно отражена такая нумерация), но на Линуксе и в старых версиях Windows по другому. Скажем, в этом документе от Microsoft пишут
и про свою нумерацию ничего не вижу. Когда оно поменялось - сходу не подскажу, но в любом случае в серьёзном коде в случаях, когда отображение номеров процессоров на физические ядра существенно, надо явно получать топологию от ОС (как писал выше, в Линуксе топология выставлена через sysfs, в Windows можно получить через GetLogicalProcessorInformation) и не закладывать какую то конкретную нумерацию. И в Линукс, и в Windows порядок может быть другим на процессорах от других производитетелей и/или c другими архитектурами.
Кстати, значения affinity меня смущают. Система же при нумеровании логических CPU на интеловских процессорах сначала проходит по всем физическим ядрам, выбирая по одному логическому процессору, а потом делает второй проход - т.е. на i7-10850H с 6 физическими ядрами процессора 0..5 находятся на разных ядрах, 6 живёт на одном ядре с 0, 7 с 1 и т.д. Бенчмарк это учитывает?
PS Хотя то, что написал выше, справедливо на Линуксе (там это легко посмотреть через /sys/devices/system/cpu/cpu<номер>/topology/thread_siblings_list), а вот на Windows 11 на ноуте простенький тест с GetLogicalProcessorInformation говорит, что логические процессоры на одном ядре идут подряд - хотя во времена Pentium 4 точно было не так.
Ну так
https://www.intel.com/content/www/us/en/developer/articles/release-notes/vtune-profiler/current.html
По работе сталкиваюсь )
Выглядит так. Я бы в том же VTune сравнил для разных вариантов каунтеры по зачитыванию модифицированных данных из L3 (скажем, MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_HITM ).
Проблема в том, что код может поменяться при смене версии компилятора или переходе между gcc и clang.
Ok, покажите логику, которая просто время от времени намеренно перекидывает поток на другое ядро (когда исходное ядро доступно).
PS Исследования на эту тему были, но не видел, чтобы заливалось в основной бранч.
Можете показать реализацию этой логики в исходном коде ядра?
Вообще то ELF файлы в память отображаются именно mmap'ом ;)
Если бы при обновлении пакетный менеджер пытался просто открывать и писать в файл с бинарником, так бы и происходило. Но он всё таки действует умнее и сначала удаляет существующий файл. Надеюсь, не надо объяснять, как в UNIX обрабатывается удаление открытого файла.
Скорее просто нюансы планирования - после прерываний система ставит поток туда, куда удобнее. От перегрева это не особо спасает - никто не мешает задать affinity, тогда поток будет всегда на одном ядре; ну и всё таки ожидается, что процессор нормально работает когда все ядра загружены вычислениями. Перегрев фиксится троттлингом частоты.
Так в том то и дело, что полиморфизм нужен уже для того, чтобы работать через один и тот же API с файлами на разных FS. Сокеты и т.п. оверхеда не добавляют - они просто не реализуют часть методов.
Ну да, те же read/write верхнего уровня, одинаковые для файла на диске, сокета или /dev/random
Дело скорее не в нюансах, а в том что только FS знает, куда конкретно на диске записать очередную порцию данных в файле.
Может ещё и явно в пользовательском коде вызывать разные read/write для разных файловых систем? Для них же разные реализации в ядре, приходится косвенный вызов делать...
Ну и кстати MCA на этих примерчиках корректно отрабатывает (но моделировать HT не умеет).
Я на подручном Haswell вижу полтора (и это логично, когда независимые операции раскладываются на два порта).
Тут как и с счётным кодом важно, является ли код latency bound (скажем, проход по связному списку, случайно разбросанному по адресам) или throughput bound (когда предсказуемо читаем память подряд, как в примере в статье). В первом случае ускорение будет.
Просто некий unsigned long, который в разных устройствах может означать разные вещи. Параметры операции - так и вовсе список из переменного числа произвольных аргументов.
Включая авторов Unix, выкинувших его в Plan 9.
Не упомянули ioctl(), с которым юниксовый файл является по сути объектом с произвольным интерфейсом.
Во первых, свои модели - скажем, БК 0010 или Микроша - были разработаны и производились в классических советских учреждениях, кооперативы эти не занимались. Во вторых, к производству элементной базы кооперативы никакого отношения не имели - соотвественно, полноценной рыночной цепочки, когда спрос на компьютеры формирует спрос на производство и развитие микропроцессоров, не было. Рынка компьютерных игр и вообще софта для домашних компьютеров тоже не было - всё просто копировали друг у друга - отсюда и явное превосходство Спектрума в плане софтварной экосистемы.