#science
Нептун гораздо менее синий, чем многие считают.
ras.ac.uk/news-and-press/news/new-images-reveal-what-neptune-and-uranus-really-look
Нептун гораздо менее синий, чем многие считают.
ras.ac.uk/news-and-press/news/new-images-reveal-what-neptune-and-uranus-really-look
😢16🤔2🤷2💩1
Forwarded from Врен о Японии для туриста
А вот так волшебно цветёт персик в горной деревне на острове Сикоку в долине реки Ниёдо. Фотографы называют эту локацию «Шангри-ла», но непонятно, насколько это официально.
🥰12👍3💩2🤡1🖕1
Forwarded from Lil Functor
В блоге Фигмы (это гугл-документы от мира графического дизайна) вышла отличная статья (https://clck.ru/JsUmz) о том, как они делали многопользовательский редактор макетов.
Там почти нет программистских подробностей, интересно скорее то, как они максимально упрощали решение очень сложной на первой взгляд задачи. Заявленный принцип «no more complex than necessary to get the job done» применялся и к технической реализации, и к продуктовым требованиям.
Ещё в статье есть про то, почему они не стали применять Operational Transformation и честный CRDT, как они реализовали многопользовательский undo-redo и совместное редактирование древовидных документов. Всё написано простым языком и с наглядной анимацией.
А вот ещё одна статья (https://clck.ru/JsUnC) из их блога про то, как они решали проблему совместного редактирования упорядоченных последовательностей.
Там почти нет программистских подробностей, интересно скорее то, как они максимально упрощали решение очень сложной на первой взгляд задачи. Заявленный принцип «no more complex than necessary to get the job done» применялся и к технической реализации, и к продуктовым требованиям.
Ещё в статье есть про то, почему они не стали применять Operational Transformation и честный CRDT, как они реализовали многопользовательский undo-redo и совместное редактирование древовидных документов. Всё написано простым языком и с наглядной анимацией.
А вот ещё одна статья (https://clck.ru/JsUnC) из их блога про то, как они решали проблему совместного редактирования упорядоченных последовательностей.
👍5
#prog #cpp #article
An informal comparison of the three major implementations of std::string
(GCC, MSVC и clang)
Все три варианта поддерживают SSO, но по разному этого достигают.
(thanks @itpgchannel)
An informal comparison of the three major implementations of std::string
(GCC, MSVC и clang)
Все три варианта поддерживают SSO, но по разному этого достигают.
(thanks @itpgchannel)
Microsoft News
An informal comparison of the three major implementations of std::string
Pros and cons.
🔥5👍1
Forwarded from commit -m "better"
#llvmweekly
https://c3.handmade.network/blog/p/8852-how_bad_is_llvm_really
TL;DR - медленно, семантика промежуточного представления (над которым производятся оптимизации) заточены на С/С++, и сделать иначе - невозможно. Ну, например, деление на 0 в LLVM - UB, а какой-то "другой" язык хочет уметь это обрабатывать. В итоге, LLVM навязывает некоторую семантику любому языку, которые хочет его использовать. Например, бесконечный цикл в rust, который некорретно оптимизировался llvm - https://github.com/rust-lang/rust/issues/28728
Зато много готовых оптимизаций из коробки.
Так же автор (очень справедливо!) вопрошает, какого хрена в коде LLVM не используются арены и пулы, везде, налево, и направо, потому что основные причины тормозов LLVM - это деревянные структуры без data locality.
У автора замена аллокатора для LLVM на mimalloc дает хороший буст в скорости (+10%).
Я систематически бенчил clang с разными аллокаторами, и остановился на tcmalloc от Google, по скорости тот же mim, но в пике жрет прямо существенно меньше памяти.
Неутешительный вывод такой - начинать разработку компилятора стоит с LLVM, а вот дальше есть варианты.
https://c3.handmade.network/blog/p/8852-how_bad_is_llvm_really
TL;DR - медленно, семантика промежуточного представления (над которым производятся оптимизации) заточены на С/С++, и сделать иначе - невозможно. Ну, например, деление на 0 в LLVM - UB, а какой-то "другой" язык хочет уметь это обрабатывать. В итоге, LLVM навязывает некоторую семантику любому языку, которые хочет его использовать. Например, бесконечный цикл в rust, который некорретно оптимизировался llvm - https://github.com/rust-lang/rust/issues/28728
Зато много готовых оптимизаций из коробки.
Так же автор (очень справедливо!) вопрошает, какого хрена в коде LLVM не используются арены и пулы, везде, налево, и направо, потому что основные причины тормозов LLVM - это деревянные структуры без data locality.
У автора замена аллокатора для LLVM на mimalloc дает хороший буст в скорости (+10%).
Я систематически бенчил clang с разными аллокаторами, и остановился на tcmalloc от Google, по скорости тот же mim, но в пике жрет прямо существенно меньше памяти.
Неутешительный вывод такой - начинать разработку компилятора стоит с LLVM, а вот дальше есть варианты.
Handmade Network
How bad is LLVM really?
LLVM used to be hailed as a great thing, but with language projects such as Rust, Zig and others c…
👍5
#prog #моё #article #outoflinestorage
В этот раз я написал слишком крупный для телеги пост — тут он занял бы семь сообщений. Поэтому держите ссылку наcold storage репозиторий для подобных текстов Блог*а:
Почему свойства (property) в языках программирования — это плохая идея
В этот раз я написал слишком крупный для телеги пост — тут он занял бы семь сообщений. Поэтому держите ссылку на
Почему свойства (property) в языках программирования — это плохая идея
❤🔥6💯6🤡5🔥2🥴2💩1🤝1
#prog #cpp #article
Fun with flat_map’s non-explicit constructors
TL;DR: в коде ниже вызываются три разных конструктора
Fun with flat_map’s non-explicit constructors
TL;DR: в коде ниже вызываются три разных конструктора
flat_map
:void print_map(std::flat_map<int, int>);
print_map({ {1, 2, 3}, {10, 20, 30} });
print_map({ {1, 2}, {10, 20} });
print_map({ {1}, {10} });
print_map({ {}, {} })
😁8🤮5🤯2🤡1
Если вашу (или чью-то ещё) задницу сравнивают с персиком — помните, что у персика на кожице волоски
🤡10🌚6🖕5🤮1💩1