| 1.1, Аноним (1), 11:13, 08/02/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> компилятор для сборки кода на языке Си
> код проекта написан на языке С++
Хехе, это настолько типично))
| | |
| |
| |
| |
| 4.7, Аноним (7), 12:09, 08/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
gnome/gtk, wayland, xorg, mesa, systemd и др., использующие meson (на питоне), глядя на твой комментарий, тихонько недоумевают
| | |
| |
| 5.14, Аноним (14), 14:16, 08/02/2025 [^] [^^] [^^^] [ответить]
| +6 +/– |
Meson - не система сборки, там на самом деле собирает ninja. И он на C++.
| | |
| 5.34, Аноним (-), 08:55, 09/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
> gnome/gtk, wayland, xorg, mesa, systemd и др., использующие meson (на питоне), глядя
> на твой комментарий, тихонько недоумевают
К счастью есть такая штука как muon - реализация языка meson на си, так что можно и без питона к счастью :)
| | |
|
| 4.23, Семен (??), 17:22, 08/02/2025 [^] [^^] [^^^] [ответить]
| –2 +/– |
Уже как много лет в большом количестве проектов отказываются от cmake в сторону meson + ninja, так как даже на простых проектах cmake сценарии очень сильно раздувает и они становятся не читаемыми, их сложно поддерживать. make сам по себе не сильно умеет динамические сценарии сборки, для этого используют automake и autoconf. Плюс у meson более приятный и удобный синтаксис чем в m4, можно на python легко реализовать любую логику сборки, и сложные сценарии сборки. При этом сборочные скрипты будут легковесными и понятными любому.
| | |
| |
| 5.26, Аноним (26), 20:14, 08/02/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ох уж эти фантазеры, прям много лет и на большом количестве, да?
| | |
|
| 4.36, Гром (?), 13:27, 09/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
Cmake - это не система сборки, а конвертор конфигов из своего формата в форматы конфигов для систем сборки. Сам он ничего не собирает.
| | |
|
| 3.9, Аноним (-), 12:34, 08/02/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> А системы сборки пишут на питоне, представь себе!
Система сборки чуток проще чем оптимизирующий компилятор. Совсем чуть-чуть))
Ну и тот факт, что на сегодняшний день нет ни одного оптимизирующего компилятора на сишке, а только на плюсах - это просто показательно.
| | |
| |
| 4.11, Аноним (11), 13:30, 08/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
Показательно что? С++ там только из-за STL контейнеров, с которыми сильно проще строить AST. Это единственная причина почему Си компилятор написаны на С++. Но вообще есть ещё pcc и tinycc, которые написаны на Си.
| | |
| |
| 5.13, Аноним (2), 14:01, 08/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
На С++ кодеры медленно работают. Джава и лучше. Если мешают GC и проверки - можно по идее для компилятора сделать сборку jre без этого, компилятору не обязательно убирать мусор - он один файл собирает и завершается, память ОС обратно забирает сама.
| | |
| 5.19, Bottle (?), 15:28, 08/02/2025 [^] [^^] [^^^] [ответить]
| –2 +/– |
О да! Видимо, по какой-то причине сишники не осилили написать собственные STL-контейнеры! Казалось бы, что им мешало, если Сишка такой хороший язычок?
| | |
| 5.20, Аноним (-), 15:49, 08/02/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Показательно что?
Показательно что на сишке не осилили)))
> С++ там только из-за STL контейнеров, с которыми сильно проще строить AST.
Ахаха, это еще более показательно!
> pcc и tinycc...
... не являются оптимизирующими компиляторами.
pcc 1.1.0 поддерживает только x86 и x86-64, последний раз релизился 10 лет назад (читай нет поддержки современных процов) и его выкинули даже из бзди.
tinycc чуть лучше, он еще в арм смог, но все равно никаких оптимизаций
| | |
|
|
|
| 2.3, Семен (??), 11:30, 08/02/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да, так как ISPC использует как ядро LLVM. Нет смысла писать компилятор с нуля, когда LLVM дает очень удобный API для написания компиляторов. Скорость разработки в разы выше будет и 80% работы сделает LLVM. ISPC похож в работе на polly из LLVM, только может гибче и лучше векторизировать код.
| | |
|
| 1.4, 12yoexpert (ok), 11:51, 08/02/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > параллельного выполнения нескольких экземпляров одной программы с разными наборами входных данных
микросервисы задолбали даже самих интел. видимо, только так можно с ними бороться
| | |
| |
| 2.38, Аноним (38), 02:12, 10/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
Нет, это чтобы во всяких ffmpeg обойтись без ассемблерных вставок.
| | |
| 2.39, Аноним (39), 09:34, 10/02/2025 [^] [^^] [^^^] [ответить]
| +/– |
Микросервисы это не про параллельность обработки данных, а про разбиение кода и его изоляцию друг от друга. Иначе миллионы строк когда нереально поддерживать, а сборка проектов может длиться днями на средних компах. В общем хотя бы первые курсы универа закончи с дабами на c++ и переходи на что-то серьезнее.
| | |
|
| 1.17, Ю.Т. (?), 15:15, 08/02/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Править не буду, лень, но SPMD это не "несколько экземпляров входных данных". Это то, что на практике делают со средой MPI, которая формально MIMD - распределенное исполнение с физически разделенной памятью. То есть данные не "входные", а те, которые поданы на соответствующий процесс из программы.
| | |
| 1.27, Аноним (27), 20:37, 08/02/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Удобно для реализации алгоритмов обучения нейронных сетей (в частности, ресурсоемких градиентных). А вот это
> Поддерживается работа в Linux, Windows, macOS и FreeBSD
достойно.
| | |
| |
| 2.33, Аноним (33), 06:39, 09/02/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Приличные люди проприетарные системы поддерживать не будут. У сабжа пермиссивная лицензия. Неудивительно.
| | |
|
|
