Возможно 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.
Любой сколь-нибудь интенсивный код будет декодирован однажды и исполняться пока не будет остановлен. Вклад декодеров в потребленную энергию будет стремиться к нулю по мере длительности его работы. Без uops cache(в идеальном мире с идеальной ISA) просто из цепочки (компиляция-трансляция в uops — тсполнение) трансляция кода «внутрь» исчезнет. Это как «прогрев» кода jit'ом.
Количество регистров никак не позволяет делать алгоритмы в железе проще.
Я этого не говорил. Это бред.
Я как раз про распределение переменных по явно доступным регистрам. Меньше load store и потенциально меньше проблем в renaming. Что вы далее и написали.
Но действительно с тех пор больше не увеличивают. Значит смысла нет.
В упор не понимаю, как сложность схемы связана с частотой.
слабо связано с физическими ограничениями полупроводников
Так абсолютно согласен. Я даже к этому ниразу и не вел. У x86-декодеров в этом смысле задача сильно проще.
Решается за O(n) но расспараллелить сложно из-за переменной длины.
Т.е. по-вашему «сложные» схемы собираются не из тех же логических элементов, что и «простые»?
Нет.
Из тех же — NOT, AND gates, обычно.
Я не думаю что блок ренэйминга будет настолько огромным.
Тут действительно с частотой у apple проблем не должно быть.
Или вы представляете себе настолько гигантскую схему декодера, что в нём время распространения электрического поля в проводнике начинает быть сравнимым с временем переходного процесса при частоте 5ГГц, а при 3ГГц ещё ок?
full hardware multiplier из за O(n^2) быстро вырастет до момента когда упрется в ограничения.
И тогда
То, что сложные алгоритмы чисто математически не раскладываются на однотактовое выполнение на логических элементах, к делу не относится
К делу относится.
В умножителях Booth'а, «wallac tree» часть сложности срезается оптимизацией.
И вообще сложность алгоритма всегда к делу относится. В железе не чудеса происходят.:
Бут придумал алгоритм. Затем его реализовали в железе. Стала меньше сложность.
Напишем алгоритм умножения столбиком. shift-add.
uint64_t mul(uint64_t a, uint64_t b) {
uint64_t c = 0;
while (a != 0) {
c += b & (0 - (a & 1));
b = b << 1;
a = a >> 1;
}
return c;
}
В худшем случае 64 64-битных сдвига и 64 n-битных сложений, где n в спектре 1...64.
Для 32 бит получится 32 32 битных сдвигов и соответственно для сложений(вдвое короче, в два раза меньше)
В случае full-hardware multiplier где будут просчитаны зависимости каждого конечного бита эта O(n^2) сложность отобразится на его площади.
Но даже интуитивно наивно полагать что можно строить цифровую схему неограниченного размера срабатывающую за тоже время без резкого увеличения power consumption и каких-либо других физ.ограничений.
Возможно 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 эта сеть растет в квадрате от их количества?
Надеюсь я вас не утомил вопросами)
Просто у меня их еще есть.
Вроде одна из самых простых вещей в modern cpu.
Или это потому что они тактируются как одна схема?
Я вас понял.
Любой сколь-нибудь интенсивный код будет декодирован однажды и исполняться пока не будет остановлен. Вклад декодеров в потребленную энергию будет стремиться к нулю по мере длительности его работы. Без uops cache(в идеальном мире с идеальной ISA) просто из цепочки (компиляция-трансляция в uops — тсполнение) трансляция кода «внутрь» исчезнет. Это как «прогрев» кода jit'ом.
Я как раз про распределение переменных по явно доступным регистрам. Меньше load store и потенциально меньше проблем в renaming. Что вы далее и написали.
Но действительно с тех пор больше не увеличивают. Значит смысла нет.
Хм, быть того не может. Зачем же в процессе увеличили количество явно доступных регистров?
Если для удобства, то, на ассемблере даже в те времена мало кто писал.
И разве это не упрощает переименование регистров в случае когда программисту/компилятору доступно больше регистров?
Так абсолютно согласен. Я даже к этому ниразу и не вел. У x86-декодеров в этом смысле задача сильно проще.
Решается за O(n) но расспараллелить сложно из-за переменной длины.
Нет.
Из тех же — NOT, AND gates, обычно.
Я не думаю что блок ренэйминга будет настолько огромным.
Тут действительно с частотой у apple проблем не должно быть.
full hardware multiplier из за O(n^2) быстро вырастет до момента когда упрется в ограничения.
И тогда
К делу относится.
В умножителях Booth'а, «wallac tree» часть сложности срезается оптимизацией.
И вообще сложность алгоритма всегда к делу относится. В железе не чудеса происходят.:
Бут придумал алгоритм. Затем его реализовали в железе. Стала меньше сложность.
Напишем алгоритм умножения столбиком. shift-add.
В худшем случае 64 64-битных сдвига и 64 n-битных сложений, где n в спектре 1...64.
Для 32 бит получится 32 32 битных сдвигов и соответственно для сложений(вдвое короче, в два раза меньше)
В случае full-hardware multiplier где будут просчитаны зависимости каждого конечного бита эта O(n^2) сложность отобразится на его площади.
Что-то вроде как-то так.
На данный момент мне уровень знаний не позволяет точно вам ответить.
Но это является проблемой. Не просто так этим занимаются.
core.ac.uk/download/pdf/234643291.pdf
Но даже интуитивно наивно полагать что можно строить цифровую схему неограниченного размера срабатывающую за тоже время без резкого увеличения power consumption и каких-либо других физ.ограничений.