зависит от того, что для вас эффективный компилятор
вот я хочу компилятор, который мог бы анализировать код на предмет незавершаемости (логических ошибок, могущих привести к бесконечному циклу для некоторых input'ов)
и это только самый простой пример (самое актуальное это, наверное, анализ worst-case execution time для автоматической мемоизации и замены ленивости на энергичность)
это невозможно в Тьюринг-полном языке
решение есть программировать на ограниченных языках, где эти проблемы разрешимы в общем случае, но мне пока неизвестны ни примеры, ни то, насколько это могло бы быть удобно
я про Haskell и ссылочную прозрачность и не говорил
в Erlang код не параллелится per function, просто там процесс и способы их коммуникации это примитивы языка, что и обеспечивает целостность программы, в отличие от низкоуровневого C++
цитата из документации к malloc в майкрософтской реализации:
By default, malloc does not call the new handler routine on failure to allocate memory
это значит, что семантически malloc в C++ не отличается от malloc в C
Тогда я пишу письма всем (ВСЕМ!) другим процессам
ну если вы хотите в realtime отслеживать доступность всех мест в самолёте со всех терминалов то, да, тут сервер будет слать сообщения клиентам об изменениях
Мы положили ее туда 45 минут назад!". Я уныло нажимаю "обновить"
мы друг друга не поняли
распределенные БД вроде mnesia обычно используются для ускорения доступа и отказоустойчивости в составе высокопроизводительного кластера, там транзакция никак не может идти 45 минут
>> Да. C заметно быстрее чем C++, если в последнем использовать ООП возможности.
какие такие "ООП возможности"? давайте не будем пространно рассуждать про возможности, а поговорим о конкретных вещах, которые якобы делают C++ медленнее, чем C
ООП возможности это неявная передача контекста this в функцию? так это ничем не отличается от простой передачи аргумента
это, может быть, виртуальные функции? то же самое делается и в C повсеместно указателями на функции
а вдруг, это наследование? так нет же наследование это просто аггрегация реализации
что-то не видать, где это "C заметно быстрее чем C++"
>> Класс задач для C++ и С заметно более широк.
это и не оспаривалось
процитирую вас еще раз: для некоторого класса задач
тавтология
>> Вот именно. Делают эффективные языки, с учётом всех физически присутвующих компромиссов.
опять тавтология
не проще ли прямо сказать: "да, я был неправ, это не неудачники, не продавшие ни одной строчки кода, могущие лишь пространно рассуждать", ы?
>> Не привносите умных слов без необходимости. Тавталогия там какая-то... :-)
если вы не понимаете, что такое тавтология, то незачем демонстрировать всему миру собственную безграмотность
>> Быстрее здесь в узком смысле - программа быстрее
вот и называйте вещи своими именами программа быстрее, не язык
правильно будет так: "программа на C++, использующая полиморфизм будет медленнее, чем программа на C, не использующая полиморфизм"
вот только это несколько странное утверждение, поскольку, если полиморфизм нужен то вы реализуете его и в C (через явную косвенность указатели на функции), и ничем быстрее, чем в C++ это не будет
>> Код на С++ медленнее по очень простой причине - полиморфизм требует во время исполнения контекстного выбора вызываемой подпрограммы
вас кто-то заставляет использовать полиморфизм?
вы ведь в курсе, наверное, что C это подмножество C++ (ну если не рассматривать форкнутый C99)
мне очень интересно, как язык может быть "быстрее"
>> потому что говорили, что вот, сейчас Lisp и Prolog всех вытеснят, и до искуственного интеллекта рукой подать
да и языки ни при чём тут по большому счёту были тогда.. просто был какой-то хайп по поводу моделирования знаний и логики через rule engines, казалось, что вот-вот и будет ИИ
>> Они вообще не очень-то сильны как компиляторы в машинный код, а тем более как распараллеливающие компиляторы.
это верно, как компиляторы в эффективный машинный код они сегодня тупое говно
здесь есть 2 проблемы:
1. академикам влом реализовывать алгоритмы из своих PhD диссертаций в реальных компиляторах (попробуйте разобраться в сорцах GHC какого-нибудь да там чёрт ногу сломит), у них просто нет мотивации никакой этого делать, им за это никто не заплатит
2. фундаментальная математическая проблема неразрешимость программ в общем случае, что следует из теоремы Гёделя о неполноте это означает, что "серебряную пулю" никто и никогда не создаст
>> Считайте меня тупым, если Вам так удобнее - но я убедился, что голова меньше болит при написании обычного кода на "C".
когда у меня голова болит за производительность и я беру в руки C
потому что если мне нужно решать задачу в терминах архитектуры PC, то глупо использовать для этого абстракцию над ней
>> С моей личной точки зрения больший интерес представляют языки с lazy evaluation
да, ленивая семантика с каррингом дает просто невообразимую выразительную мощь
плохо лишь исполнение компиляторы не умеют адекватно превращать ленивость в энергичность, поскольку для этого требуется анализ производительности кода в общем случае это неразрешимо
в таком анализе может помочь он-лайн профилирование (т.е. сбор статистики с реально работающего кода), но, AFAIK, ни один компилятор Haskell этого не умеет
поэтому чтобы написать производительную программу на Haskell приходится везде вручную расставлять хинты для энергичного исполнения код превращается в говно из-за мельтешащих везде хинтов :((
>> никакого прироста в производительности Erlang не даст
на Erlang'е распределенную систему сделать в разы проще, чем на C++
вы понимаете, что железо сегодня стоит дешевле, чем работа квалифицированых C++ программистов, обеспечивающих отсутствие в необходимости покупать это железо?
>>Так что в итоге это не даёт каких-то особых преимуществ перед преимуществ перед хорошо написанным кодом
.. а так же перед хорошо написанным кодом на x86-опкодах, угу
давайте не будем толочь воду в ступе
мы же здесь не про сферических коней в вакууме есть Эрланг, на нём хорошо распараллеленый код писать в разы проще, чем на C++, это и есть основной concern
>> чем на время компиляции.
при чём тут время компиляции? я говорил про то, что задача автоматического параллелизма разрешима в C++ лишь в частных случаях, а в Erlang - в общем
>> Всё-таки C++ и Erlang вроде бы компилируемые языки
интерпретируемый язык или компилируемый это очень странный и абсолютно некорректный критерий оценки, компиляция это преобразование кода, и "интерпретируемые" и "компилируемые" программы проходят через длинные цепочки преобразований до фактического исполнения их железом
>> P.S. Я не против этого языка, но не нужно же считать его панацеей.
забавно, покажите мне место в статье или в комментариях к ней, где утверждается: "Эрланг это панацея, ребяты!"
>> то как при работа с ним поступают в случае, если программа должна записать в разные места одного файла данные, которые получаются при работа разных потоков?
делаете процесс, принимающий сообщение "записать кусок байтов в файл"
все остальные процессы посылают сообщение с байтами этому процессу
вот я использую jQuery и Yahoo UI library библиотеки для яваскрипта, и тоже ничем не отличается
флеш является частью браузера, пусть и опциональной
точно так же можно сказать javascript не является частью браузера, ведь его можно отключить!
короче, ответьте на вопрос чем для программиста десктоп-приложения отличаются от веб-приложений?
я разницы не вижу как программировал раньше для десктопа, так сейчас и для веба программирую
вот я хочу компилятор, который мог бы анализировать код на предмет незавершаемости (логических ошибок, могущих привести к бесконечному циклу для некоторых input'ов)
и это только самый простой пример (самое актуальное это, наверное, анализ worst-case execution time для автоматической мемоизации и замены ленивости на энергичность)
это невозможно в Тьюринг-полном языке
решение есть программировать на ограниченных языках, где эти проблемы разрешимы в общем случае, но мне пока неизвестны ни примеры, ни то, насколько это могло бы быть удобно
в Erlang код не параллелится per function, просто там процесс и способы их коммуникации это примитивы языка, что и обеспечивает целостность программы, в отличие от низкоуровневого C++
т.е. если у вас в Erlang будет миллион процессов все 4 ядра вашего Core Quad будут полностью загружены ими
это и есть scalability когда программа не привязана к кол-ву ядер/машин на которых физически исполняется код
>> Вы не хотите продавать данный движок загрузки на сайт?
об этом мы не думали, поскольку тот код, что есть сейчас вряд ли целесообразен для применения где-то, кроме сферы image hosting
мы работаем над интеграционными решениями для блогов и форумов они будут бесплатными и изображения будут хоститься у нас
By default, malloc does not call the new handler routine on failure to allocate memory
это значит, что семантически malloc в C++ не отличается от malloc в C
Тогда я пишу письма всем (ВСЕМ!) другим процессам
ну если вы хотите в realtime отслеживать доступность всех мест в самолёте со всех терминалов то, да, тут сервер будет слать сообщения клиентам об изменениях
Мы положили ее туда 45 минут назад!". Я уныло нажимаю "обновить"
мы друг друга не поняли
распределенные БД вроде mnesia обычно используются для ускорения доступа и отказоустойчивости в составе высокопроизводительного кластера, там транзакция никак не может идти 45 минут
не переживайте так
какие такие "ООП возможности"? давайте не будем пространно рассуждать про возможности, а поговорим о конкретных вещах, которые якобы делают C++ медленнее, чем C
ООП возможности это неявная передача контекста this в функцию? так это ничем не отличается от простой передачи аргумента
это, может быть, виртуальные функции? то же самое делается и в C повсеместно указателями на функции
а вдруг, это наследование? так нет же наследование это просто аггрегация реализации
что-то не видать, где это "C заметно быстрее чем C++"
>> Класс задач для C++ и С заметно более широк.
это и не оспаривалось
процитирую вас еще раз: для некоторого класса задач
тавтология
>> Вот именно. Делают эффективные языки, с учётом всех физически присутвующих компромиссов.
опять тавтология
не проще ли прямо сказать: "да, я был неправ, это не неудачники, не продавшие ни одной строчки кода, могущие лишь пространно рассуждать", ы?
>> Не привносите умных слов без необходимости. Тавталогия там какая-то... :-)
если вы не понимаете, что такое тавтология, то незачем демонстрировать всему миру собственную безграмотность
угу, особенно про "С быстрее C++"
>>не продавших ни строчки собственного кода, но гораздых долго и пространно рассуждать о теоретических достоинствах академических языков
just FYI, эти "академические чайники" разработчики Haskell работают в Microsoft и делают для вас сегодня C# и VisualBasic
не загоняйтесь
>> Просто отдельная интересная вещь, логически удобная для некоторого класса задач.
.. как и C, и любой другой язык и технология, упомянутые на этой странице хабра
вы только что сказали тавтологию к чему это?
вот и называйте вещи своими именами программа быстрее, не язык
правильно будет так: "программа на C++, использующая полиморфизм будет медленнее, чем программа на C, не использующая полиморфизм"
вот только это несколько странное утверждение, поскольку, если полиморфизм нужен то вы реализуете его и в C (через явную косвенность указатели на функции), и ничем быстрее, чем в C++ это не будет
с каких пор malloc в C++ начал бросать исключения?
>> Как это реализовать, используя ассинхронные сообщения и не имея общей памяти
общая память в данном случае есть, просто чтение и запись в/из неё транзакционные, транзакция это и есть посылка сообщения
обычно в Erlang для таких задач используют распределенную БД mnesia (тесно интегрированую в Erlang)
а SMS-месседжинг встроен в OS телефона
поэтому никакие аськи пока что не заменят SMS
даже и не собираюсь выяснять что-то на сферических конях в вакууме
и ежу ясно, что код на C получится эффективнее, т.к. с ним вы практически напрямую программируете железо, а с Erlang контролем над железа у вас ноль
если не трудно
вас кто-то заставляет использовать полиморфизм?
вы ведь в курсе, наверное, что C это подмножество C++ (ну если не рассматривать форкнутый C99)
мне очень интересно, как язык может быть "быстрее"
>> потому что говорили, что вот, сейчас Lisp и Prolog всех вытеснят, и до искуственного интеллекта рукой подать
да и языки ни при чём тут по большому счёту были тогда.. просто был какой-то хайп по поводу моделирования знаний и логики через rule engines, казалось, что вот-вот и будет ИИ
это верно, как компиляторы в эффективный машинный код они сегодня тупое говно
здесь есть 2 проблемы:
1. академикам влом реализовывать алгоритмы из своих PhD диссертаций в реальных компиляторах (попробуйте разобраться в сорцах GHC какого-нибудь да там чёрт ногу сломит), у них просто нет мотивации никакой этого делать, им за это никто не заплатит
2. фундаментальная математическая проблема неразрешимость программ в общем случае, что следует из теоремы Гёделя о неполноте это означает, что "серебряную пулю" никто и никогда не создаст
>> Считайте меня тупым, если Вам так удобнее - но я убедился, что голова меньше болит при написании обычного кода на "C".
когда у меня голова болит за производительность и я беру в руки C
потому что если мне нужно решать задачу в терминах архитектуры PC, то глупо использовать для этого абстракцию над ней
да, ленивая семантика с каррингом дает просто невообразимую выразительную мощь
плохо лишь исполнение компиляторы не умеют адекватно превращать ленивость в энергичность, поскольку для этого требуется анализ производительности кода в общем случае это неразрешимо
в таком анализе может помочь он-лайн профилирование (т.е. сбор статистики с реально работающего кода), но, AFAIK, ни один компилятор Haskell этого не умеет
поэтому чтобы написать производительную программу на Haskell приходится везде вручную расставлять хинты для энергичного исполнения код превращается в говно из-за мельтешащих везде хинтов :((
на Erlang'е распределенную систему сделать в разы проще, чем на C++
вы понимаете, что железо сегодня стоит дешевле, чем работа квалифицированых C++ программистов, обеспечивающих отсутствие в необходимости покупать это железо?
.. а так же перед хорошо написанным кодом на x86-опкодах, угу
давайте не будем толочь воду в ступе
мы же здесь не про сферических коней в вакууме есть Эрланг, на нём хорошо распараллеленый код писать в разы проще, чем на C++, это и есть основной concern
>> чем на время компиляции.
при чём тут время компиляции? я говорил про то, что задача автоматического параллелизма разрешима в C++ лишь в частных случаях, а в Erlang - в общем
>> Всё-таки C++ и Erlang вроде бы компилируемые языки
интерпретируемый язык или компилируемый это очень странный и абсолютно некорректный критерий оценки, компиляция это преобразование кода, и "интерпретируемые" и "компилируемые" программы проходят через длинные цепочки преобразований до фактического исполнения их железом
>> P.S. Я не против этого языка, но не нужно же считать его панацеей.
забавно, покажите мне место в статье или в комментариях к ней, где утверждается: "Эрланг это панацея, ребяты!"
>> то как при работа с ним поступают в случае, если программа должна записать в разные места одного файла данные, которые получаются при работа разных потоков?
делаете процесс, принимающий сообщение "записать кусок байтов в файл"
все остальные процессы посылают сообщение с байтами этому процессу