По другому наверное проще сказать в сторону cmake. Он пытается стать пакетным менеджером универсиальным в стиле С++. Поэтому он добавляет куча винтиков для этого, а каждый потом пилит свой пакетный менеджер ( Избыточно), вместо того чтобы быть просто пакетным менеджером. С точки зрения написания простого проекта и привинтить к нему пару тройку зависимостей - очень просто
Хоть кто-то адекватно описал почему не стоит использовать conan и vcpkg когда cmake умеет скачивать ( просто -чуть напильником дополить и адекватный пакетный менеджер)
Питон позволяет писать быстро но работает медленно, го пишем чуть медленно но работает быстрее . С++ все еще остается лучшим языком для высоконагруженых сервисов
Рефлексия это не только json, proto. Рефлексия открывает дорогу к полноценной замене moc. Замена moc вместе с введением контрактов в том с++26 уже открыввает модуляризацию и упрощению компиляции большего числа существующих проектов . Вы не думали об этом?
Вопрос зачем было прописывать отдельно JIT Cache если по умолчанию и так берется 1/4 от оперативы ( то есть те же 8 гб, что вы прописали)? Так же принудительная многоядерность заметного прироста производительности также не приносит. В итоге мы получаем отвратительно долгую инсталяцию ос на мощной машине ( в сравнении с родной архитектурой) + кратную разницу с розетой или нативом при компиляции программ. Ради эксперемента ( раз блог компании ГК Астра) взять билд астры под арм и увидеть как хорошо будет работать эта ос на арм
все же хотелось бы увидеть производительность в сравнении с наитивной, а также производительность в сравнении с докер контейнером астры, запущеном через розетта, в сценарии сборки с++ проектов
Спасибо за статью. Сам этим моментом как разработчик под астру увлекаюсь. Но тут вопрос что про производительности на m3 Max в режиме эмуляции? Я смог добиться нормальной производительности работы на m1 с астрой только через docker контейнер, с тех пор как они добавили поддержку rosetta для запуска контейнеров на базе amd64. Иначе производительность оставляет желать лучшего, Еще хотелось бы увидеть замеры производительности на примере сброрки C++ проекта на разных виртуальных машинах. В качестве тестовых примеров предлагаю собирать cmake, qtbase или llvm ( не полный, а только компилятор clang и libc++). Данные примеры адекватно покажут рабочую производительность данных виртуальных машин в режиме эмуляции
По другому наверное проще сказать в сторону cmake. Он пытается стать пакетным менеджером универсиальным в стиле С++. Поэтому он добавляет куча винтиков для этого, а каждый потом пилит свой пакетный менеджер ( Избыточно), вместо того чтобы быть просто пакетным менеджером. С точки зрения написания простого проекта и привинтить к нему пару тройку зависимостей - очень просто
Если судить по пакетным менджерам в других ЯП то выйгрывают другие по сравнению С++.
Хоть кто-то адекватно описал почему не стоит использовать conan и vcpkg когда cmake умеет скачивать ( просто -чуть напильником дополить и адекватный пакетный менеджер)
ММ доверять работу ИИ. Резко качество кода и решения начинает деградировать +)
Как понимаю, вы вдохновились опытом Qt но решили сделать его в разы удобнее? Делалось ли написание gui на C++ или оно только через ts?
Вообще если любите js то посмотрите в сторону ts
Питон позволяет писать быстро но работает медленно, го пишем чуть медленно но работает быстрее . С++ все еще остается лучшим языком для высоконагруженых сервисов
Вы слишком плохо думаете о современном C++. если скорость исчисляете годами, но ваше право.
с одной стороны clang все еще не добавили embed, с другой стороны gcc смотрится предпочтительнее из-за linux
Может проще было все переписать на с++? Есть удобные библиотеки для работы и быстрые. Тот же userver
Предлагаю рассмотреть C++. Если говорить с точки зрения бигтеха, то для высокой нагрузки языка лучше не придумали
Кто первый из компиляторов добавит рефлексию с аннотациями, тот и будет моим любимчиком
Рефлексия это не только json, proto. Рефлексия открывает дорогу к полноценной замене moc. Замена moc вместе с введением контрактов в том с++26 уже открыввает модуляризацию и упрощению компиляции большего числа существующих проектов . Вы не думали об этом?
Ни слова о С++ . Пожалуйста ставьте правильные теги, так как все ваши тесты написаны на С. А так спасибо за иследование
Ничего лучше rtfm в мире не придумали для решения проблем.
ДА НО, не поддерживается rosetta2.
Эммм в июле 2014 года же? https://cmake.org/pipermail/cmake-developers/2014-June/010639.html
Вопрос зачем было прописывать отдельно JIT Cache если по умолчанию и так берется 1/4 от оперативы ( то есть те же 8 гб, что вы прописали)? Так же принудительная многоядерность заметного прироста производительности также не приносит. В итоге мы получаем отвратительно долгую инсталяцию ос на мощной машине ( в сравнении с родной архитектурой) + кратную разницу с розетой или нативом при компиляции программ. Ради эксперемента ( раз блог компании ГК Астра) взять билд астры под арм и увидеть как хорошо будет работать эта ос на арм
все же хотелось бы увидеть производительность в сравнении с наитивной, а также производительность в сравнении с докер контейнером астры, запущеном через розетта, в сценарии сборки с++ проектов
Спасибо за статью. Сам этим моментом как разработчик под астру увлекаюсь. Но тут вопрос что про производительности на m3 Max в режиме эмуляции? Я смог добиться нормальной производительности работы на m1 с астрой только через docker контейнер, с тех пор как они добавили поддержку rosetta для запуска контейнеров на базе amd64. Иначе производительность оставляет желать лучшего, Еще хотелось бы увидеть замеры производительности на примере сброрки C++ проекта на разных виртуальных машинах. В качестве тестовых примеров предлагаю собирать cmake, qtbase или llvm ( не полный, а только компилятор clang и libc++). Данные примеры адекватно покажут рабочую производительность данных виртуальных машин в режиме эмуляции