Спасибо за информацию. Значит, Вирт не автор этого исследования. Буду знать.
Кстати, я не вижу на картинке Лиспа, у которого то ли 2, то ли 3 грамматических правила…
Насчет языков: О Харухи, как я с вами согласен! Это настолько разные концепции, что пришивать пятую ногу к существующим языкам — значит ограничивать возможности GPU. Именно поэтому я говорю, что нужен новый язык для GPU, отстаньте вы от старичка Фортрана. Но рынок уже рассудил, что лучше пускать отдельные циклы на GPU, а не пытаться переписать всю программу на новом языке. И это можно понять. Таков мир, к сожалению.
Прошу прощения, но я не согласен с автором, хотя и поддерживаю некоторые его аргументы.
При всем уважении в профессору Вирту, его оценка сложности языков программирования основана на правилах грамматики, то есть, говоря по-простому, оценивает лишь синтаксис, не затрагивая семантику. Однако, проблема в том, что семантику сложно, а в большинстве случаев невозможно оценить в цифрах. Я уже не говорю о том, что само понятие «семантика» _немного_ расплывчато. Тем не менее, я следую понятию семантики из википедии: ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%BC%D0%B0%D0%BD%D1%82%D0%B8%D0%BA%D0%B0_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29
Таким образом, семантически следующие конструкции эквивалентны (JS):
1) for(var i in [1,2,3]) { sum += 2*i }
2) [1,2,3].map(function(a) {return 2*a}).reduce(function(a, b) { return a+b }, 0)
Так же как и следуюшие (С++):
1) for (int i = 0; i < vec.size(); i++) { sum += i*2 }
2) for (auto i = vec.begin(); i != vec.end(); ++i) { sum += *i * 2 }
3) std::for_each(vec.begin(), vec.end(), [](int i) { sum += i*2 }
Однако, в С++, результирующий ассемблерный код будет одинаков (в релиз версии). Что в случае JS? Ээээ. Ну… В V8 уж точно нет. Но я сейчас не об этом (и да, я утрирую).
Так вот. Какая разница, сколько синтаксических фич у языка!? Главное, какая у языка семантика, то есть сколько различных смыслов можно описать на языке. И если у языка столько различных семантических фич, сколько, например, у С++, то он будет сложен, но и областей применения у него будет больше, чем, например, у JS.
Другой вопрос, на рассмотрение которого, у сожалению, формат комментария маловат — это как раз области применения. Я покручу у виска, если кто-либо всерьез предложит программировать микроконтроллеры на JS (такое уже было трижды на моей памяти), или будет парсить сайты (один раз, то есть производительность не важна) на чистом C. Кроме того, области применения постоянно возникают и исчезают. Кто десять лет назад задумывался о вычислениях на GPU? Но сейчас это реальность. И где язык, заточенный под GPU? Есть, конечно, попытки пришить собаке пятую ногу, например, С с новыми ключевыми словами и несовместимый ни с одним существующим компилятором, Фортран, С и С++ с новыми прагмами, но ни одного нового языка.
А теперь у меня вопрос к вам, автор. Как можно добавить поддержку GPU в Оберон, не усложняя его? Или она уже есть?
В чем же проблема как тру С++ разработчику написать функцию с именем вроде _Z7MyClass7MyMethod, которая принимает MyClass* в качестве первого параметра?
На рутрекере была эпохальная раздача с сотней ранобэ, никак не могу найти…
К сожалению, я не могу найти нормальную читалку под линукс или андроид и поэтому читаю только печатный вариант с амазона. К тому же, по моему опыту, большая часть оцифрованных ранобэ — это сканы, что не располагает к чтению, особенно на начальном этапе.
А если что-нибудь попроще и в txt, то попробуйте ハリー・ポッター: rutracker.org/forum/viewtopic.php?t=1660037. Серьезно.
В случае JIT я никакого зрелого проекта не знаю, к сожалению. Здесь уж кто во что горазд. Могу порекомендовать незрелый (см. ниже).
Для AOT я с вами согласен, создание фронтенда для LLVM проще, чем для gcc, но стоит один раз разобраться (https://gcc.gnu.org/wiki/WritingANewFrontEnd) и вам предоставятся огромные возможности gcc. Например, поддержка распарелелливания на GPU «из коробки» с помощью аннотаций (в LLVM вам придется явно генерировать такой код), лучшая кодогенерация, и т. п. Если вас не пугает статус альфа, то вот вам еще и JIT: gcc.gnu.org/wiki/JIT.
На мой взгляд, gcc гораздо удобнее для расширения. Что в LLVM приходится делать на интринсиках, в gcc можно делать еще добавлением нового типа ноды дерева AST. Кстати, это, имхо, еще один плюс gcc: вам не нужно генерировать SSA форму, только AST, все делает компилятор сам.
Разумеется, у gcc есть и минусы. И самые главные из них, на мой взгляд — очень высокий порог входа и очень скудная документация.
Кстати, я не вижу на картинке Лиспа, у которого то ли 2, то ли 3 грамматических правила…
Насчет языков: О Харухи, как я с вами согласен! Это настолько разные концепции, что пришивать пятую ногу к существующим языкам — значит ограничивать возможности GPU. Именно поэтому я говорю, что нужен новый язык для GPU, отстаньте вы от старичка Фортрана. Но рынок уже рассудил, что лучше пускать отдельные циклы на GPU, а не пытаться переписать всю программу на новом языке. И это можно понять. Таков мир, к сожалению.
При всем уважении в профессору Вирту, его оценка сложности языков программирования основана на правилах грамматики, то есть, говоря по-простому, оценивает лишь синтаксис, не затрагивая семантику. Однако, проблема в том, что семантику сложно, а в большинстве случаев невозможно оценить в цифрах. Я уже не говорю о том, что само понятие «семантика» _немного_ расплывчато. Тем не менее, я следую понятию семантики из википедии: ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%BC%D0%B0%D0%BD%D1%82%D0%B8%D0%BA%D0%B0_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29
Таким образом, семантически следующие конструкции эквивалентны (JS):
1) for(var i in [1,2,3]) { sum += 2*i }
2) [1,2,3].map(function(a) {return 2*a}).reduce(function(a, b) { return a+b }, 0)
Так же как и следуюшие (С++):
1) for (int i = 0; i < vec.size(); i++) { sum += i*2 }
2) for (auto i = vec.begin(); i != vec.end(); ++i) { sum += *i * 2 }
3) std::for_each(vec.begin(), vec.end(), [](int i) { sum += i*2 }
Однако, в С++, результирующий ассемблерный код будет одинаков (в релиз версии). Что в случае JS? Ээээ. Ну… В V8 уж точно нет. Но я сейчас не об этом (и да, я утрирую).
Так вот. Какая разница, сколько синтаксических фич у языка!? Главное, какая у языка семантика, то есть сколько различных смыслов можно описать на языке. И если у языка столько различных семантических фич, сколько, например, у С++, то он будет сложен, но и областей применения у него будет больше, чем, например, у JS.
Другой вопрос, на рассмотрение которого, у сожалению, формат комментария маловат — это как раз области применения. Я покручу у виска, если кто-либо всерьез предложит программировать микроконтроллеры на JS (такое уже было трижды на моей памяти), или будет парсить сайты (один раз, то есть производительность не важна) на чистом C. Кроме того, области применения постоянно возникают и исчезают. Кто десять лет назад задумывался о вычислениях на GPU? Но сейчас это реальность. И где язык, заточенный под GPU? Есть, конечно, попытки пришить собаке пятую ногу, например, С с новыми ключевыми словами и несовместимый ни с одним существующим компилятором, Фортран, С и С++ с новыми прагмами, но ни одного нового языка.
А теперь у меня вопрос к вам, автор. Как можно добавить поддержку GPU в Оберон, не усложняя его? Или она уже есть?
Оффтоп: мне любопытно, как кланговцы будут пилить совместимость с MSVС и, как они запилят, хотелось почитать их код.
Тупо транслитерация с лунного.
К сожалению, я не могу найти нормальную читалку под линукс или андроид и поэтому читаю только печатный вариант с амазона. К тому же, по моему опыту, большая часть оцифрованных ранобэ — это сканы, что не располагает к чтению, особенно на начальном этапе.
А если что-нибудь попроще и в txt, то попробуйте ハリー・ポッター: rutracker.org/forum/viewtopic.php?t=1660037. Серьезно.
Для AOT я с вами согласен, создание фронтенда для LLVM проще, чем для gcc, но стоит один раз разобраться (https://gcc.gnu.org/wiki/WritingANewFrontEnd) и вам предоставятся огромные возможности gcc. Например, поддержка распарелелливания на GPU «из коробки» с помощью аннотаций (в LLVM вам придется явно генерировать такой код), лучшая кодогенерация, и т. п. Если вас не пугает статус альфа, то вот вам еще и JIT: gcc.gnu.org/wiki/JIT.
На мой взгляд, gcc гораздо удобнее для расширения. Что в LLVM приходится делать на интринсиках, в gcc можно делать еще добавлением нового типа ноды дерева AST. Кстати, это, имхо, еще один плюс gcc: вам не нужно генерировать SSA форму, только AST, все делает компилятор сам.
Разумеется, у gcc есть и минусы. И самые главные из них, на мой взгляд — очень высокий порог входа и очень скудная документация.