Моя главная боль с C++
Это сборка. Насрать на систему типов, насрать на "компилятор все проверяет". Изначально я пошел учить Rust только из-за того, что я попробовал Go, у которого прекрасная система сборки, и понял, что дальше так жить нельзя и я не хочу больше страдать со сборкой. Не из-за safety, из-за
Для меня всю мою жизнь стандартом было потратить несколько часов чтобы научиться собирать один файлик в плюсах. При этом с каждым годом я все больше и больше начинал разбираться в сборке, я даже могу сказать, что сейчас я что-то понимаю в cmake (sic!), но при этом я все еще трачу несколько часов на то, чтобы собрать один файлик
И вы не поверите, это случилось опять
Имеем две папки, содержимое файлов абсолютно одинаковое, хедер пустой, .cpp содержит элементарный hello world (он даже не инлюдит хедер).
Последняя команда генерировалась cmake'ом (тут она упрощена), я ее не из головы взял
Ошибка компиляции намекает на какую-то проблему со стандартной библиотекой, которая никак не гуглится
...
Вот так я в очередной раз не могу собрать один (ладно два) файлик в плюсах второй час
У меня уже нет слов, я просто устал, я просто хочу
Это сборка. Насрать на систему типов, насрать на "компилятор все проверяет". Изначально я пошел учить Rust только из-за того, что я попробовал Go, у которого прекрасная система сборки, и понял, что дальше так жить нельзя и я не хочу больше страдать со сборкой. Не из-за safety, из-за
cargo run
. Для меня всю мою жизнь стандартом было потратить несколько часов чтобы научиться собирать один файлик в плюсах. При этом с каждым годом я все больше и больше начинал разбираться в сборке, я даже могу сказать, что сейчас я что-то понимаю в cmake (sic!), но при этом я все еще трачу несколько часов на то, чтобы собрать один файлик
И вы не поверите, это случилось опять
Имеем две папки, содержимое файлов абсолютно одинаковое, хедер пустой, .cpp содержит элементарный hello world (он даже не инлюдит хедер).
.
├── features
│ ├── features.cpp
│ └── features.h
└── test
├── test.cpp
└── test.h
clang++ test/test.cpp # ok
clang++ -I/home/leviska/projects/personal/test/test test/test.cpp # ok
clang++ features/features.cpp # ok
clang++ -I/home/leviska/projects/personal/test/features features/features.cpp # fail
Последняя команда генерировалась cmake'ом (тут она упрощена), я ее не из головы взял
Ошибка компиляции намекает на какую-то проблему со стандартной библиотекой, которая никак не гуглится
...
Вот так я в очередной раз не могу собрать один (ладно два) файлик в плюсах второй час
У меня уже нет слов, я просто устал, я просто хочу
cargo run
, но для плюсов. И не говорите мне, что cmake
это тоже самое, как видите - нет.👍6🤔4
Panic! At the 0xC0D3
Моя главная боль с C++ Это сборка. Насрать на систему типов, насрать на "компилятор все проверяет". Изначально я пошел учить Rust только из-за того, что я попробовал Go, у которого прекрасная система сборки, и понял, что дальше так жить нельзя и я не хочу…
Люди про плюсы часто говорят, что "ну это просто инструмент, иногда плюсы для каких-то задач лучше подходят"
И я даже согласен с этим, я знаю примеры, когда C/C++ реально может быть удобнее Rust (да те же легаси кодовые базы)
Но меня никогда не покидает ощущение, что плюсы это "молоток", но то у него рукоятка сломается, то оголовье слетит
У меня после таких моментов просто пропадает все желание программировать
И я даже согласен с этим, я знаю примеры, когда C/C++ реально может быть удобнее Rust (да те же легаси кодовые базы)
Но меня никогда не покидает ощущение, что плюсы это "молоток", но то у него рукоятка сломается, то оголовье слетит
У меня после таких моментов просто пропадает все желание программировать
👍5🔥1🤔1
Use this simple trick to speedup catboost preparing dataset up to 210 times (21000%)
Я недавно оптимизировал пайплайн обучения катбуста, и наткнулся на странную вещь: инициализация
Гуглеж почему он может занимать много времени или как это ускорить не выдал абсолютно ничего, что сделало эту проблему еще веселее
Т.к. идей у меня больше не было, пришлось идти писать тестовый скрипт и pprofать его, и... ну я нашел проблему, больше сказать нечего
Оказывается, катбуст умеет копировать указатель только в одном очень аккуратном супер идеальном случае: это numpy массив(пока pyarrow), массив именно np.float32, и он непрерывный. В целом разумно, тут проблем нет.
Вопрос в том, что будет, если вы не дай бог передадите np.float64? Катбусту же много лет, над ним трудится кучастудентов людей, и все простые оптимизации уже были наверняка сделаны, подумаете вы
...
(буквально это но на cython)
Да, катбуст пойдет проверять тип каждого элемента. Да, это займет вечность.
Короче дамы и господа, передавайте катбусту только numpy массивы и только float32, и будет вам счастье.
А я сделал им ишьюи буду ждать когда они скажут, что это я дурак а они молодцы UPD: они согласились что это надо пофиксить!!!
Я недавно оптимизировал пайплайн обучения катбуста, и наткнулся на странную вещь: инициализация
catboost.Pool
занимает ну адски много времени (больше, чем обучение), хотя я ему передаю подготовленные нампай массивы в идеальном виде, и казалось бы ему надо просто указатель скопировать. Гуглеж почему он может занимать много времени или как это ускорить не выдал абсолютно ничего, что сделало эту проблему еще веселее
Т.к. идей у меня больше не было, пришлось идти писать тестовый скрипт и pprofать его, и... ну я нашел проблему, больше сказать нечего
Оказывается, катбуст умеет копировать указатель только в одном очень аккуратном супер идеальном случае: это numpy массив
Вопрос в том, что будет, если вы не дай бог передадите np.float64? Катбусту же много лет, над ним трудится куча
...
for i in range(len(x)):
if type(x[i]) == float:
res[i] = x[i]
(буквально это но на cython)
Да, катбуст пойдет проверять тип каждого элемента. Да, это займет вечность.
Короче дамы и господа, передавайте катбусту только numpy массивы и только float32, и будет вам счастье.
А я сделал им ишью
GitHub
Optimize catboost pool initialization for np.float64 case · Issue #2847 · catboost/catboost
I have a simple test code: import numpy as np import catboost from datetime import datetime print(catboost.version.VERSION) start = datetime.now() shape = (1024 * 1024 // 8, 1024) # 1 gig of floats...
🔥6😁5🤡1
SpacetimeDB
Я как геймдевелопер в душé был приятно удивлен
Если кратко, то это relational бд, где вместо традиционного backend + SQL over network ты пишешь явно модули (запросы + логика) на каком-то ЯП, они компилятся в васм, и запускаются прям внутри бд,
Плюсы по перфу очевидны: latency уменьшается а throughput увеличивается колоссально, так как вместо
мы получаем
Убрали сеть, убрали ось, получаем перф (добавили васм, но вроде как он довольно хорош по перфу)
Они, видимо, еще интегрировали какие-то доп решения (балансеры и прочее), чтобы был единый продукт для геймдевелоперов, но это уже детали.
Забавно то, что блин идея то не нова. Я сам думал о такой архитектуре еще несколько лет назад и спрашивал себя, почему никто это не сделал. Но я бы поспорил, что на самом деле сделали в блокчейне. Да, хуе мое децентрализация, но идейно архитектура бд то очень похожа - вместо традиционного backend + sql, у тебя виртуальная машина (evm в случае блокчейна, wasm в этом случае), и ты пишешь кастомную логику, которая прозрачно делает запросы к бд (контракты в блокчейне, "модули" тут). Возможно какие-нибудь yt подобные штуки тоже стали уметь в это (в мое время стажером в я они не умели)
По сути главное отличие от "современных" решений тут в том, что сейчас "модно" слоем абстракции выбирать сеть - закон мура для сети внутри дц пока не остановился, сеть улучшается с каждым годом. Но геймдев это одна из редких сфер, где задачи зачастую cpu+memory bound: тот же банальный пример обновить позицию миллиону точек. И тут люди решили сделать по сути упрощенное "облако" но внутри одной машины/процесса, чтобы получить плюсы всего.
Я не утверждаю, что это какое-то groundbreaking решение, и что оно заменит все, но I'm a sucker по идейно новым подходам, особенно когда идейность это return to monke, упростить стек, и использовать hardware на 100%.
Я как геймдевелопер в душé был приятно удивлен
Если кратко, то это relational бд, где вместо традиционного backend + SQL over network ты пишешь явно модули (запросы + логика) на каком-то ЯП, они компилятся в васм, и запускаются прям внутри бд,
Плюсы по перфу очевидны: latency уменьшается а throughput увеличивается колоссально, так как вместо
client -> (backend -> SQL -> backend) times N -> client
мы получаем
client -> db -> (wasm -> in memory -> wasm) times N -> db -> client
Убрали сеть, убрали ось, получаем перф (добавили васм, но вроде как он довольно хорош по перфу)
Они, видимо, еще интегрировали какие-то доп решения (балансеры и прочее), чтобы был единый продукт для геймдевелоперов, но это уже детали.
Забавно то, что блин идея то не нова. Я сам думал о такой архитектуре еще несколько лет назад и спрашивал себя, почему никто это не сделал. Но я бы поспорил, что на самом деле сделали в блокчейне. Да, хуе мое децентрализация, но идейно архитектура бд то очень похожа - вместо традиционного backend + sql, у тебя виртуальная машина (evm в случае блокчейна, wasm в этом случае), и ты пишешь кастомную логику, которая прозрачно делает запросы к бд (контракты в блокчейне, "модули" тут). Возможно какие-нибудь yt подобные штуки тоже стали уметь в это (в мое время стажером в я они не умели)
По сути главное отличие от "современных" решений тут в том, что сейчас "модно" слоем абстракции выбирать сеть - закон мура для сети внутри дц пока не остановился, сеть улучшается с каждым годом. Но геймдев это одна из редких сфер, где задачи зачастую cpu+memory bound: тот же банальный пример обновить позицию миллиону точек. И тут люди решили сделать по сути упрощенное "облако" но внутри одной машины/процесса, чтобы получить плюсы всего.
Я не утверждаю, что это какое-то groundbreaking решение, и что оно заменит все, но I'm a sucker по идейно новым подходам, особенно когда идейность это return to monke, упростить стек, и использовать hardware на 100%.
YouTube
A breakthrough in game dev - SpacetimeDB 1.0
SpacetimeDB is an all-in-one backend server and database designed for building and running multiplayer games and apps with incredible speed.
https://spacetimedb.com
Give us a star! https://github.com/clockworklabs/SpacetimeDB
Join our Discord! https://…
https://spacetimedb.com
Give us a star! https://github.com/clockworklabs/SpacetimeDB
Join our Discord! https://…
👍6🔥2
(📽 Камера дрожит, кусты шевелятся, кто-то осторожно пробирается вперёд)
— Тсс... Смотрите, вон он. Прямо перед нами — редчайший экземпляр. Вайбкодер маниграбер, решивший... завайбкодить библиотеку для терминального UI на Rust.
— Он не использует реактивность. Вообще. Никаких состояний, никаких подписок, ничего живого. Просто... текст. Выплюнутый один раз и навсегда. Как надпись на камне.
*пример рисует кнопку "Click me" и завершает выполнение, не дождавшись действия от юзера*
— Это всё. Он считает, что UI — это просто вывод текста. Кажется, для него “интерфейс” заканчивается после println!.
*перелистывает LICENSE*
— А вот и лицензия. Своя, уникальная. Если ты начнёшь зарабатывать деньги с проектом, использующим эту библиотеку... ты должен платить ему. Серьёзно.
— Мы были здесь. Мы это видели. Никто не поверит.
this post was generated with chatgpt due to it being fucking hilarious
— Тсс... Смотрите, вон он. Прямо перед нами — редчайший экземпляр. Вайбкодер маниграбер, решивший... завайбкодить библиотеку для терминального UI на Rust.
— Он не использует реактивность. Вообще. Никаких состояний, никаких подписок, ничего живого. Просто... текст. Выплюнутый один раз и навсегда. Как надпись на камне.
*пример рисует кнопку "Click me" и завершает выполнение, не дождавшись действия от юзера*
— Это всё. Он считает, что UI — это просто вывод текста. Кажется, для него “интерфейс” заканчивается после println!.
*перелистывает LICENSE*
— А вот и лицензия. Своя, уникальная. Если ты начнёшь зарабатывать деньги с проектом, использующим эту библиотеку... ты должен платить ему. Серьёзно.
— Мы были здесь. Мы это видели. Никто не поверит.
this post was generated with chatgpt due to it being fucking hilarious
GitHub
GitHub - entrepeneur4lyf/reactive-tui: CSS-styled Terminal User Interface framework with native Node.js/Bun bindings via NAPI-RS
CSS-styled Terminal User Interface framework with native Node.js/Bun bindings via NAPI-RS - entrepeneur4lyf/reactive-tui
😁9🤡3
jj крута
Посидел я на
Сначала опишу мой основной юзкейс для VCS:
* Делать много изменений на основе базового коммита, свитчится между ними и сравнивать
* Делать "снепшоты" in-development версий - т.е. условная фича еще полностью не готова, но хочется какой-то стейт аля "оно хотя бы билдится" зафиксировать
* Делать "снепшоты" экспериментов - т.е. тут вообще любой стейт от "изменил константу в конфиге" до "переписал половину кода", на котором был запущен эксперимент, и хочется этот стейт сохранить на будущее
Т.е. у меня по большей части не обычный "гит воркфлоу", где делаешь фичу, мержишь, делаешь новую, а эдакий стейт "тещу 20 фичей какая заработает"
И jj для этого идеален
Почему:
* WORKING COPY IS A PART OF A COMMIT ХОСПАДЕ НИКАКИХ СТЕШЕЙ ВСЁ ВСЕГДА СОХРАНЕНО АААА
* Свитч между двумя версиями буквально
* Коммиты не привязаны к веткам, поэтому можно их откреплять и прикреплять к друг другу как тебе вздумается. Можно фикс из рандомного места засунуть в другое рандомное место
* Интеграция с гитом - это по сути deal breaker, т.к. переводить всех на jj нет ни желания, ни смысла
* Сделать снепшот это буквально
Я скажу сразу, изначально было тяжело и не так радостно:
* Спустя месяц все концепты действительно становятся логичными и простыми, но по началу твой git brain отказывается собирать их в общую картинку, и в моменте возникает ощущение что ты заменил гит на другой гит - делаешь рандомные команды и надеешься, что будет хорошо
* Интеграций почти ни с чем нет. Очень рад был, что working copy diff все еще работает в ide, т.е. ты хотя бы в своем редакторе можешь нормально дифф твоего текущего коммита посмотреть
* Интерфейс хоть и понятный, но все еще терминальный, и все еще новый. Надо было привыкать и чутка выучить новый для меня "язык" для запросов по ревизиям
* Туториалы есть, но местами разбирали вообще не мои юзкейсы. Некоторые вещи приходилось самому понимать методом научного тыка
*
Посидел я на
jj
где-то месяц, и... это офигенно. Сначала опишу мой основной юзкейс для VCS:
* Делать много изменений на основе базового коммита, свитчится между ними и сравнивать
* Делать "снепшоты" in-development версий - т.е. условная фича еще полностью не готова, но хочется какой-то стейт аля "оно хотя бы билдится" зафиксировать
* Делать "снепшоты" экспериментов - т.е. тут вообще любой стейт от "изменил константу в конфиге" до "переписал половину кода", на котором был запущен эксперимент, и хочется этот стейт сохранить на будущее
Т.е. у меня по большей части не обычный "гит воркфлоу", где делаешь фичу, мержишь, делаешь новую, а эдакий стейт "тещу 20 фичей какая заработает"
И jj для этого идеален
Почему:
* WORKING COPY IS A PART OF A COMMIT ХОСПАДЕ НИКАКИХ СТЕШЕЙ ВСЁ ВСЕГДА СОХРАНЕНО АААА
* Свитч между двумя версиями буквально
jj new -r "version"
* Коммиты не привязаны к веткам, поэтому можно их откреплять и прикреплять к друг другу как тебе вздумается. Можно фикс из рандомного места засунуть в другое рандомное место
* Интеграция с гитом - это по сути deal breaker, т.к. переводить всех на jj нет ни желания, ни смысла
* Сделать снепшот это буквально
jj duplicate
- ВСЕ (это отличается от коммита, т.к. working copy остается в том же стейте)Я скажу сразу, изначально было тяжело и не так радостно:
* Спустя месяц все концепты действительно становятся логичными и простыми, но по началу твой git brain отказывается собирать их в общую картинку, и в моменте возникает ощущение что ты заменил гит на другой гит - делаешь рандомные команды и надеешься, что будет хорошо
* Интеграций почти ни с чем нет. Очень рад был, что working copy diff все еще работает в ide, т.е. ты хотя бы в своем редакторе можешь нормально дифф твоего текущего коммита посмотреть
* Интерфейс хоть и понятный, но все еще терминальный, и все еще новый. Надо было привыкать и чутка выучить новый для меня "язык" для запросов по ревизиям
* Туториалы есть, но местами разбирали вообще не мои юзкейсы. Некоторые вещи приходилось самому понимать методом научного тыка
*
jj log
...🔥7🤔3👍2
jj log
Тут больше всего подходит фраза "с большой силой приходит большая ответственность". В гите есть большой плюс - в простом воркфлоу ты работаешь с понятными тебе вещами - названиями веток. Коммит хэш ты используешь довольно редко, обычно, когда что-то сломалось.
В jj, log - это твоя самая популярная команда (в том числе потому что нет интеграций с ide), и самый большой вопрос в интерфейсе у меня к ней. Все команды ты делаешь с ревизиями, где ревизия - это либо коммит хэш, либо что-то на их языке запросов (например
Т.е. если я хочу потестить другой эксперимент, мне нужно:
1. Открыть
2. Найти в нем интересующую ревизию
3. Запомнить(!!!) четыре случайных буквы
4. Выполнить
А если я хочу сделать мердж, то нужно запомнить 2 набора из четырех букв. И вот тут уже "ux сделанный для людей" превращается в "ux сделанный для людей с хорошей памятью на рандомные наборы букв"
Имхо это главная вещь, с которой я бы попробовал что-то сделать (но я тоже слабо понимаю как)
Прежде чем эксперты
1.
2. Справедливости ради, тут скорее
3. В
4. В
5. Есть
В итоге, я доволен. Потому что я не страдаю, а если и страдаю, то с понятными проблемами типа "блин я потерял старый коммит в большом логе", а не "епт какую тут команду вообще использовать". Но learning curve у
Тут больше всего подходит фраза "с большой силой приходит большая ответственность". В гите есть большой плюс - в простом воркфлоу ты работаешь с понятными тебе вещами - названиями веток. Коммит хэш ты используешь довольно редко, обычно, когда что-то сломалось.
В jj, log - это твоя самая популярная команда (в том числе потому что нет интеграций с ide), и самый большой вопрос в интерфейсе у меня к ней. Все команды ты делаешь с ревизиями, где ревизия - это либо коммит хэш, либо что-то на их языке запросов (например
@-
- предыдущий коммит). И блин, я привык использовать человеческий текст а не случайный набор из 4х букв для хождения по репозиторию.Т.е. если я хочу потестить другой эксперимент, мне нужно:
1. Открыть
jj log
2. Найти в нем интересующую ревизию
3. Запомнить(!!!) четыре случайных буквы
4. Выполнить
jj new abcd
А если я хочу сделать мердж, то нужно запомнить 2 набора из четырех букв. И вот тут уже "ux сделанный для людей" превращается в "ux сделанный для людей с хорошей памятью на рандомные наборы букв"
Имхо это главная вещь, с которой я бы попробовал что-то сделать (но я тоже слабо понимаю как)
Прежде чем эксперты
jj
(лол) начнут писать комментарии, стоит сказать:1.
jj
пытается тебе помочь с коммит хешами - он показывает минимальный префикс, который тебе нужен чтобы указать на эту ревизию (например, по началу надо будет запоминать 1-2 буквы, но с ростом коммитов буковок становится больше...)2. Справедливости ради, тут скорее
jj
открыл мне возможность свободно ходить по ревизиям, и в гите была бы +- такая же проблема - запоминать названия веток или тех же коммит хешей3. В
jj
можно указать коммит по дескрипшену: jj new "description(some text)"
. И это в целом помогает (меня только бесит слишком длинное название функции)4. В
jj
все еще можно так же юзать "ветки" (bookmarks). Но прикол в том, что в гите ты зафоршен юзать их, а в jj они опциональны, и поэтому естественно ты в какой-то момент забудешь тегнуть коммит букмарком, и из-за этого воркфлоу не супер стабильный5. Есть
jjui
- интерактивная тулза, в которой запоминать нужно сильно меньше. Но у нее опять свои кнопочки и опять чему-то учиться и я пока не успел.В итоге, я доволен. Потому что я не страдаю, а если и страдаю, то с понятными проблемами типа "блин я потерял старый коммит в большом логе", а не "епт какую тут команду вообще использовать". Но learning curve у
jj
я бы сказал довольно высокий. Порекомендовать я могу это только людям, которых бесит гит и они готовы потратить время на изучение новой тулзы. К сожалению, за 5 минут ты на нее не пересядешь.👍6🔥5