LINUX.ORG.RU

Нужен компилятор ANSI C, который не умирает

 


1

2

Хочу добавить в свое приложение возможность расширения. Сначала хотел использовать любой скриптовый язык, но потом понял, что все они отстой и тормоза. По идее, если взять сишечку и скомпилять ее по быстрому, то времени это много не займет, компилять прямо в память, зато работать будет со скоростью света.

В принципе, можно просто вызывать gcc и создавать шаред-объект во временном файле, но это очень долго, если файлов будет много. Это как php, который умирает после каждого запроса. А есть ли компиляторы, которые могут работать как демоны, не тратя время на инициализацию при выполнении запросов, быстро компилить и требовать минимум ресурсов?

Алсо, подойдет и какая-то либа, в принципе можно и с собой таскать, внутри бинаря

Моя твоя не понимать. Если ты не хочешь скриптоты, то нафига заморачиваться с компиляцией, делай обычные плагины с dlopen.

Stil ★★★★★
()
Последнее исправление: Stil (всего исправлений: 1)
Ответ на: комментарий от Stil

Ну внутри оно так и будет. Другое дело, что когда пишешь скриптоту, то часто используешь принцип «написал - попробовал», т.е. в одном окошке пишешь код, в соседнем получаешь результат. Особенно когда код занимается отрисовкой чего-то. И вот я хочу, скажем, поправить одну циферку, после чего в соседнем окне увидеть как изменился результат. Быстро.

ruzisufaka
() автор топика

clang/llvm умеют ровно это (компилять будучи библиотекой). Инициализации, как таковой, нет. Для быстрой компиляции можно сделать магию с выведением всех инклюдов в precompiled header и перекомпиляцией их по необходимости, будет работать реактивно.

vzzo ★★★
()

Сначала хотел использовать любой скриптовый язык, но потом понял, что все они отстой и тормоза. По идее, если взять сишечку и скомпилять ее по быстрому, то времени это много не займет, компилять прямо в память, зато работать будет со скоростью света.

Хахаха :-) Лол :-)

anonymous
()

По идее, если взять сишечку и скомпилять ее по быстрому, то времени это много не займет, компилять прямо в память, зато работать будет со скоростью света.

Хороший JIT-компилятор для скриптоты уделает твою сишечку на раз

annulen ★★★★★
()
Ответ на: комментарий от ruzisufaka

Другое дело, что когда пишешь скриптоту, то часто используешь принцип «написал - попробовал», т.е. в одном окошке пишешь код, в соседнем получаешь результат. Особенно когда код занимается отрисовкой чего-то. И вот я хочу, скажем, поправить одну циферку, после чего в соседнем окне увидеть как изменился результат. Быстро.

В одном окне код, в другом

gcc -O2 -o plugin.so plugin.c && cp ./plugin.so /target/path/plugins/ && killall -SIGUSR1 your_app

Stil ★★★★★
()

Хочу добавить в свое приложение возможность расширения. Сначала хотел использовать любой скриптовый язык, но потом понял, что все они отстой и тормоза.

Lua то пробовал? Остальная петушня даже рядом не стоит.

anonymous
()

Создай файл .c состоящий из инклудов всех файлов, которые тебе надо скомпилить, и компиль его:

#include "1.c"
#include "2.c"
...
unC0Rr ★★★★★
()
Ответ на: комментарий от annulen

Сишечку никогда не уделать, ведь все ведет к ней. Другое дело, что можно проссать высокоуровневый алгоритм, который из скриптоты можно было бы эффективно оптимизировать, а в сишечке - нет.

ruzisufaka
() автор топика
Ответ на: комментарий от Stil

Плохо, очень плохо

gcc -O2 -o plugin.so plugin.c

Это как раз не быстро. Компилятор умирает и каждый раз начинает все заново.

cp ./plugin.so /target/path/plugins/

Это еще хуже, теперь у нас будут тысячи временных файлов. Еще медленней и менее безопаснее.

killall -SIGUSR1 your_app

Если редактор уже внутри приложения - не нужно

ruzisufaka
() автор топика

Запили нормальную систему плагинов, хотя бы в виде .so библиотек и не извращайся. А скриптота должна быть на питоне.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)

tcc уже советовали? Попробуй. Но не рассчитывай на интенсивное применение. Оно не реентерабельно и не потоко-безопасно. Сам для себя давно ищу что-то подобное(и для подобных целей). Эти идиоты используют глобальные переменные внутри, а мне нужно параллельное компилирование. А привести в порядок введя state не хватает терпения.Да и толку если разрабы пилят матчасть, при этом плевать хотели на читаемость кода, я потом не смержусь вовсе.

FeyFre ★★★★
()
Ответ на: комментарий от ruzisufaka

Сишечку никогда не уделать, ведь все ведет к ней. Другое дело, что можно проссать высокоуровневый алгоритм, который из скриптоты можно было бы эффективно оптимизировать, а в сишечке - нет.

Ассемблер никогда не уделать, ведь все ведет к нему. Другое дело, что можно проссать высокоуровневый алгоритм, который из скриптоты можно было бы эффективно оптимизировать, а в ассемблере - нет.

