Когда от ключей шифрования отделяет лишь микрософтовский логин, то иллюзий вообще быть не должно. У битлокера есть ещё одна поганая особенность - он может попросить ключ разблокировки в самый неподходящий момент, например после обновления БИОС, которое нынче может накатиться прямо из Windows11. Просто перегружаетесть и на тебе - введите полсотни цифр. Делали б уж сразу сотню-другую, чего уж мелочиться. У меня на рабочем компе в домашнем офисе так и произошло, а залогиниться в корпоративный логин с домашнего компа - было никак, ибо несекьюрно, только из корп сети с компа коллеги, пришлось тащиться в офис. Лучше всего этот код сразу распечатать и приклеить скотчем снизу на дно ноута - всем головной боли будет будет меньше - и вам, и ФБР.
Скорее всего и был заводской дефект, либо его качественно уронили. Батарейка смартофона на самом деле довольно нежная штука, она внутри вот как-то так устроена, там такой рулон, как в электролитическом конденсаторе (это угол батареи):
Аноды подлиннее, и вот то, насколько они вылезают за катоды - это называется overhang, и он должен быть вполне определённый, не много и не мало, если они слишком далеко торчат, то могут замкнуться с вытекающими, а слишком короткие - это плохо для катодов. Ну и при падении возможна внутренняя деформация. На деформацию их проверяют, роняя тестовые образцы с полутораметровой высоты на бетонную плиту под рентгеном и смотрят, что внутри происходит. Ну а картинка выше - это томография. Системы проверки довольно дорогие и медленные, так что у меня есть сомнения, что идёт повальный стопроцентный контроль, скорее выборочный, как в автомоторах, когда контролируется полностью примерно каждый десятый блок, так что дефекты вполне могут встретиться в продакшене, хоть верояность и невелика. Сразу после выхода новой модели она в теории может быть выше, потому что процесс проверки может быть не отстроен, ну и бизнес требует выход годных как можно выше.
Бывает, складывается этакая "устоявшаяся" терминология — к примеру в области рентгеновских детекторов "Binning" - это метод процессинга изображения (аппаратно или программно - неважно), когда четыре смежных пиксела (2х2) складываются вместе (иногда с усреднением), это снижает разрешение, но улучшает сигнал/шум. Можно и 3х3, и всё это называется именно "Binning". Хотя в какой-то мере тут тоже "корзины", да.
непрерывно скроллили колесо выбора времени около трех минут. Пальцы устали
Эх, так хотелось робота-манипулятора со стилусом и камерой увидеть, который скроллит и скроллит без устали... А по ADB с автотестом — читерство это ;).
Что-то я самого патента US20260017503A1 найти никак не могу, мож слепой. А было бы интересно взглянуть. Вообще идея делить данные на части не нова, например при вычислении медианы массива чисел с плавающей точкой, скажем одиночной точности - 32 бит можно воспользоваться тем фактом, что IEEE 754 так устроена, что целочисленное представление монотонно растущей последоваельности также монотонно возрастает, так что можно сначала взять старшие 16 бит слова, построить гистограмму (там всего-то 65536 элементов будет), найти медиану, затем взять отвечающие младшие слова, и снова посчитать медиану по ним, вместе они дадут общую. Два прохода и почти линейная сложность. Пару лет назад я даже статью набросал (жаль, я этот ненормальный метод не запантетовал). Хотя здесь может быть совсем другое, поскольку речь идёт о повышении точности и алгоритмы свёрток с битовым расширением для уменьшения ошибок квантования существуют, поэтому вдвойне любопытно, что же конкретно там запатентовано и как патент прошёл проверку, так как не все математические алгоритмы и трюки так уж легко запатентовать.
В принципе даже раздельность L1 и L2 кэшей уже влияет. Вот тут в комментарии спин ожидание в двух конкурентных очередях мы как раз обсуждали ускорение спинлока на гипертредированных ядрах за счёт того, что у них кэш общий на пару. У меня нет процессора с раздельным L3, но есть гибридный i7-13850, и там этот эффект точно также наблюдается. Ну то есть если спин лок на двух раздельных E ядрах запускать, то разница более чем шестикратная (там, конечно, ещё сильно влияет низкая производительность Е ядер, но тем не менее):
Пока писал статью про евроассемблер, сообразил как это можно сделать. Можно ведь несколько секций PROGRAM в одном файле иметь. Общий код надо сложить в отдельный файл и включить его в оба "проекта", они и будут собираться вместе:
EUROASM AutoSegment=Yes, CPU=X64, SIMD=AVX2
HelloLinux PROGRAM Format=ELFX, Width=64, Entry=Start:
INCLUDE linabi.htm, cpuext64.htm
INCLUDE Code.asm ; < Your code
ENDPROGRAM HelloLinux
%DROPMACRO * ; Forget macros defined in "linabi.htm".
HelloWindows PROGRAM Format=PE, Width=64, Entry=Start:
INCLUDE winabi.htm, cpuext64.htm
INCLUDE Code.asm
ENDPROGRAM HelloWindows
Единственная "хитрость" - надо макросы "сбросить" между проектами.
У интеловских камушков есть соответствующие счётчики производительности, которые можно получить, там можно всё что угодно посмотреть - от промахов по кэшу любого уровня до промахов предсказателя переходов и даже отдельную инфу о количестве инструкций, что летят через порты можно вытащить, надо только уметь пользоваться. Иногда в "мистических случаях" помогает и экономит время, иначе приходится лишь гадать по изменению поведения на те или иные изменения кода.
Да, это так, просто в этом месте я писал про MASM/FASM/NASM, плюс ниже в примерах использовал WinAPI/SEH. А так верно, им действительно можно собрать бинарник для Linux, даже 16 бит для древнего DOS можно. Я, возможно, набросаю пример и обновлю статью, спасибо за замечание.
Ну да, это такая "изюминка". Хотя при сборке можно обйтись и без PHP, а что касается HTML — то парсер просто игнорирует все теги, код можно вставлять в <pre>...</pre>, так что вот такой "код" — вполне себе валидный и компилябельный исходник:
А у меня onedrive вот совершенно не прижился. Рассказываю почему. На работе раньше был корпоративный box.com. Он был полностью безлимитный, это было круто и удобно. Я лил туда решительно всё - бекапы, рабочие файлы, проекты, и т.д. За несколько лет накопилось примерно пятнадцать терабайт (у меня есть нехитрая система еженедельного архивирования, с поиском проблем не было). Тут админам в рамках оптимизации пришла в голову светлая мысль мигрировать это дело на onedrive. Ага, все 15 ТБ. Получаю я значит новый комп (их меняют раз в три года) и эта фигня начинает заливать 15 ТБ на комп, где терабайтный SSD. Место само собой заканчивается. Я пытаюсь остановить синхронизацию в настройках, но там ошибка на ошибке, он упорно пытается закончить и снять галочки не даёт. А мне надо работать, я останавливаю onedrive и грохаю всё, что он накачал. Ну вы поняли, что дальше произошло - после обновлений (либо я автозагрузку при старте Windows не отключил), эта хрень грохает всё, что я почикал ещё и в облаке и начинает качать новую порцию. Я снова останавливаю синхронизацию и пытаюсь через веб интерфейс восстановить удалённое, а там это можно сделать ПОФАЙЛОВО (реально по одному), а их там тысячи, и нет возможности выделить все (я верю, что сейчас такое возможно). Короче я просто выпилил onedrive из всех авто загрузок. Сейчас, кстати, стало чуть удобнее, но эти 15 (точнее 14 ТБ) так и лежат там. Данные я не потерял, у меня есть копии помимо облака, также есть hp сервер на 160 ТБ, но осадочек остался. Плюс админы ещё и лимит включили, так что я и записать туда ничего не могу. Я верю, что если пользоваться аккуратно, "с чистого листа", то оно всё работает, но мне такой "миграции" хватило. До кучи админы так настроили, что весь рабочий стол тоже в облаке, а мне иногда с большими данными надо работать, и забрасывание нескольких гигабайт, а то и десятков на рабочий стол приводит к реальному замедлению сети и постоянно настраивать, что синхрить а что нет - ну такое. Так что просто не пользуюсь, мне это неудобно. Вот бухгалтерия и склад используют onedrive именно так - там инфы немного, и смена рабочего компа автоматом подтягивает рабочий стол и документы из облака, все довольны. А так в частном порядке из облаков я пользуюсь гуглодрайвом, дропбоксом и яндекс диском (где мне подарили четверть терабайта за ошибку в клиенте) и в общем норм.
Мой эксперимент на Raptor Lake показывает, что те же пять (зависимых) команд, но только на Р ядрах. А вот на Е ядрах - одна команда сложения за такт, как и на Haswell. Это и uops.info вроде подтверждает.
Абсолютно верно, но, пожалуй, только в том случае, если это предсказанный и взятый переход (что на подавляющем большинстве итераций так и есть), в этом случае он исполнится на шестом порту (это я проверял), а ALU будет свободен для параллельной команды, поэтому всё вместе за один такт, да.
Полагаю (хотя и не проверял), что на последней итерации может быть и два такта, хотя там ещё такты от промаха предсказателя прилетят, так что один или два - уже неважно. Но это реально тонкости.
PDP11, где непосредственно в ISA есть пост/пре инкремент/декремент регистров.
Справедливости ради надо заметить, что там вроде только пост инкремент и пре декремент были, а вот пре инкремента и пост декремента я не помню. Впрочем это 30+ лет тому назад было, может я забыл. Пятая глава в инструкции MACRO-11.
Хотя, конечно, циклы с постинкрементом по обоим операндам типа
"проворачиваются" за один такт, так как инструкции обрабатываются параллельно на разных портах проца (jl фьюзится только если выполняется предсказанный переход, но тут так оно и есть), чего дековскому процессору и не снилось.
Обычно, кстати, декремент используется, это экономит сравнение, но на скорость не влияет, тут ровно столько же тактов (просто выше было 3 IPC, а ниже будет 2 IPC):
mov rсx, 1_000_000_000
.10:
dec rcx
jnz .10
Это выше для хасвелла справедливо, а на рапторе я завтра проверю.
Нет, только под Windows, сейчас тег и хаб добавлю, хотя в тексте там это есть.
Когда от ключей шифрования отделяет лишь микрософтовский логин, то иллюзий вообще быть не должно. У битлокера есть ещё одна поганая особенность - он может попросить ключ разблокировки в самый неподходящий момент, например после обновления БИОС, которое нынче может накатиться прямо из Windows11. Просто перегружаетесть и на тебе - введите полсотни цифр. Делали б уж сразу сотню-другую, чего уж мелочиться. У меня на рабочем компе в домашнем офисе так и произошло, а залогиниться в корпоративный логин с домашнего компа - было никак, ибо несекьюрно, только из корп сети с компа коллеги, пришлось тащиться в офис. Лучше всего этот код сразу распечатать и приклеить скотчем снизу на дно ноута - всем головной боли будет будет меньше - и вам, и ФБР.
Скорее всего и был заводской дефект, либо его качественно уронили. Батарейка смартофона на самом деле довольно нежная штука, она внутри вот как-то так устроена, там такой рулон, как в электролитическом конденсаторе (это угол батареи):
Аноды подлиннее, и вот то, насколько они вылезают за катоды - это называется overhang, и он должен быть вполне определённый, не много и не мало, если они слишком далеко торчат, то могут замкнуться с вытекающими, а слишком короткие - это плохо для катодов. Ну и при падении возможна внутренняя деформация. На деформацию их проверяют, роняя тестовые образцы с полутораметровой высоты на бетонную плиту под рентгеном и смотрят, что внутри происходит. Ну а картинка выше - это томография. Системы проверки довольно дорогие и медленные, так что у меня есть сомнения, что идёт повальный стопроцентный контроль, скорее выборочный, как в автомоторах, когда контролируется полностью примерно каждый десятый блок, так что дефекты вполне могут встретиться в продакшене, хоть верояность и невелика. Сразу после выхода новой модели она в теории может быть выше, потому что процесс проверки может быть не отстроен, ну и бизнес требует выход годных как можно выше.
Бывает, складывается этакая "устоявшаяся" терминология — к примеру в области рентгеновских детекторов "Binning" - это метод процессинга изображения (аппаратно или программно - неважно), когда четыре смежных пиксела (2х2) складываются вместе (иногда с усреднением), это снижает разрешение, но улучшает сигнал/шум. Можно и 3х3, и всё это называется именно "Binning". Хотя в какой-то мере тут тоже "корзины", да.
Добро пожаловать, Павел! Я имел ввиду, что можно выставить опции
Как в примере https://euroassembler.eu/prodos16/com.htm.
Эх, так хотелось робота-манипулятора со стилусом и камерой увидеть, который скроллит и скроллит без устали... А по ADB с автотестом — читерство это ;).
Что-то я самого патента US20260017503A1 найти никак не могу, мож слепой. А было бы интересно взглянуть. Вообще идея делить данные на части не нова, например при вычислении медианы массива чисел с плавающей точкой, скажем одиночной точности - 32 бит можно воспользоваться тем фактом, что IEEE 754 так устроена, что целочисленное представление монотонно растущей последоваельности также монотонно возрастает, так что можно сначала взять старшие 16 бит слова, построить гистограмму (там всего-то 65536 элементов будет), найти медиану, затем взять отвечающие младшие слова, и снова посчитать медиану по ним, вместе они дадут общую. Два прохода и почти линейная сложность. Пару лет назад я даже статью набросал (жаль, я этот ненормальный метод не запантетовал). Хотя здесь может быть совсем другое, поскольку речь идёт о повышении точности и алгоритмы свёрток с битовым расширением для уменьшения ошибок квантования существуют, поэтому вдвойне любопытно, что же конкретно там запатентовано и как патент прошёл проверку, так как не все математические алгоритмы и трюки так уж легко запатентовать.
Это тот Пратт, который из алгоритма Кнута-Морриса-Пратта? О какой конкретно книге идёт речь, если не секрет?
Ну, меня, как работающего на LabVIEW с возможностью вставлять анимированные гифки прямо в код (блок-диаграмму) программы в общем сложно удивить:
Ну как почти... смотрите, если предпоследний пример с SEH переложить на FASM, просто для сравнения, то оно будет как-то вот так, почти один-в-один:
И всё бы ничего, но видите в начале "include 'seh64.inc'"? — чтобы это заработало, там ещё простыню макросов придётся наваять:
содержимое seh64.inc
Так что местами евроассемблер весьма удобная штука.
В принципе даже раздельность L1 и L2 кэшей уже влияет. Вот тут в комментарии спин ожидание в двух конкурентных очередях мы как раз обсуждали ускорение спинлока на гипертредированных ядрах за счёт того, что у них кэш общий на пару. У меня нет процессора с раздельным L3, но есть гибридный i7-13850, и там этот эффект точно также наблюдается. Ну то есть если спин лок на двух раздельных E ядрах запускать, то разница более чем шестикратная (там, конечно, ещё сильно влияет низкая производительность Е ядер, но тем не менее):
Код там выше в комменте был.
Пока писал статью про евроассемблер, сообразил как это можно сделать. Можно ведь несколько секций PROGRAM в одном файле иметь. Общий код надо сложить в отдельный файл и включить его в оба "проекта", они и будут собираться вместе:
Единственная "хитрость" - надо макросы "сбросить" между проектами.
У интеловских камушков есть соответствующие счётчики производительности, которые можно получить, там можно всё что угодно посмотреть - от промахов по кэшу любого уровня до промахов предсказателя переходов и даже отдельную инфу о количестве инструкций, что летят через порты можно вытащить, надо только уметь пользоваться. Иногда в "мистических случаях" помогает и экономит время, иначе приходится лишь гадать по изменению поведения на те или иные изменения кода.
Да, это так, просто в этом месте я писал про MASM/FASM/NASM, плюс ниже в примерах использовал WinAPI/SEH. А так верно, им действительно можно собрать бинарник для Linux, даже 16 бит для древнего DOS можно. Я, возможно, набросаю пример и обновлю статью, спасибо за замечание.
Ну да, это такая "изюминка". Хотя при сборке можно обйтись и без PHP, а что касается HTML — то парсер просто игнорирует все теги, код можно вставлять в <pre>...</pre>, так что вот такой "код" — вполне себе валидный и компилябельный исходник:
И выглядит опять же симпатично, можно всё, что угодно, хоть поясняющие картинки с иллюстрациями прямо в код вставлять:
Да. Я б ещё и LTSC порекомендовал. С тех пор, как я перешёл на Windows LTSC с локальной учёткой мне работать стало очень и очень комфортно.
А у меня onedrive вот совершенно не прижился. Рассказываю почему. На работе раньше был корпоративный box.com. Он был полностью безлимитный, это было круто и удобно. Я лил туда решительно всё - бекапы, рабочие файлы, проекты, и т.д. За несколько лет накопилось примерно пятнадцать терабайт (у меня есть нехитрая система еженедельного архивирования, с поиском проблем не было). Тут админам в рамках оптимизации пришла в голову светлая мысль мигрировать это дело на onedrive. Ага, все 15 ТБ. Получаю я значит новый комп (их меняют раз в три года) и эта фигня начинает заливать 15 ТБ на комп, где терабайтный SSD. Место само собой заканчивается. Я пытаюсь остановить синхронизацию в настройках, но там ошибка на ошибке, он упорно пытается закончить и снять галочки не даёт. А мне надо работать, я останавливаю onedrive и грохаю всё, что он накачал. Ну вы поняли, что дальше произошло - после обновлений (либо я автозагрузку при старте Windows не отключил), эта хрень грохает всё, что я почикал ещё и в облаке и начинает качать новую порцию. Я снова останавливаю синхронизацию и пытаюсь через веб интерфейс восстановить удалённое, а там это можно сделать ПОФАЙЛОВО (реально по одному), а их там тысячи, и нет возможности выделить все (я верю, что сейчас такое возможно). Короче я просто выпилил onedrive из всех авто загрузок. Сейчас, кстати, стало чуть удобнее, но эти 15 (точнее 14 ТБ) так и лежат там. Данные я не потерял, у меня есть копии помимо облака, также есть hp сервер на 160 ТБ, но осадочек остался. Плюс админы ещё и лимит включили, так что я и записать туда ничего не могу. Я верю, что если пользоваться аккуратно, "с чистого листа", то оно всё работает, но мне такой "миграции" хватило. До кучи админы так настроили, что весь рабочий стол тоже в облаке, а мне иногда с большими данными надо работать, и забрасывание нескольких гигабайт, а то и десятков на рабочий стол приводит к реальному замедлению сети и постоянно настраивать, что синхрить а что нет - ну такое. Так что просто не пользуюсь, мне это неудобно. Вот бухгалтерия и склад используют onedrive именно так - там инфы немного, и смена рабочего компа автоматом подтягивает рабочий стол и документы из облака, все довольны. А так в частном порядке из облаков я пользуюсь гуглодрайвом, дропбоксом и яндекс диском (где мне подарили четверть терабайта за ошибку в клиенте) и в общем норм.
Мой эксперимент на Raptor Lake показывает, что те же пять (зависимых) команд, но только на Р ядрах. А вот на Е ядрах - одна команда сложения за такт, как и на Haswell. Это и uops.info вроде подтверждает.
Абсолютно верно, но, пожалуй, только в том случае, если это предсказанный и взятый переход (что на подавляющем большинстве итераций так и есть), в этом случае он исполнится на шестом порту (это я проверял), а ALU будет свободен для параллельной команды, поэтому всё вместе за один такт, да.
Полагаю (хотя и не проверял), что на последней итерации может быть и два такта, хотя там ещё такты от промаха предсказателя прилетят, так что один или два - уже неважно. Но это реально тонкости.
Справедливости ради надо заметить, что там вроде только пост инкремент и пре декремент были, а вот пре инкремента и пост декремента я не помню. Впрочем это 30+ лет тому назад было, может я забыл. Пятая глава в инструкции MACRO-11.
Хотя, конечно, циклы с постинкрементом по обоим операндам типа
просто гениальны - это то, чего в интеловском асме не хватает.
Зато у интела циклы типа
или
"проворачиваются" за один такт, так как инструкции обрабатываются параллельно на разных портах проца (jl фьюзится только если выполняется предсказанный переход, но тут так оно и есть), чего дековскому процессору и не снилось.
Обычно, кстати, декремент используется, это экономит сравнение, но на скорость не влияет, тут ровно столько же тактов (просто выше было 3 IPC, а ниже будет 2 IPC):
Это выше для хасвелла справедливо, а на рапторе я завтра проверю.