LINUX.ORG.RU

Хочу C++ без C++

 ,


0

2

Такие дела.
Безплюсового старшего брата сразу отметаем. Интерпретируемые/JIT-языки тоже отметаем. Языки типа D, в которых размер бинарника хелловорда около мегабайта отметаем так же.
Хотелось бы, что-то типа Python, но который не требует интерпретатора, как Cython, для своей работы.
Что там остается? Есть ли Путь? Сколько времени прошло с создания C/C++, появилась ли им вменяемая альтернатива?
Если писать с нуля транслятор Python (СТ) в код на C (не машинный, не llvm), какие там основные проблемы будут? Преобразование грамматик? Падение производительности? В чем основные сложности и примерно сколько времени займет реализация такого проекта? Кто-нибудь подобным занимался?



Последнее исправление: cetjs2 (всего исправлений: 2)

Если писать с нуля транслятор Python (СТ) в код на C (не машинный, не llvm), какие там основные проблемы будут?

Уже написан: http://nuitka.net/

Но вообще-то сила Си++ - в шаблонах и вот этом всём.

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

Qt 5 - лучший C++ без C++, рекомендовано лучшими собаководами

Если писать с нуля транслятор Python (СТ) в код на C (не машинный, не llvm)

А что скажешь о Vala?

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от JN

Настолько я помню, это поделие еле концы с концами сводит

«Едва сводить концы с концами» означает «быть бедным, нуждаться». Ты уверен, что хотел сказать именно это?

проигрывая даже CPython'у.

По скорости оно выигрывает у CPython. Но, естественно, при сохранении семантики Python тупой трансляцией в Си большого выигрыша не добиться.

tailgunner ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

А что скажешь о Vala?

Это нужно исследовать, спасибо

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

Спасибо, не знал, буду пробовать

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

Безплюсового старшего брата сразу отметаем. Интерпретируемые/JIT-языки тоже отметаем. Языки типа D, в которых размер хелловорда около мегабайта отметаем так же.

Ты хоть расскажи по какой причине отметаешь каждый из трёх, чтобы не гадать что тебе нужно. Дай список конкретных требований. «хелловорлд меньше мегабайта» - это не конкретное. «Хелловорлд чтобы влез в мой спаянный на коленках контроллер с памятью 64кб» - достаточно конкретное.

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

В недавнем треде было установлено, что вместо Vala надо писать на Swift :)

annulen ★★★★★
()

Посмотри на Nim.

ПС: Ты Упорот!

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

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

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

У OCaml компилятор выдаёт маленькие быстрые бинарники, но у него проблема с параллельностью. Для Haskell GHC генерит быстрый код, но RTS у него жирен, и бинарник меньше мегабайта размером ты вряд-ли получишь. Есть ещё Rust, но от его синтаксиса хочется вырвать себе глаза, вскрыть вены на жопе и умереть, а так он вроде как неплох.

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

Да, ты таки реально упоротый. Школоло небось?

anonymous
()
Ответ на: комментарий от Oxdeadbeef

Самое серьезное это когда на ассемблере все

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

Все упомянутые языки(кроме Rust) обладают одним неприятным свойством - в них неотключаемый GC. Неотключаемый GC - плохо. Человек способен более грамотно распоряжаться памятью, при желании человек может даже свой специальный GC сделать в тех же плюсах (в фаерфоксе например есть GC) который будет эффективней, чем некий GC общего назначения, впиленный разрабами языка в рантайм

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

Неотключаемый GC - плохо.

Почему?

Человек способен более грамотно распоряжаться памятью

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

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

Все упомянутые языки(кроме Rust) обладают одним неприятным свойством - в них неотключаемый GC. Неотключаемый GC - плохо. Человек способен более грамотно распоряжаться памятью, при желании человек может даже свой специальный GC сделать в тех же плюсах (в фаерфоксе например есть GC) который будет эффективней, чем некий GC общего назначения, впиленный разрабами языка в рантайм

Выигрыш обычно минимален, а вот ошибок из-за ручного управления памятью куча.

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

В Nim GC отключается, но его сишный выхлоп пока меня немного пугает

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

Да, способен.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663
http://govnokod.ru/19395
кто считает что компиляторы прям такие крутые что человеку их не переплюнуть - не читали выхлопы компиляторов

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

