История изменений
Исправление SZT, (текущая версия) :
Параллельная обработка, например.
Параллельная обработка чего? Мне нужен конкретный пример задачи, в котором хаскель на параллельной обработке обгонет С, при том чтобы на С нельзя было впринципе написать кода, который бы обогнал код на хаскеле(рассматриваются актуальные версии компиляторов С и хаскель. Ассемблерные вставки и FFI не рассматриваются. Целевая архитектура x86-64. OS - GNU/Linux).
Есть примеры задач, где даже Java, прости хоспади, быстрее C.
Насчет Java я еще могу поверить. Там в hotspot-е есть адаптивная оптимизация, когда ява-машина динамически перекомпилирует(адаптирует) код исходя из результатов рантайм-профилирования. Но разве в GHC есть нечто подобное?
Современный конпеляторы генерят куда более вменяемый ассемблерный код, чем ты.
Нет. Могу привести конкретный пример невменяемого кода, сгенерированного компилятором см. http://gcc.1065356.n5.nabble.com/Ways-to-fill-the-stack-td912561.html . Багрепорт -> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152
Да, я согласен что во многих случаях вручную переписывая код из С на ассемблер, я напишу код хуже, чем это сделает компилятор С. Тогда такой вопрос. Может ли компилятор для нетривиальных случаев сгенерировать такой код на ассемблере, чтобы человек, глядя на него, был бы не в состоянии его улучшить?
Практика показывает, что компиляторы не в сосотянии сами по себе(без специальных подсказок-интринсиков) генерировать эффективный код. Например http://blog.lexa.ru/2012/12/26/opyat_o_sovremennykh_cpu.html http://thedeemon.livejournal.com/49226.html .
Так что ассемблерные вставки с изрядной долей вероятности сделаю только хуже.
Есть FFmpeg с кучей кода на ассемблере для разных архитектур https://github.com/FFmpeg/FFmpeg/search?l=gas&q=&utf8=✓ и еще libjpeg-turbo например. Так что смысл писать/оптимизировать на ассемблере есть.
Исходная версия SZT, :
Параллельная обработка, например.
Параллельная обработка чего? Мне нужен конкретный пример задачи, в котором хаскель на параллельной обработке обгонет С, при том чтобы на С нельзя было впринципе написать кода, который бы обогнал код на хаскеле(рассматриваются актуальные версии компиляторов С и хаскель. Ассемблерные вставки и FFI не рассматриваются. Целевая архитектура x86-64. OS - GNU/Linux).
Есть примеры задач, где даже Java, прости хоспади, быстрее C.
Насчет Java я еще могу поверить. Там в hotspot-е есть адаптивная оптимизация, когда ява-машина динамически перекомпилирует(адаптирует) код исходя из результатов рантайм-профилирования. Но разве в GHC есть нечто подобное?
Современный конпеляторы генерят куда более вменяемый ассемблерный код, чем ты.
Нет. Могу привести конкретный пример невменяемого кода, сгенерированного компилятором см. http://gcc.1065356.n5.nabble.com/Ways-to-fill-the-stack-td912561.html . Багрепорт -> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152
Да, я согласен что во многих случаях вручную переписывая код из С на ассемблер, я напишу код хуже, чем это сделает компилятор С. Тогда такой вопрос. Может ли компилятор для нетривиальных случаев сгенерировать такой код на ассемблере, чтобы человек, глядя на него, был бы не в состоянии его улучшить?
Практика показывает, что компиляторы не в сосотянии сами по себе(без специальных подсказок-интринсиков) генерировать эффективный код. Например http://blog.lexa.ru/2012/12/26/opyat_o_sovremennykh_cpu.html http://thedeemon.livejournal.com/49226.html . Еще есть FFmpeg с кучей кода на ассемблере для разных архитектур https://github.com/FFmpeg/FFmpeg/search?l=gas&q=&utf8=✓ и еще libjpeg-turbo например. Так что смысл писать/оптимизировать на ассемблере есть.