Лингвофорум

Цитата: myst от июля 28, 2009, 23:26
Язык не может быть быстрым или медленным, нет у него такого качества.

Есть, скорость зависит от концепции языка. Если все методы делать виртуальными (то бишь на каждый вызов, даже если нету потомков, будет проводиться диспатчинг в пару лишних опкодов), как это в смоллтоке или обж-с, то любая реализация некоего класса А на таких языках гарантированно будет медленнее, чем то же, но средствами с++, в котором методам разрешено быть невиртуальными.
Если в концепции языка нету такой штуки, как объект на стеке (как например в жабе), то и в данном случае в практически любой реализации ява-машины гарантированно оно будет медленнее, чем в с++ (слыхал, якобы, последние явы умеют распозновать что к чему и выделять объект на стеке, но хз хз).
Если в концепции усмотрено прототипирование, то тоже всё будет гарантированно медленнее, чем в языке без прототипирования.
Если в концепции языка усмотрен дак-тайпинг, то бишь проверка типов в рантайме, то оно гарантированно будет медленнее, чем в языках со статической типизацией.
Если в концепции есть такие вещи как интроспеция самого себя в любой момент времени с вытекающими, где неминуема интерпретация, то оно тоже будет гарантированно медленнее, чем без.
Концепция языка во многом задаёт скорость выполнения по сравнению с другими концепциями. Поэтому можно сравнивать.

ЦитироватьПроблема эта даже не в самом gcc, а в библиотеке. Язык тут вообще не при чём.

Эээ. Вообще-то стандарт задаёт набор библиотек. Без них язык не язык. Они есть часть языка. Если есть кривость в реализации стандартной либы, значит это кривость в реализации языка вообще.

Цитата: Алексей Гринь от июля 29, 2009, 00:18
Если все методы делать виртуальными (то бишь на каждый вызов, даже если нету потомков, будет проводиться диспатчинг в пару лишних опкодов), как это в смоллтоке или обж-с, то любая реализация некоего класса А на таких языках гарантированно будет медленнее, чем то же, но средствами с++, в котором методам разрешено быть невиртуальными.

Ничего подобного. Из того, что текущие реализации на текущем железе медленные, не следует принципиальная медленность языка.

Цитата: Алексей Гринь от июля 29, 2009, 00:18
Если есть кривость в реализации стандартной либы, значит это кривость в реализации языка вообще.

Что значит вообще?

Но так-то mingw-gcc переадресует все malloc'ы и free'ы к таковым в msvcrt.dll, которые сами по себе являются обёртками над winapi'шными функциями типа GlobalAlloc, LocalAlloc и проч., поэтому не понятно в принципе почему VC++ вариант быстрее, ведь он обращается к тем же самым системным функциям.

Цитата: myst от июля 29, 2009, 00:22
Ничего подобного. Из того, что текущие реализации на текущем железе медленные, не следует принципиальная медленность языка.

Так медлнность понятие относительное! Если реализация языка А на одном железе медленнее реализации языка Б на том же самом — значит, реализация языка А медленная. Я что, при сравнении запускаю Си++ на первом пне, а Си-вариант на Интел Коре Ту Квад? Делать нечего

Цитата: myst от июля 29, 2009, 00:25
Что значит вообще?

Стандартная библиотека = часть языка.
Если есть баг/тормоза в стандартной библиотеке — значит, это баг/тормоза в языке (точнее в его реализации)

Цитата: Алексей Гринь от июля 29, 2009, 00:26
Но так-то mingw-gcc переадресует все malloc'ы и free'ы к таковым в mscvrt.dll, которые сами по себе являются обёртками над winapi'шными функциями типа GlobalAlloc, LocalAlloc и проч., поэтому не понятно в принципе почему VC++ вариант быстрее, ведь он обращается к тем же самым системным функциям.

Ты не понял, у меня сишная версия чуть медленнее сплюплюсной, если собирать микрософтовскими инструментами. GCC у меня из cygwin'а вообще. Сравнивать скорость cygwin'овских со скоростью «родных» программ смысла нет.

Почему медленнее? Надо лезть в дизассемблер и смотреть. Чудес, ясное дело, не предвидится.

Цитата: myst от июля 29, 2009, 00:33
GCC у меня из cygwin'а вообще.

Ужос...

Цитата: myst от июля 29, 2009, 00:33
Сравнивать скорость cygwin'овских со скоростью «родных» программ смысла нет.

А я-то сравниваю mingw-овские; тебе смысла нет, мне — есть


