Продолжая рассуждения на тему обмена данных между Процессором и Памятью:
Есть Out Of Order Execution процессор, есть кусочек кода который подгружает данные из Памяти в Кеш Процессора и как-либо обрабатывает их после, и есть код который отрабатывает ДО места где эти данные загружаются / используются.
Из поста выше мы знаем, что обмен данными между Памятью и Процессором - долог: если на момент пользования обмениваемыми данными, в Кеше Процессора их нету - работа встанет. Процессор, конечно, не дурак и просматривая Фреймы наперед, начнет загрузку данных в Кеш еще до того как они реально понадобятся, параллельно выполняя команды идущие ДО. То есть я к чему: нужно писать код так, чтобы до Работы с Памятью можно было сделать какую-либо полезную Память-Независимую работу, на фоне выполнения которой и будет происходить опережающая выгрузка данных из Памяти.

#memory #cache #prefetching

Привет! Джем и Горячий чай уже ждут тебя:

https://habr.com/ru/post/470674/

Контент авторский, тут все по плану. Ну а утро бывает не только добрым, но и теплым, да.

#link #publication #cxx #allocator #data_structure #interesting

https://www.youtube.com/watch?v=51lqHKVDoBE модули пельтье в охлаждении #pc фактически это реактивный буст охлаждения. как будто проц работает в комнате с -40 по цельсию

Make LLVM fast again
https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html.html ускорение #llvm, просто отлично, что оно двигается в направлении ускорения компиляции

https://joellaity.com/2020/01/25/linking.html статья про то как работает линковка в #cpp. впрочем в #rust и #swift тожесамое

https://joellaity.com/2019/02/28/checkmate-undefined-behavior.html немного про Undefined Behavior в #cpp

https://docs.google.com/presentation/d/1VnisvNEUj0Q7JzHbvGqTOVM9zcLuHhBOwg4aaTx6cMQ/edit#slide=id.p причина почему #cpp это боль. название говорит за себя. нужен целый гайд что бы понять как оно работает. вообще не смешно

https://blog.reverberate.org/2020/05/12/optimizing-date-algorithms.html про оптимизации превращения даты в юникс эпоху, магические числа, #fortran #c с бенчмарками

https://blog.reverberate.org/2009/01/llvm-bitcode-vs-protocol-buffers.html прям по свежему. недавно копал разного вида бенчмарки мгновенной десериализации данных, и тут старая статья про биткод #llvm и #protobuf... если коротко то бикод выиграл по месту... по остальным показателям протобаф ообошел. НО в моих бенчах на #rust имплементация протобафов получилась чуть ли не самая тормозная и в результате выбрал малоизвестную либу speedy которая работает так же как bincode но оптимизирована по скорости загрузки в память сразу в нужном виде (что критично важно)

https://habr.com/ru/post/460295/ ансэйф в #rust. Если коротко то компилятор гарантирует отсутствие сигфолдов, но иногда надо манипулировать указателями и там нужен ансэйф

О ролях и шилдочках в разработке

https://doc.rust-lang.org/std/mem/fn.replace.html
наконец добрались руки везде где надо mem::replace прописать. 0.4секунды из 4.6сек сэкономлено. #rust

https://github.com/rust-lang/llvm/blob/master/docs/Vectorizers.rst #векторизация в #llvm. старенькая статейка

https://www.youtube.com/watch?v=onbnb_D1wC8 просто ахтунг что могет NVidia теперь. мощность датацентра уже в одной стойке за 1млн баксов. парам пам пам. расходимся

кроссплатформенная компиляция в #rust огнище 🔥🔥🔥🔥🔥 вот только чтото с openssl не получилось скомпилировать. но думаю что получится скоро.
https://cloudwafer.com/blog/installing-openssl-on-ubuntu-16-04-18-04/ неплохой ман по тому как скомпилировать openssl под убунту

https://medium.com/@qertoip/how-to-generate-an-array-of-random-bytes-in-rust-ccf742a1afd5 обана. незадокументированная мелочь генерации массива рандомных значений в #rust при помощи rand

вопросы Саше
- мув памяти, как это работает ?

Можно сжать ссылки в #jvm за счет разделения хипа на несколько. https://habr.com/ru/post/440166/

https://www.youtube.com/watch?v=iTJpGa3W0xc оч хорошо рассказал.

* меньше хип - меньше паузы GC. GC останавливает все потоки. поэтмоу лучше разделить #Jvm на несколько.
* мидеанная задержка меньше 1мксек. изза этого не дюрабл, и зза этого только асинхронная репликация.
* вариант 1 = общение через syscall, лупбэк и сокеты (это поход в ОС и это около 100нс*4) = дорого. лишние копирования (2+) и непредсказуемые задержки.
* вариант 2 = общение через разделяемую память. всеже есть перекопирования. минусов меньше, но есть.
* контекст свич это дорого.
* репликации без логов. просто флаг на данных, и отдельно воркер ходит и перекладывает с одной базы на другую
* асинхронная репликация нарушает консистентность мультикей обновлений.