Ой, к чему это я? Ах, да, компилятор тебе тогда не нужен :D

Waterlaz ★★★★★
()
Ответ на: комментарий от ruzisufaka

Это как раз не быстро. Компилятор умирает и каждый раз начинает все заново.

Что по-твоему компилятор начинает заново, что можно было бы не начинать?

Ты же понимаешь, что тут либо компилируем долго, но в эффективный код, либо быстро, но в неэффективный и могли бы уже скриптовый язык брать и не выпендриваться.

Waterlaz ★★★★★
()
Ответ на: комментарий от ruzisufaka

Для DSP?

Ты на DSP собираешься запускать компилятор Си?

tailgunner ★★★★★
()
Ответ на: комментарий от FeyFre

Да, активно смотрю на него, особенно на libtcc, однако вот такая пляска со стейтом пугает. Пока не разобрался, можно ли сделать инкрементальную компиляцию.

Что касаемо разрабов, то это ты зря, на главной проекта запись, что последний релиз был 3 года назад, а ныне автор ничего не девелопит больше. Есть ссылка на форк, но там еще более ломающие откровения и новый форк, который, как я понимаю, еще даже не пилится. Так что можешь форкать и считать себя лидером проекта

ruzisufaka
() автор топика
Ответ на: комментарий от Waterlaz

Что по-твоему компилятор начинает заново, что можно было бы не начинать?

Перечитывает все иклюды, ведет полный разбор всех файлов и только потом, когда оно знает что и зачем - оно компилируется. Вот это вот все хотелось бы держать в памяти. Потом линковка (я правда не очень понимаю, что в моем случае с ней делать), мы опять перечитываем кучу всего. Представь, что мы линкуемся с чем-то большим вроде ffmpeg, выхлоп бинарника на выходе - 100+ метров, а то и сильно больше, в зависимости от условий сборки.

А теперь представь, что ты поменял одну цифру в исходнике и хочешь посмотреть чем это закончится. Или условие. Если бы просто цифры менять, то можно было бы компилить с magic numbers и патчить самого себя.

ruzisufaka
() автор топика

Хочу добавить в свое приложение возможность расширения. Сначала хотел использовать любой скриптовый язык, но потом понял, что все они отстой и тормоза.

LUA, LuaJIT.

devl547 ★★★★★
()

Хочу добавить в свое приложение возможность расширения. Сначала хотел использовать любой скриптовый язык, но потом понял, что все они отстой и тормоза. По идее, если взять сишечку

Вот тут в голосину. Как там борщ? Вкусный?

Aswed ★★★★★
()
Ответ на: комментарий от ruzisufaka

Использование ANSI C там, где самое время подключить lua или что-то подобное с уже написанным хорошим JIT, ничем не лучше использования haskell не по назначению.

Aswed ★★★★★
()
Ответ на: комментарий от Stil

Если ты не хочешь скриптоты, то нафига заморачиваться с компиляцией, делай обычные плагины с dlopen.

Удваиваю.

hobbit ★★★★★
()
Ответ на: комментарий от ruzisufaka

Особенно когда код занимается отрисовкой чего-то. И вот я хочу, скажем, поправить одну циферку, после чего в соседнем окне увидеть как изменился результат. Быстро.

Мне кажется, это достигается просто грамотной настройкой твоей IDE. Чтобы при запуске твоего плагина запускалась хост-программа и подхватывала плагин.

А то, что это не моментально - увы, это как раз из-за неидеальности Си, в котором в 2016 году до сих пор не завезли нормальных модулей. В Object Pascal, кстати, они есть, и он собирается гораздо быстрее. :) Другое дело, что у паскаля свои недостатки.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Проблема в том, что я этот хост и пишу, при этом слабо понимаю, как обеспечить такую интеграцию. Затащить с собой компилятор - вроде неплохая идея. Конечно, не будет работать на АРМах, слабо представляю как это будет линковаться под маком или форточкой, но это не критично, девелопить можно будет уже хоть как-то. В итоге получается какой-то монстр в виде встроенной IDE. Хотя изначально планировался простой текстовый редактор и кнопка «применить».

ruzisufaka
() автор топика
Ответ на: комментарий от Aswed

Могу ли я c LuaJit ворошить мегабайты байтиков? Скажем, сделать размытие Гаусса, при этом так, что скорость будет не совсем убийственна? Я понимаю, что чудес не бывает и даже с сишкой реалтайм не получить, но не хотелось бы получить 0.0001 fps вместо 1fps

ruzisufaka
() автор топика
Ответ на: комментарий от ruzisufaka

Затащить с собой компилятор - вроде неплохая идея.

Затащить dlopen явно проще :)

hobbit ★★★★★
()
Ответ на: комментарий от ruzisufaka

Для таких целей можно взять OpenCL, если ограничения по железу устраивают.

asavonic
()
Ответ на: комментарий от ruzisufaka

размытие Гаусса [...] даже с сишкой реалтайм не получить

На каком железе?

gag ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.