.text:77C1C407                 mov     edi, edi
.text:77C1C409                 push    ebp
.text:77C1C40A                 mov     ebp, esp
.text:77C1C40C                 cmp     hHeap, 0
.text:77C1C413                 jnz     short loc_77C1C420
.text:77C1C415                 call    sub_77C0EF38
.text:77C1C41A                 test    eax, eax
.text:77C1C41C                 jnz     short loc_77C1C420
.text:77C1C41E                 pop     ebp
.text:77C1C41F                 retn
.text:77C1C420
.text:77C1C420 loc_77C1C420:   
.text:77C1C420                 push    dword_77C51808
.text:77C1C426                 push    [ebp+arg_0]
.text:77C1C429                 call    alloc_memory
.text:77C1C42E                 pop     ecx
.text:77C1C42F                 pop     ecx
.text:77C1C430                 pop     ebp
.text:77C1C431                 retn


.text:77C19CC5                 mov     edi, edi
.text:77C19CC7                 push    ebp
.text:77C19CC8                 mov     ebp, esp
.text:77C19CCA                 push    1
.text:77C19CCC                 push    [ebp+arg_0]
.text:77C19CCF                 call    alloc_memory
.text:77C19CD4                 pop     ecx
.text:77C19CD5                 pop     ecx
.text:77C19CD6                 pop     ebp
.text:77C19CD7                 retn

malloc медленнее из-за ветвления. Я же говорил, что никаких чудес.

Вообще оптимизаторы любят конструкторы инлайнить. Видимо, gс++ не инлайнил у меня...

Цитата: Алексей Гринь от июля 29, 2009, 00:38
А я-то сравниваю mingw-овские; тебе смысла нет, мне — есть

Ты опять не понял, я сравнивал варианты, собранные одними инструментами. Разница в пользу Си есть только у gcc из-за реализации new в libstdc++, ну и в delete есть лишнее ветвление (парни ниасилили стандарт, или реализация free была баговая ).

Цитата: Алексей Гринь от июля 29, 2009, 00:48
Видимо, gс++ не инлайнил у меня...

Если мне память не изменяет, определение CPLala(int x, int y): x(x), y(y) { } всегда inline.

Таки короче надо популяризировать идеи Vala

Цитата: Алексей Гринь от июля 29, 2009, 00:38
Ужос...

Ну почему ужос? Да, он педальный, но очень полезный. Версия 1.7 просто замечательная, даром что бета ещё.

Цитата: Алексей Гринь от июля 29, 2009, 00:55
Таки короче надо популяризировать Vala

Они его допилили? Помню, гноммеры раскидывали распальцовки на ЛОР'е, но тогда эта штука была сыровата.

Цитата: myst от июля 29, 2009, 00:57
Они его допилили? Помню, гноммеры раскидывали распальцовки на ЛОР'е, но тогда эта штука была сыровата.

Да мне не нравится ентот GObject. Я хочу C#-/Java-подобный простенький язык, но шоб без огромного рантайма (а ля gcj'овский в 3 мегабайта, аха), без сборщика мусора, без зависимости от непонятных кривоватых динамически-типизированных либ типа GObject. Шоб то, шо я делаю в объектно-ориентированном си, отшаблонить в более простые и абстрактные структуры...
Хоть сам иди и транслятор в Си пиши, ничего толкового нету (везде какие-нибудь медленные, тяжеловесные депенденсись) А ля

Цитироватьvar childClass = new childClass();
childClass.boo();

превратилось в что-то типа

ЦитироватьChildClass* childClass = ChildClass_create();
(*__dispatch(childClass, ChildClass_BOO))(); // где ChildClass_BOO енто макрос для, скажем, 2 (номер в таблице методов)

И усё. Потом любимым компилятором прошёлсе и получил бинарник. А вот Vala генерит для такого примера такой ужас, шо ужас.

Надо бы ужо осилить какой-нибудь yacc

Цитата: Алексей Гринь от июля 29, 2009, 01:09
Я хочу C#-/Java-подобный простенький язык, но шоб без огромного рантайма (а ля gcj'овский в 3 мегабайта, аха), без сборщика мусора, без зависимости от непонятных кривоватых динамически-типизированных либ типа GObject.

Да, нету щастья. Я, помню, искал-искал, но так и не нашёл. Нужна ось, у которой юзерленд из рантайма той же Жабы, Оберона или CL растёт, и будет всё OK. Но все велосипеды придётся переизобретать, особенно в случае Оберона.