>Только нужно помнить что винда жрет память зачастую кэшируя
Не нужно.
А в чем проявляется кэширование? И что она угадывает?
Она может сжимать память. Chrome может себе побольше запросить.
Но как винда кэширует мне интересно стало
Может угадывает какой exe распарсить и положить в память для моментального последующего запуска? - Стоит вот она думает и один хрен что не запусти на core m3 7y30 с ssd все равно запуск по 2-3 секунды и всё тормозит.
(Обрезанная винда или очищенная pwrshll скриптами конечно лучше значительно работает)
Думаю они знали что это в теории может быть уязвимостью еще на этапе идеи, не то что проектирования. Ну надо же как-то медленный говнокод исполнять который еще и не гарантирует безопасность данных
Я бы наоборот вынес функции защиты данных в софт. Типа статический анализатор в OC, который определит что программа будет стучаться в "запрещенную" область памяти, который можно отключить по желанию, но галочка в самой глубине настроек. Программу чтобы было нельзя запустить до окончания анализа, если она совсем большая
Но процессор читает определенными порциями, а не вооброжаемыми человеком массивами произвольной длины. Плохой выбор - так все будет медленнее. Хотя не скажу насколько - может это можно сгладить, что и делают производители цп, что и приводит к теме этого диалога
Все процессоры сейчас заранее подгружают нужные данные и/или исполняют код наперед чтобы потом в зависимости от одного бита взять готовый результат(Ну примерно так). Скорость проверки 1 бита тут вообще не причём. Просто после проверки бита - либо доступ к данным/коду уже в кэше либо проверили и подгружаем из ram то что нужно, ждем 50-200 тактов. И такая условность нередко в главном цикле программы. Ну что выбираете?
Это я знаю. Но почему то мне подумалось что вместо исполнения инструкций вызовом подпрогаммы из ROM, добавили какое-то крайне простое in-order ядро и записали на его isa в ROM программу-декодер. Кажется за счет конвееризации всех стадий исполнения процессором кода этот вариант вообще не будет уступать/отличаться от hard-wired. И это более гибко
Возможно js78. Я сам на Arch/sway и сегодня узнал что в системе есть какой-то js78. Подумал что от firefox остался. Попытался удалить и всплыла цепочка зависимостей
js78>polkit>rtkit,sway>(rtkit):pipewire
Причем pipewire вроде самый легкий, быстрый и продвинутый(короче эффективный, но это не точно) медиафреймворк линукса сейчас, но нуждается в таком.
>Linux традиционно нормально работает только с Intel-овскими, если у вас что-то другое (Qualcomm или Broadcom, например), то лучше даже не пытаться, а пойти купить модуль от Intel, это дешевле выйдет.
Я ответил на это. Потому что на трех устройствах с модемом qualcomm у меня не было проблем. Да, на Арче на последних двух и mint был на самом первом. Но я так понял имелось ввиду что любой linux лучше даже не пытаться ставить если модем не от интел. Это конечно частный случай(три). Все работали без проблем, сразу.
Ага, а МОП кэши придуманы просто так, да? Они нужны чтобы увеличить ширину декодирования.
Имея 4-way декодер x86 процессоры могут доставать 6-8 МОПов, точно так же как и на ARM Cortex-A77+.
Вот блин, а я понять не мог.
Вроде x86 isa не такой уж и cisc(именно даже с т.з. внешней isa) чтобы zen 3, декодируя 4-5 инструкций, держался близко к m1.
Вроде читал статьи, а как-то пропустил этот момент.
P.S.
Комменты полезнее любой статьи)
Хотел бы я увидеть software emulation который будет работать за приемлемое время. С удовольствием включу в исходники Bochs:)
Понятно что эмуляция медленная.
Но в целом.
1. В некоторых вычислениях прослеживаются участие лишь какого-то спектра чисел.
2. Иногда мантисса такая не нужна. Иногда экспонента.
3. Всякие зависимости бывает прослеживаются бит-в-бит и прочее.
4. По устройству misc cpu например сильно проще и в теории может достигать скорости достаточной для эмуляции 16 fmac fp32 per cycle
5. Для компилятора пропадает стена между типами данных = более продвинутый компилятор может вообще зависимости отдельных бит отслеживать втечение всей программы. (Ну это пока немного фантастика)
6. Кастомные типы данных из-за 1,2 и 3.
7. fixed point, правда это частный случай из п.6
И так далее.
То есть именно все вместе это могло быть лучше современного hard fp)
Ну это просто такая вот моя теория.)
P.S.
Вообще последний раз intel удвоили теоретический максимум fp32 до 32(16 fmac) per cycle в Haswell. С тех пор только задержки уменьшаются, но верхний предел тот же. У zen и arm в основном также +-. В GPU то же не сильно прогресс. «Жирные» они(fp блоки).
FP операции.
Никогда не понимал смысл hardware fp.
Специфический тип данных по причине фиксированной мантиссы и экспоненты.
Можно же и софтварно реализовать, развернуть цикл.
Получится чуть больше общий поток инструкций, но можно сильно нарастить темп исполнения более простых операций.
+
Компилятор больше не будет ориентироваться на типы данных. Будет дополнительные зависимости находить, когда смешанный код.
Таким образом мне кажется компилятор можно будет сделать более продвинутым. А пока получается искусственный барьер между data types.
+
Кастомная мантисса и экспонента.
2. Как умножение за 2-3 такта происходит? Там же вроде зацикливается ALU, который для этого имеет дополнительный небольшой circuit, чем и отличается от обычных ALU.
Но это слишком быстро по моему даже для wallec tree или booth. Он как будто на повышенной частоте работает.
3. Кстати есть такое что отдельные части запускают на бОльшей частоте? Как в каком-то pentium вроде было, снаружи 3Ghz, внутри alu на 6Ghz.
А можно без бенчмарка чтобы на ssd с core 7th gen как то работало нормально?
Вот в действии чтобы? Как "Антибенчмаркщики" говорят в "реальных" задачах.
А то я не чувствую "умность" винды совсем.
Просто вы заявляете что она там что-то кэширует и что она такая умная, значит я должен это увидеть.
P.S. Уже не говоря о том что обычный юзер не полез бы что то там скриптами оптимизировать в реестре
>Только нужно помнить что винда жрет память зачастую кэшируя
Не нужно.
А в чем проявляется кэширование? И что она угадывает?
Она может сжимать память. Chrome может себе побольше запросить.
Но как винда кэширует мне интересно стало
Может угадывает какой exe распарсить и положить в память для моментального последующего запуска? - Стоит вот она думает и один хрен что не запусти на core m3 7y30 с ssd все равно запуск по 2-3 секунды и всё тормозит.
(Обрезанная винда или очищенная pwrshll скриптами конечно лучше значительно работает)
Думаю они знали что это в теории может быть уязвимостью еще на этапе идеи, не то что проектирования. Ну надо же как-то медленный говнокод исполнять который еще и не гарантирует безопасность данных
Я бы наоборот вынес функции защиты данных в софт. Типа статический анализатор в OC, который определит что программа будет стучаться в "запрещенную" область памяти, который можно отключить по желанию, но галочка в самой глубине настроек. Программу чтобы было нельзя запустить до окончания анализа, если она совсем большая
Ну и репозиторий проверенного софта(или стор). Хочется приключений - отключай анализатор
>потому что проверка должна быть еще до того, как он что-то прочитает.
То как должно быть и как работает в железе немного разное.
По моему spectre как раз использует то что процессоры могут читать данные до проверки условия
Но процессор читает определенными порциями, а не вооброжаемыми человеком массивами произвольной длины. Плохой выбор - так все будет медленнее. Хотя не скажу насколько - может это можно сгладить, что и делают производители цп, что и приводит к теме этого диалога
Все процессоры сейчас заранее подгружают нужные данные и/или исполняют код наперед чтобы потом в зависимости от одного бита взять готовый результат(Ну примерно так). Скорость проверки 1 бита тут вообще не причём. Просто после проверки бита - либо доступ к данным/коду уже в кэше либо проверили и подгружаем из ram то что нужно, ждем 50-200 тактов. И такая условность нередко в главном цикле программы. Ну что выбираете?
Это я знаю. Но почему то мне подумалось что вместо исполнения инструкций вызовом подпрогаммы из ROM, добавили какое-то крайне простое in-order ядро и записали на его isa в ROM программу-декодер. Кажется за счет конвееризации всех стадий исполнения процессором кода этот вариант вообще не будет уступать/отличаться от hard-wired. И это более гибко
Как же hard-wired если микрокодом уязвимости исправляют? Или его влияние было сведено к нулю? Или я не так понимаю "hard-wired'
Возможно js78. Я сам на Arch/sway и сегодня узнал что в системе есть какой-то js78. Подумал что от firefox остался. Попытался удалить и всплыла цепочка зависимостей
js78>polkit>rtkit,sway>(rtkit):pipewire
Причем pipewire вроде самый легкий, быстрый и продвинутый(короче эффективный, но это не точно) медиафреймворк линукса сейчас, но нуждается в таком.
Оказалось что:
https://www.reddit.com/r/archlinux/comments/mb4cv8/why_do_so_many_packages_depend_on_js78/
>Lots of packages require polkit which in turn requires js78. Rules for polkit are written in javascript
Так можно узнать за что минус?
>Linux традиционно нормально работает только с Intel-овскими, если у вас что-то другое (Qualcomm или Broadcom, например), то лучше даже не пытаться, а пойти купить модуль от Intel, это дешевле выйдет.
Я ответил на это. Потому что на трех устройствах с модемом qualcomm у меня не было проблем. Да, на Арче на последних двух и mint был на самом первом. Но я так понял имелось ввиду что любой linux лучше даже не пытаться ставить если модем не от интел. Это конечно частный случай(три). Все работали без проблем, сразу.
Если не верите можно спросить пруф, я просто не видел проблем с qualcomm на Линуксе на 3-ех устройствах. Ну да ну да, надо молча минус вставить.
P.S. Могу скинуть скрин
Arch, dell inspiron какой-то, skylake 6006u, qualcomm modem. Все работает
aras-p.info/blog/2021/01/18/Texture-Compression-on-Apple-M1
Почему то один qualcomm решил что достаточно int8 и сделал int8-only NPU
Хотя тренду они чуть-чуть последовали, Adreno умеет всё.
Интересно что с идеей бинаризации.
software.intel.com/content/www/ru/ru/develop/articles/optimizing-binarized-neural-networks-on-intel-xeon-scalable-processors.html
Вот блин, а я понять не мог.
Вроде x86 isa не такой уж и cisc(именно даже с т.з. внешней isa) чтобы zen 3, декодируя 4-5 инструкций, держался близко к m1.
Вроде читал статьи, а как-то пропустил этот момент.
P.S.
Комменты полезнее любой статьи)
Понятно что эмуляция медленная.
Но в целом.
1. В некоторых вычислениях прослеживаются участие лишь какого-то спектра чисел.
2. Иногда мантисса такая не нужна. Иногда экспонента.
3. Всякие зависимости бывает прослеживаются бит-в-бит и прочее.
4. По устройству misc cpu например сильно проще и в теории может достигать скорости достаточной для эмуляции 16 fmac fp32 per cycle
5. Для компилятора пропадает стена между типами данных = более продвинутый компилятор может вообще зависимости отдельных бит отслеживать втечение всей программы. (Ну это пока немного фантастика)
6. Кастомные типы данных из-за 1,2 и 3.
7. fixed point, правда это частный случай из п.6
И так далее.
То есть именно все вместе это могло быть лучше современного hard fp)
Ну это просто такая вот моя теория.)
P.S.
Вообще последний раз intel удвоили теоретический максимум fp32 до 32(16 fmac) per cycle в Haswell. С тех пор только задержки уменьшаются, но верхний предел тот же. У zen и arm в основном также +-. В GPU то же не сильно прогресс. «Жирные» они(fp блоки).
Никогда не понимал смысл hardware fp.
Специфический тип данных по причине фиксированной мантиссы и экспоненты.
Можно же и софтварно реализовать, развернуть цикл.
Получится чуть больше общий поток инструкций, но можно сильно нарастить темп исполнения более простых операций.
+
Компилятор больше не будет ориентироваться на типы данных. Будет дополнительные зависимости находить, когда смешанный код.
Таким образом мне кажется компилятор можно будет сделать более продвинутым. А пока получается искусственный барьер между data types.
+
Кастомная мантисса и экспонента.
2. Как умножение за 2-3 такта происходит? Там же вроде зацикливается ALU, который для этого имеет дополнительный небольшой circuit, чем и отличается от обычных ALU.
Но это слишком быстро по моему даже для wallec tree или booth. Он как будто на повышенной частоте работает.
3. Кстати есть такое что отдельные части запускают на бОльшей частоте? Как в каком-то pentium вроде было, снаружи 3Ghz, внутри alu на 6Ghz.
Как я понял через регистры уже задержка будет.
Сейчас страшно стало что-то глупое отморозить…
Получается для моментальной передачи между двумя любыми ALU эта сеть растет в квадрате от их количества?
Надеюсь я вас не утомил вопросами)
Просто у меня их еще есть.