Здравствуйте, Cyberax, Вы писали:
C>Я разговаривал с создателями LLVM.
Боюсь, что на оэтом уровне данное знание мало что даст.
C> Они прекрасно знают, что такое ПМ и как он помогает. Более того, они и GCCшники давно уже используют PM там, где надо. Естественно, с помощью специальных DSLей (см. файлы описаний архитектур машин в GCC и TableGen в LLVM).
Ну, вот оказывается все как интересно. Жать только, что свое знание они пытаются унести в могилу. Да и "там, где надо" у них слишком узкое.
C>В основном коде PM не дает таких преимуществ, чтобы прямо так бросаться и переписывать все. Тем более, что для этого есть всего один реальный язык — OCaml.
Неправда в обоих утверждения. И дает не мало. И кроме ОКамлм языков еще куча.
WH>>А еще при разработке компиляторов рулят ГЦ и макросы (нормальные, а не Сишные). C>Макросы? Сомнительно.
Тут все просто как неучить уроки. Макросы позволяют развивать язык на более высоком уровне. Многие фичи языка — это шорткаты для некоторых паттернов. Возьмем тот же foreach. Одно дело реализовать его на С++ используя только классы предсавляющие АСТ, а другое написать его на макросах. Тут уже разница получается не на банальные 3-6 раз, а более чем на порядок. Причем сопровождаемость кода просто несопоставима. Одно дело поправить код генерируемый с помощь квази-цитирвоания, а другое ужастное награмождение низкоуровневых операций на С++ с АСТ.
C>GC в некоторых случаях очень помогает, но в той же LLVM показали, что вполне сойдут и счтетчики + пулы.
Это без разницы. Важно, чтобы память управлялась автоматически и стомость выделения памяти была не очень сильно выше выделения память в стеке.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Люблю я ваши разы и порядки высосанные из пальца
VD>Да, да. У нас тех кто пробовал и знает, оно конечно из пальца, а у вас теоретиков все цифры точные.
Цифры есть только у эрлангистов им их добрый дядя эрриксон дал, остальные все в равном положении
WH>В этой статье есть пример калькулятора. WH>Сравни C#ную версию с немерловой. WH>В случае с голым С все будет еще хуже.
Угадайте, во сколько строк можно сделать калькулятор на голом С, умеющий вычислять выражения типа
"d=8, 1+(a=b=2*(c=2+d))/5+a" ? 20 строчек! Существенно короче, чем ничего не умеющий пример из той статьи.
По иронии судьбы автор того калькулятора сейчас девелопит GCC на чистом С...
Здравствуйте, VladD2, Вы писали:
C>>Я разговаривал с создателями LLVM. VD>Боюсь, что на оэтом уровне данное знание мало что даст.
Так я и не претендую на вселенское абсолютное знание
C>> Они прекрасно знают, что такое ПМ и как он помогает. Более того, они и GCCшники давно уже используют PM там, где надо. Естественно, с помощью специальных DSLей (см. файлы описаний архитектур машин в GCC и TableGen в LLVM). VD>Ну, вот оказывается все как интересно. Жать только, что свое знание они пытаются унести в могилу. Да и "там, где надо" у них слишком узкое.
По мнению GCCшников и LLVMистов — вполне достаточное. В принципе, я с ними согласен.
C>>В основном коде PM не дает таких преимуществ, чтобы прямо так бросаться и переписывать все. Тем более, что для этого есть всего один реальный язык — OCaml. VD>Неправда в обоих утверждения. И дает не мало. И кроме ОКамлм языков еще куча.
И какие из них подходят под следующие условия: Работает на всех платформах (или хотя бы компилируется в чистый С)
Поддерживает нормальную интероперабельность с C-шным кодом
Не требует изучать (и использовать) монады
Быстрый
?
C>>Макросы? Сомнительно. VD>Для блабов то? Естественно. А для тех кто сам этим занимался сомнений никаких нет. Вот почитай, хотя бы это сообщение: VD>Добавил поддержку auto-property (как в C# 3.0)
И? Большая часть компилятора — это кодогенерация. Там макросы уже есть в виде языка описания машины. Остальная часть — это оптимизации. Там жесткий "алгоритмический" код, для которого достаточно языка на уровне Паскаля/С. Там не нужно делать прозрачную поддержку свойств и строить компонентные фреймворки.
VD>Тут все просто как неучить уроки. Макросы позволяют развивать язык на более высоком уровне. Многие фичи языка — это шорткаты для некоторых паттернов. Возьмем тот же foreach. Одно дело реализовать его на С++ используя только классы предсавляющие АСТ, а другое написать его на макросах. Тут уже разница получается не на банальные 3-6 раз, а более чем на порядок. Причем сопровождаемость кода просто несопоставима. Одно дело поправить код генерируемый с помощь квази-цитирвоания, а другое ужастное награмождение низкоуровневых операций на С++ с АСТ.
Тупых низкоуровневых операций с AST в LLVM не так много — оно как раз по большей части нужно в генераторе кода, а там замечательно работает TableGen.
Еще жестокая работа с графами в некоторых оптимизаторах, но в них там примерно половина файла — это комментарии того, что они делают. Там вряд ли бы PM чем-то особенным помог, так как объем кода вовсе не является главной проблемой.
C>>GC в некоторых случаях очень помогает, но в той же LLVM показали, что вполне сойдут и счтетчики + пулы. VD>Это без разницы. Важно, чтобы память управлялась автоматически и стомость выделения памяти была не очень сильно выше выделения память в стеке.
Ну оно так и есть. Например, JIT в LLVM работает очень шустро, причем, может использоваться в системах без GC. Там очень неплохо все сделано.
Здравствуйте, Cyberax, Вы писали:
C>По мнению GCCшников и LLVMистов — вполне достаточное. В принципе, я с ними согласен.
А я нет. Собственно у них такой бэкграунд, что от них и этого то ожидать не приходилось.
C>>>В основном коде PM не дает таких преимуществ, чтобы прямо так бросаться и переписывать все. Тем более, что для этого есть всего один реальный язык — OCaml. VD>>Неправда в обоих утверждения. И дает не мало. И кроме ОКамлм языков еще куча. C>И какие из них подходят под следующие условия: C> C> Работает на всех платформах (или хотя бы компилируется в чистый С) C> Поддерживает нормальную интероперабельность с C-шным кодом C> Не требует изучать (и использовать) монады C> Быстрый C>C>?
На всех платформах не работает ни один язык. Если это бессмысленное требование отбросить, то прийдется выкинуть только Хаскель.
C>И? Большая часть компилятора — это кодогенерация.
Большая.
C> Там макросы уже есть в виде языка описания машины.
Какой на фиг машины?
C> Остальная часть — это оптимизации. Там жесткий "алгоритмический" код, для которого достаточно языка на уровне Паскаля/С. Там не нужно делать прозрачную поддержку свойств и строить компонентные фреймворки.
Для оптимизаций рулят (не мерянно) ПМ и алгеброические типы. Макросы рулят для реализции фич. В общем, С/С++ в этой области отдыкат.
C>Тупых низкоуровневых операций с AST в LLVM не так много — оно как раз по большей части нужно в генераторе кода, а там замечательно работает TableGen.
Про LLVM никто и не вел речь. Это низкоуровневая фиговина.
C>Еще жестокая работа с графами в некоторых оптимизаторах, но в них там примерно половина файла — это комментарии того, что они делают. Там вряд ли бы PM чем-то особенным помог, так как объем кода вовсе не является главной проблемой.
Ну, ну.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, D. Mon, Вы писали:
DM> DM>Угадайте, во сколько строк можно сделать калькулятор на голом С, умеющий вычислять выражения типа DM>"d=8, 1+(a=b=2*(c=2+d))/5+a" ? DM>20 строчек! Существенно короче, чем ничего не умеющий пример из той статьи.
DM>По иронии судьбы автор того калькулятора сейчас девелопит GCC на чистом С...
Там до конца нужно читать:
Да, и последнее. Никогда так не делайте.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Я разговаривал с создателями LLVM.
А я видил их код
C>Они прекрасно знают, что такое ПМ и как он помогает.
Похоже что плохо они это знают.
C>Более того, они и GCCшники давно уже используют PM там, где надо. Естественно, с помощью специальных DSLей (см. файлы описаний архитектур машин в GCC и TableGen в LLVM).
Код ГЦЦ вобще ужасен.
C>В основном коде PM не дает таких преимуществ, чтобы прямо так бросаться и переписывать все. Тем более, что для этого есть всего один реальный язык — OCaml.
Хватит эту ерунду повторять.
WH>>А еще при разработке компиляторов рулят ГЦ и макросы (нормальные, а не Сишные). C>Макросы? Сомнительно.
Это ты разработчикам немерла скажи...
C>GC в некоторых случаях очень помогает, но в той же LLVM показали, что вполне сойдут и счтетчики + пулы.
Закат солнца в ручную.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
FR>>Абстрактно может и не тягатся, а реально разрывов на порядки не будет. VD>Ну, да 3-6 раз... храмой кобыле, как известно, 100 верст не крюк.
Бешеной собаке 100 вёрст -- не крюк.
Здравствуйте, VladD2, Вы писали:
C>>По мнению GCCшников и LLVMистов — вполне достаточное. В принципе, я с ними согласен. VD>А я нет. Собственно у них такой бэкграунд, что от них и этого то ожидать не приходилось.
Там многие товарищи по своему языку написали Так что я лично в их умственных способностях не сомневаюсь.
VD>>>Неправда в обоих утверждения. И дает не мало. И кроме ОКамлм языков еще куча. C>>И какие из них подходят под следующие условия: C>> C>> Работает на всех платформах (или хотя бы компилируется в чистый С) C>> Поддерживает нормальную интероперабельность с C-шным кодом C>> Не требует изучать (и использовать) монады C>> Быстрый C>>C>>? VD>На всех платформах не работает ни один язык. Если это бессмысленное требование отбросить, то прийдется выкинуть только Хаскель.
Платформа, для которой нет компилятора С — это не платформа А если серьезно, то какие еще языки ты знаешь, которые лучше всего подходят под эти параметры? Я еще могу ОКамл вспомнить, но он очень многим не нравится.
C>>И? Большая часть компилятора — это кодогенерация. VD>Большая.
Большая.
C>> Там макросы уже есть в виде языка описания машины. VD>Какой на фиг машины?
В GCC/LLVM используется специальный язык для описания архитектуры машин. В LLVM выглядит вот так:
; Decrement and branch conditional instructions cannot modify the
; condition codes for the cycles in the delay slots.
;
(define_delay (eq_attr "type" "dbc")
[(eq_attr "in_dbc_slot" "true") (nil) (nil)
(eq_attr "in_dbc_slot" "true") (nil) (nil)
(eq_attr "in_dbc_slot" "true") (nil) (nil)])
; The LAJ instruction has three delay slots but the last slot is
; used for pushing the return address. Thus we can only use two slots.
;
(define_delay (eq_attr "type" "laj")
[(eq_attr "in_delay_slot" "true") (nil) (nil)
(eq_attr "in_delay_slot" "true") (nil) (nil)])
По этим описаниям потом генерируются конечные автоматы для компиляции RTL (Register Transfer Language) в машинный код в GCC, и SSA-дерева в машинный код в LLVM.
C>> Остальная часть — это оптимизации. Там жесткий "алгоритмический" код, для которого достаточно языка на уровне Паскаля/С. Там не нужно делать прозрачную поддержку свойств и строить компонентные фреймворки. VD>Для оптимизаций рулят (не мерянно) ПМ и алгеброические типы. Макросы рулят для реализции фич. В общем, С/С++ в этой области отдыкат.
Чем они там немеряно рулят? Я видел компилятор OCaml'а в нативный код и в байт-код, там большая часть match'ей — просто аналог switch..case'ов. Да, в С++ теряем некоторую безопасность из-за использования констант, но на практике опять ничего groundbreaking.
C>>Тупых низкоуровневых операций с AST в LLVM не так много — оно как раз по большей части нужно в генераторе кода, а там замечательно работает TableGen. VD>Про LLVM никто и не вел речь. Это низкоуровневая фиговина.
LLVM — это, фактически, бэкэнд компилятора. А именно это — наиболее сложная часть.
Например для GCC, фронтэнд для С++ занимает 3344064 байт (а фронтэнд для более простого Objective C занимает 645Кб). Бэкэнд GCC занимает 15941916 байт. Описания архитектур и занимают еще 11658899 байт.
То есть, мы видим, что даже если мы перепишем наш компилятор С++ на супермегаязык, который в 3 раза короче чистого С (т.е. в файлах мало что останется кроме комментариев), то у нас общий размер компилятора не уменьшится на значительную величину.
Здравствуйте, WolfHound, Вы писали:
C>>Я разговаривал с создателями LLVM. WH>А я видил их код
И что там такого? Неплохой С++-ный код, без темплейтных извращений.
C>>Более того, они и GCCшники давно уже используют PM там, где надо. Естественно, с помощью специальных DSLей (см. файлы описаний архитектур машин в GCC и TableGen в LLVM). WH>Код ГЦЦ вобще ужасен.
Согласен.
C>>В основном коде PM не дает таких преимуществ, чтобы прямо так бросаться и переписывать все. Тем более, что для этого есть всего один реальный язык — OCaml. WH>Хватит эту ерунду повторять.
Прекрасно, какие еще есть языки, который подходят под мой список требований?
WH>>>А еще при разработке компиляторов рулят ГЦ и макросы (нормальные, а не Сишные). C>>Макросы? Сомнительно. WH>Это ты разработчикам немерла скажи...
Ну так Немерль весь из макросов состоит. Так что не очень понятно что им говорить.
C>>GC в некоторых случаях очень помогает, но в той же LLVM показали, что вполне сойдут и счтетчики + пулы. WH>Закат солнца в ручную.
Однако, работает нормально и быстро. Использовать в клиентском коде просто, работает надежно. Что еще надо?
Здравствуйте, D. Mon, Вы писали:
DM>Угадайте, во сколько строк можно сделать калькулятор на голом С, умеющий вычислять выражения типа DM>"d=8, 1+(a=b=2*(c=2+d))/5+a" ? DM>20 строчек! Существенно короче, чем ничего не умеющий пример из той статьи.
Смешно Такой код пишется только ради спортивного интереса или как тут выражаются пенисометрия ради, это можно и на других языках залудить, но вот стоит ли это того.
ЗЫ. Кстати да, как долго согласишься работать там, где весь код пишется в подобном стиле? Уволишься или будешь просить прибавку за вредность
Здравствуйте, ambel-vlad, Вы писали: AV>Не сказал бы так. Если языки с ПМ так сильно упрощают написание, то было бы логично именно их использовать. Тем более, что написанием компиляторов занимаются достаточно выкосоклассные специалисты. И они способны выбрать инструмент под задачу. Да и на рекламный булшит менее ведуться. Однако этого не наблюдается. Значит все таки не все так прекрасно. Не так ли?
Все прекрасно наблюдается. Если ты посмотришь на экспериментальные компиляторы, анализаторы, и вообще на чем пишет народ в околокомпиляторной тусовке, то это никак не С++. Предпочитают играть с ML, F# и прочей функциональщиной. Вот уже потом, при доведении до коммерческого статуса, начинается мучительное переписывание на неуправляемые императивные языки. Начинается по разным причинам, не последняя из которых — отсутствие промышленного фукционально-ориентированного языка.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, trukhin.yuri, Вы писали:
S>>Чтоже тогда w2k3as на рабстанции ставить? или хрень на серваки? Да и вообще на серваках частеенько лялих стоит, ибо его админить проще виндов. TY>нуну. Ты наверное точно админ и специалист в области и Windows и Linux
Здравствуйте, Sinclair, Вы писали:
S>Все прекрасно наблюдается. Если ты посмотришь на экспериментальные компиляторы, анализаторы, и вообще на чем пишет народ в околокомпиляторной тусовке, то это никак не С++. Предпочитают играть с ML, F# и прочей функциональщиной. Вот уже потом, при доведении до коммерческого статуса, начинается мучительное переписывание на неуправляемые императивные языки. Начинается по разным причинам, не последняя из которых — отсутствие промышленного фукционально-ориентированного языка.
Тут более сильные утверждения звучали. Такие что объем работы по написанию более-менее сложного языка будет на ML подобных языках на порядок меньше чем на C++. Это явное заблуждение.
Здравствуйте, FR, Вы писали: FR>Тут более сильные утверждения звучали. Такие что объем работы по написанию более-менее сложного языка будет на ML подобных языках на порядок меньше чем на C++. Это явное заблуждение.
Это явная правда. Прототипирование компиляторов реально сложных языков делается ФП ровно потому, что это на порядок быстрее. Накидывают за пару месяцев proof of concept, а потом года три утаптывают этот concept в MSVC, потому как политика партии.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, FR, Вы писали: FR>>Тут более сильные утверждения звучали. Такие что объем работы по написанию более-менее сложного языка будет на ML подобных языках на порядок меньше чем на C++. Это явное заблуждение. S>Это явная правда. Прототипирование компиляторов реально сложных языков делается ФП ровно потому, что это на порядок быстрее. Накидывают за пару месяцев proof of concept, а потом года три утаптывают этот concept в MSVC, потому как политика партии.
С прототипированием согласен, любой высокоуровневый язык его сильно ускоряет. Но вот дальнейшая разработка от этого существенно не ускорится.
Просто представь себе что у тебя заказ на написания компилятора C++ на немерли. И большая часть преимуществ которая на самом деле есть при написании компилятора немерли на немерли (а главное из них не ПМ а удобство расширения компилятора). Это очень похоже на Форт системы которые легко доводятся до очень высокоуровневых DSL но на них так же непросто как ина других языках писать не форт компиляторы.
А для тех кто сам этим занимался сомнений никаких нет. Вот почитай, хотя бы это сообщение:
