А вот с например BIOS and Kernel Developer's Guide (BKDG) для AMD Family >=17h, то есть начиная с zen1 (почти 10-ти летней давности) можно где-то ознакомится и он выложен в открытый доступ, не под NDA? С интелом тоже не лучше, это видимо от переизбытка открытой и досутпной документации на современные процессоры блогеру из исходной статьи пришлось по помойкам искать core2duo, чтобы на нём это запустить.
Только вот запустить ему это удалось совсем не на ryzen, а на вполне уже достигшем совершенноления core2duo. Потому что всё что младше - огороженное ME / PSP без документации, и cache-as-ram там уже не используется во время начальной инициализации (хотя теоретически возможно мог бы).
найденное им (чужое) решение тоже не самое быстрое как минимум из-за корня.
корень нынче тактов за 5-10 вроде вычисляется у х86, это пожалуй быстрее чем ещё несколько степней к полиному добавлять для получения такой же точности, а разбиения и ветвления будут имхо ещё хуже.
но всякие дополнительные eval Blob.stream().pipeThrough(new DecompressionStream("gzip")).getReader().read().then atob(...) эту разницу почти нивелируют
c wasm-opt но без gzip, c gzip может и не так плохо, но на паре кБ много насжимать не получится + base64, да и js тоже после минификации ещё и через gzip пропустить можно.
>Хорошо сжимаемые ресурсы (HTML, JS) разумно встраивать в WASM при использовании gzip + DecompressionStream.
lzma1 декодер - 1.5кБ минифицированного JS, а жмёт он получше gz. Для 4КБ не поможет конечно, но на размерах в пару десятков КБ может уже оказаться лучше gz, даже не смотря на то что надо ещё и декодер с собой таскать.
не, я и сам на этот вопрос написал бы скорее всего for(count=0;var;var>>=1) count +=var&1;
и за компилятором приглядывать надо,
но те кто считают что для современных компиляторов есть какая-то разница написать ему %2==1 вместо &1, убрать if или что деление на константу надо заменять сдвигами, добро пожаловать на godbolt.org, там ждёт масса удивительных открытий по этому поводу.
Сотни литров воздуха, предварительно охлажденного до минус 28 градусов, могут поглощать несколько сотен ватт тепла в течение нескольких минут, прежде чем значительно нагреются
300л воздуха т.е. 0.3кг имеют теплоёмкость 300Дж/С, то есть повышение на 1градус каждую 1 секунду при 300Вт "нагревателе" внутри, очень так себе аккумулятор холода.
2) взять езернетную физику (MII или GMII, RMII/RGMII не подойдёт, там на клоках сэкономили и внутри есть дополнительная буферизация для компенсации несовпадения клоков и непрерывно долго принимать/передавать возможно не получится) и в неё через AF_PACKET SOCK_RAW гнать данные с ПК и получить параллельный выход 4бита х 25МГц или 8х125МГц для гигабита. Но со стороны ПК с "непрерывностью" поприседать придётся, и скорее всего совсем непрерывный поток всё равно не получится. Но на строку хватит и можно к строчной синхронизациии привязаться.
а где эти слитые бутромы целиком поглядеть можно?
беглым гуглением нашлось только https://github.com/anonpsp/bootroms но вроде немного не то.
про то, какой именно это zen2 - e06f2a ии втирает какую-то дичь.
А вот с например BIOS and Kernel Developer's Guide (BKDG) для AMD Family >=17h, то есть начиная с zen1 (почти 10-ти летней давности) можно где-то ознакомится и он выложен в открытый доступ, не под NDA? С интелом тоже не лучше, это видимо от переизбытка открытой и досутпной документации на современные процессоры блогеру из исходной статьи пришлось по помойкам искать core2duo, чтобы на нём это запустить.
Только вот запустить ему это удалось совсем не на ryzen, а на вполне уже достигшем совершенноления core2duo. Потому что всё что младше - огороженное ME / PSP без документации, и cache-as-ram там уже не используется во время начальной инициализации (хотя теоретически возможно мог бы).
корень нынче тактов за 5-10 вроде вычисляется у х86, это пожалуй быстрее чем ещё несколько степней к полиному добавлять для получения такой же точности, а разбиения и ветвления будут имхо ещё хуже.
в xbox series s - те же 8ГБ (10) там же как-то работает
но всякие дополнительные eval Blob.stream().pipeThrough(new DecompressionStream("gzip")).getReader().read().then atob(...) эту разницу почти нивелируют
c wasm-opt но без gzip, c gzip может и не так плохо, но на паре кБ много насжимать не получится + base64, да и js тоже после минификации ещё и через gzip пропустить можно.
https://github.com/ilyakurdyukov/micro-lzmadec
https://github.com/pavel212/micro-lzmadec-js
microlzma собранный в wasm получается по размеру больше чем он же на JS :( + 25% от base64 + ещё несколько сотен байт JS обёртки для вызова.
хотя руками сильно оптимизированный под x64 асм этот декодер в 500байт влезает.
>Хорошо сжимаемые ресурсы (HTML, JS) разумно встраивать в WASM при использовании gzip + DecompressionStream.
lzma1 декодер - 1.5кБ минифицированного JS, а жмёт он получше gz. Для 4КБ не поможет конечно, но на размерах в пару десятков КБ может уже оказаться лучше gz, даже не смотря на то что надо ещё и декодер с собой таскать.
обычные стандартные ответные штыри для этих разъёмов (pls ?) скорее пластик разъёма разворотят чем сами сломаются.
компилятор не всемогущ, но при чём тут древние dsp и simd?
речь про тривиальные constant folding оптимизации, делать которые за компилятор совсем не обяхательно
и это тоже компилятор точно так же соптимизирует.
не, я и сам на этот вопрос написал бы скорее всего for(count=0;var;var>>=1) count +=var&1;
и за компилятором приглядывать надо,
но те кто считают что для современных компиляторов есть какая-то разница написать ему %2==1 вместо &1, убрать if или что деление на константу надо заменять сдвигами, добро пожаловать на godbolt.org, там ждёт масса удивительных открытий по этому поводу.
if (var & 1 != 0)
count++;
var >>= 1;
сейчас c -O1 и выше разницы в выхлопе компилятора не будет никакой.
это уж совсем какой-нибудь sdcc для 8051 (о чё вспомнил) должен быть чтобы такое нынче не соптимизировать.
ну ЯМР магнитометр доводилось как-то использовать с вот таким принципом работы
только вот релаксация там довольно быстрая, за пару секунд всё забудет полностью, но как кратковременная память :) - вполне.
300л воздуха т.е. 0.3кг имеют теплоёмкость 300Дж/С, то есть повышение на 1градус каждую 1 секунду при 300Вт "нагревателе" внутри, очень так себе аккумулятор холода.
https://stackoverflow.com/a/8556436
у компилятора для этого есть препроцессор:
у линкера этого есть: SECTIONS { .text : { *(.text) } =0xABCD }
а для таких вопросов есть qna.habr.com
хорошо! до 84МГц должно работать.
ешё пара вариантов из серии "дичь", помимо банального ft232h
1) из 5$ fl2k USB->VGA сделать обратно цифровой 2х битный интерфейс до 150МГц / 2 (/2 для клоков на одном из цветов). там возможно даже его родные сихнроимпульсы задействовать получится. https://osmocom.org/projects/osmo-fl2k/wiki#USB-Host-Controller-comparison
2) взять езернетную физику (MII или GMII, RMII/RGMII не подойдёт, там на клоках сэкономили и внутри есть дополнительная буферизация для компенсации несовпадения клоков и непрерывно долго принимать/передавать возможно не получится) и в неё через AF_PACKET SOCK_RAW гнать данные с ПК и получить параллельный выход 4бита х 25МГц или 8х125МГц для гигабита. Но со стороны ПК с "непрерывностью" поприседать придётся, и скорее всего совсем непрерывный поток всё равно не получится. Но на строку хватит и можно к строчной синхронизациии привязаться.
Да это понятно,
не понятно кто мешал буквам вроде Ё и Й выделить отдельные коды, много там наэкономили, частично переиспользуя для этого E и И?
как тогда тот же код пробела 32, закодированный в leb128, станет вдруг 3 байта???