Неотключаемый GC - плохо.

Почему?

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

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

Потому что неэффективно

Пруф.

перерасход памяти

Насколько большой?

фризы при периодической сборке мусора

Хватит насиловать Java.

проблемы с реалтаймовостью

Если мы про Linux - он сам по себе не реалтаймовый. Решит у тебя кто-то заняться I/O по-взрослому и окажешься ты в полной заднице.

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

Потому что неэффективно

Пруф.

Сравнивать эффективность ручного управления памятью из Си(malloc/free) с GC из какого языка? http://lambda-the-ultimate.org/node/2552 вот статейка

перерасход памяти

Насколько большой?

https://benchmarksgame.alioth.debian.org/u64q/java.html смотрим на потребление памяти.

фризы при периодической сборке мусора

Хватит насиловать Java.

Проявляется не только в Java. Пруф http://rsdn.ru/forum/dotnet/4664675.hot

проблемы с реалтаймовостью

Если мы про Linux - он сам по себе не реалтаймовый.

Вроде никто четко не обозначил, в какой среде (Windows, Linux, QNX, VxWorks или что там еще) рассматриваюся проблемы, связанные с GC.

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

И в чём проблема поправить пару багов в компиляторе, чтобы он начал выдавать более эффективный код?

Я уже не говорю о том, что затраты на железо практически всегда ниже затрат на разработку софта.

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

Все статьи ведут на обсуждения Java и dotnet. Да, GC в Java действительно отвратителен.

kirk_johnson ★☆
()

Brainfuck /thread

Deleted
()
Ответ на: комментарий от Deathstalker

Deathstalker спасибо за ссылку на хабр. На фоне местного русификатора Лиспа радует что есть люди, которые сами что-то пишут.

Ivana
()
Ответ на: комментарий от hateyoufeel

Там замеряется пиковое потребление. В Си можно пробовать соптимизировать потребление ОЗУ, например взять этот код https://benchmarksgame.alioth.debian.org/u64q/program.php?test=mandelbrot&amp...

OCaml
	13.78 	5,492 	710 	54.89 	100% 100% 100% 100%
C gcc
	5.92 	32,464 	694 	22.81 	95% 100% 96% 95% 

Там есть всего 1 malloc

uint8_t * const pixels=malloc(image_Width_And_Height*
     image_Width_And_Height/8);
И если вдруг стоит задача считать мандельброта на каких-то устройствах с жестким ограничением ОЗУ, можно просто не выделять такой большой блок памяти, а выводить картинку кусками. https://benchmarksgame.alioth.debian.org/download/mandelbrot-output.txt вот тут пример самой картинки, формат Netpbm PBM "rawbits" image data, size = 200 x 200
Программа пишет это в файл. Очевидно что можно писать файл кусками, а не выделять сразу большой кусок памяти под всю картинку и в него писать.

SZT ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Qt 5 - лучший C++ без C++

Qt - тулкит для гуйни. Если гуйня не нужна, то зачем его тащить, можешь хоть один нормальный аргумент привести?

А vala - вообще маргинальное недо-поделие...

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

Размер бинарника хелловорда в один метр показывает несерьезность подхода.

Смешно...

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

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

Круто. Как это относится к управлению памятью, и почему «писать файл кусками» нельзя в языках с GC?

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

Можно где угодно. К управлению памяти это никак не относится. Хотя не, относится. С управлением памятью я могу в более явном виде работать с выделением и освобожденем кусков памяти, могу переиспользовать уже выделенную память, вместо того чтоб освобождать и выделять новый кусок. Не стоит так же забывать про realloc (mremap) для расширения выделенного куска памяти. Не знаю, как все это реализуется на уровне рантайма GC-языков, но в Си я получаю более предсказуемое поведение

Можно посравнивать какие-нибудь реализации деревьев, двусвязных списков, и прочего такого

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

Почему?

Потому что риалтайм писать нельзя.

А управлять памятью, а точнее иметь возможность удалять всё что надо тогда когда мне удобно - необходимость, потому что если работаешь с большим количеством данных, то их желательно удалять сразу же после использования и не загаживать ими память и не ждать пока там GC разродится.

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