но всякие дополнительные 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МГц для гигабита. Но со стороны ПК с "непрерывностью" поприседать придётся, и скорее всего совсем непрерывный поток всё равно не получится. Но на строку хватит и можно к строчной синхронизациии привязаться.
там место под коды в уникоде закончилось что ли, чтобы все эти точечки, кружочки, чёрточки, домики и всевозможные их комбинации вместе с буковками закодировать отдельно? не настолько же их много.
А в UTF8 как? Там два байта для кодирования всего 2048 (-128) символов, вместо 16384 у leb128.
Кодировки с переменной длиной - дичь, сколько там всего долей процента текстовой информации вообще по сравнению с каким-нибудь видео, чтобы не сношать уже мозг и какой-нибудь фиксированный utf32 использовать. А лишние нулевые байты любая примитивная компрессия поверх и так уберёт.
в 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 байта???
там место под коды в уникоде закончилось что ли, чтобы все эти точечки, кружочки, чёрточки, домики и всевозможные их комбинации вместе с буковками закодировать отдельно? не настолько же их много.
А в UTF8 как? Там два байта для кодирования всего 2048 (-128) символов, вместо 16384 у leb128.
Кодировки с переменной длиной - дичь, сколько там всего долей процента текстовой информации вообще по сравнению с каким-нибудь видео, чтобы не сношать уже мозг и какой-нибудь фиксированный utf32 использовать. А лишние нулевые байты любая примитивная компрессия поверх и так уберёт.
leb128
alglib уж тогда