Как программист на Си уделал Хаскелистов на их поле

Клиника. Это не программист, это задрот, странно, что он не чистом асме писал, а ассемблер высокого уровня взял.

На каком поле? Ты ещё один прыщавый неадекват?

> Клиника. Это не программист, это задрот, странно, что он не чистом асме писал

Ты так не смог бы.

Справедливости ради стоит заметить, что эти аспекты никоим образом не связаны с С как таковым или компилятором GCC, они связаны с исконным для С предоставлением доступа к низлежащему аппаратному обеспечению и ОС

Моя реализация примерно в 4 раза больше реализаций на Haskell и Erlang

:( Да уж... Действительно, а почему не на асме?

Естественно. Я никогда не интересовался архитектурой и ассемблером, максимум моих сил - небольшую вставку на асме сделать. И что? Завтра поменяют проц на какой спарк и где его суперскорость будет?

Побитый сишниками хаскеллист?

> Побитый сишниками хаскеллист?

Я хаскелль не знаю и знать не хочу.

> На каком поле? Ты ещё один прыщавый неадекват?

Известно на каком, чего-нибудь параллельное запрограммировать, как пример здесь задача о хамелеонах.

Можно сколько угодно говорить, что размер исходников больше и прочее ля-ля, но 0.72 секунды вместо 4.59 вполне того могут стоить.

Эпичнее всего, конечно слил Питон. И вообще из этих результатов видно почему несмотря на рост скоростей проги становятся все тормознее и тормознее.

>чего-нибудь параллельное запрограммировать

покажи мне пример прикладной задачи, в которой пареллелизация должна достигаться такой ценой

> Я никогда не интересовался архитектурой и ассемблером, максимум моих сил - небольшую вставку на асме сделать. И что?

И не следует неуважительно отзываться о тех, кто этим интересовался.

> Завтра поменяют проц на какой спарк и где его суперскорость будет?

Через некоторое (вряд ли большое) время он напишет такую же симпатичную программешку и для SPARC.

> покажи мне пример прикладной задачи, в которой пареллелизация должна достигаться такой ценой

Например, убыстрение решения системы интегральных уравнений в томографии вполне способно съэкономить больницам десятки, если не сотни килобаксов на девайс.

> покажи мне пример прикладной задачи, в которой пареллелизация должна достигаться такой ценой

Какой "такой", что за трагизм? %)Ты хочешь сказать, что ни при каких условиях, никогда 7-кратный выигрыш в скорости не стоит ручной реализации спинлока?

> Известно на каком, чего-нибудь параллельное запрограммировать, как пример здесь задача о хамелеонах.

В The Swiss Federal Institute of Technology of Lausanne считалки на математике (mathematica) разбрасывают кондором (condor). И радуются, что математиковскую считалку можно так легко разбросать на класетр, не тратя своё драгоценное исследовательское время на рутину осточертевшего траха к низкоуровневым языком, не приспособленным для решения исследовательских задач.

Никто никого не заставляет тратить время на рутину, если можно что-то раскидать на кластер. Но бывают ситуации, когда задача слишком серьезная и ее приходится оптимизировать.

>Какой "такой", что за трагизм?

в большинстве случаев сценарий будет выглядеть так: есть готовое решение, его надо распараллелить; либо условием будет эффективное использование всех доступных ядер, например

>Ты хочешь сказать, что ни при каких условиях, никогда 7-кратный выигрыш в скорости не стоит ручной реализации спинлока?

есть такие условия, несомненно. однако они описывают частный и очень специальный случай

> Но бывают ситуации, когда задача слишком серьезная и ее приходится оптимизировать.

Отлично! Но если вам говорят, что Haskell Curry лично стоит за спиной и держит ствол у вашего затылка, мешая использовать подходящее средство для конкретной задачи - не верьте, вас гнусно обманывают.

Но предварительно проверить концепт на самом выразительном доступном языке никогда не помешает.

>Например, убыстрение решения системы интегральных уравнений в томографии вполне способно съэкономить больницам десятки, если не сотни килобаксов на девайс.

какой девайс, например?

к слову - у Bruker (http://www.bruker.com/product.html), например, всё ПО для ЯМР-устройств на Tcl и Java. предлагаю тебе написать им, насколько они неправы

>Но бывают ситуации, когда задача слишком серьезная и ее приходится оптимизировать.

если возникает необходимость оптимизировать на уровне ОС - нужен язык уровня ОС; казалось бы, при чём тут Haskell?

> Естественно. Я никогда не интересовался архитектурой и ассемблером, максимум моих сил - небольшую вставку на асме сделать.

Т.е. ты какбе не задрот, а классный парень, да?

> казалось бы, при чём тут Haskell?

Полагаю, автор ни Хаскелль в частности, ни ФП в целом, ни область их применения в принципе не знает, но поддался модному тренду их обсирания. Особенно умиляет: "Питон в 220 раз медленнее Си", - какое откровение...

>> Ты хочешь сказать, что ни при каких условиях, никогда 7-кратный выигрыш в скорости не стоит ручной реализации спинлока?

> есть такие условия, несомненно.

О чем и речь.Никто же и не говорит, что сабжевая эквилибристика является нормой жизни.

И кстати, странно, что никто не обратил внимание эквилибриста на то, что sched_yield является noop на Linux. Или я что-то пропустил, и sched_yield снова в строю?

> И кстати, странно, что никто не обратил внимание эквилибриста на то, что sched_yield является noop на Linux. Или я что-то пропустил, и sched_yield снова в строю?

Оно и на стором O(1) шедуллере смысла не несло, если каждый числодробильный тред на своей корке сидит.

>Через некоторое (вряд ли большое) время он напишет такую же симпатичную программешку и для SPARC.

Только в некоторых краевых условиях она себя будет вести себя немного не так. Смысл высокого уровня наверно всеже не в простоте написания кода, а в реюзабельности оного.

> к слову - у Bruker (http://www.bruker.com/product.html), например, всё ПО для ЯМР-устройств на Tcl и Java. предлагаю тебе написать им, насколько они неправы

Не знаю, что там у них за софт на жабе, может обвязка какая, а может разводят покупателей на бабки неоптимизированным софтом, но факт, что расчет 3-мерного изображения в медицинской томографии до сих пор требует нехилых и совсем неписюковых вычислительных ресурсов.

> но поддался модному тренду их обсирания

..., then they fight you, ...

8)))

Но фигурное выпиливание лобзиком на скорость, безусловно, красиво.

> Но фигурное выпиливание лобзиком на скорость, безусловно, красиво.

Если автору за это не заплатили, то он только зря увеличил энтропию в припадке повышения ЧСВ. В случае жажды славы лучше полезный оупенсорсный код писать.

Автор да, молодец. Но блин, ведь сабжевый проект (The Computer Language Benchmarks Game) нацелен на сравнение языков в их "родном" применении. А идея автора насчет сродства ядер и стоимости взаимодействия потоков ну никак не относится к свойствам языка C.

Завтра явится ещё один фанатик и реализует туже идею на C++, а послезавтра учтут размер кеша третьего уровня на "эталонной" системе проекта... напоминает те истории с соревнований по плаванью, где на самом деле соревнуются производители плавательных щапочек.

Вот, нашел там, гуляя по ссылкам http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html

Типа, все переходим на Clean =)

Ой. Вот только не надо рассказывать какой отличный софт делает брюкер. Имел счастье пообщаться, более эпичного языка макросов я не видел в жизни. Вылетания на простых макросах - это тоже фигня.

Но там, где надо проводить обсчёт, брюкеровский софт просто нагло врёт, завышая свои результаты, и работает в 5 раз медленнее даже бесплатных конкурентов.

> Завтра поменяют проц на какой спарк и где его суперскорость будет?

Ииии... Не произойдёт ровным счётом ничего. Судя по прилагаемому исходнику -> http://shootout.alioth.debian.org/u32q/benchmark.php?test=chameneosredux&... он практически ни где не вышел "за пределы" и не скатился до грязных трюков. Ergo, его программа, откомпилированная для платформы SPARC, будет стоь же быстра.

Касаемо использования /proc/cpuinfo (что может не понравится "строгим ценителям"), так это не трюк. Уж простите. Вообще-то, ФС /proc сама по себе пришла с Solaris а, во-вторых, он использовал её довольно корректно.

Классный код. +10^6 Автору. Моё почтение.

Посмотрел всю таблицу http://shootout.alioth.debian.org/u32q/fulldata.php?test=chameneosredux&p...

и возникли странные вопросы. Например, этот код раза так в два уступил Хаскелю при N=60000 и 600000 и некоторым другим реализациям тоже. Всех делает он только при очень больших N.

И вообще мне краткость Хаскеля очень понравилась, при не совсем уже отстойной по сравнению с иными языками скорости.

> и600000

gcc - 0.10
Haskell - 0.70, 0.60

вы что-то путаете

>Вот только не надо рассказывать какой отличный софт делает брюкер

говно они делают, я как бы обратного нигде и не утверждал

Сама статья на рсдн.ру кажется толковой и интересной. Только причем здесь "хаскелисты и уделавший их программист на си" непонятно. Предлагаю заигнорить.

http://www.gnu.org/s/libc/manual/html_node/Feature-Test-Macros.html (тут про #define _GNU_SOURCE и что оно значит).

__sync_val_compare_and_swap -- оно и на Sun есть -> http://drizzle.org/doxygen/dc/d51/sun__studio_8h-source.html (для gcc по крайней мере).

Касаемо /proc/cpuinfo, то таки да. Его не будет на *BSD, что поделать, странная там реализоция /proc, но в варианте Автора, оно будет по-шустрее, чем выполнять 'sysctl -a | grep -i CPU | less'.

> Предлагаю заигнорить.

Верно. Ибо не фиг о вкусах, да языках спорить. Толку не будет, IMHO.

>Не знаю, что там у них за софт на жабе

всё подряд у них там на жабе

>расчет 3-мерного изображения в медицинской томографии до сих пор требует нехилых и совсем неписюковых вычислительных ресурсов

кто ж спорит? вот только решение вроде представленного на C - это крайняя мера, которую в промышленных проектах, вообще говоря, не используют. даже в ЯМР

курить sysctl(3) до просветления

<q>Если автору за это не заплатили, то он только зря увеличил энтропию в припадке повышения ЧСВ</q>

Почему бы и нет?..

<q>В случае жажды славы лучше полезный оупенсорсный код писать</q>

Оно куда больше времени займёт.

Ага, уделал. 440 строк кода против 68.

> курить sysctl(3) до просветления

Прошу простить, но марка "нормально_сделаный_/proc" мне нравится больше. А курить я предпочитаю свои... :)

Спасибо за ссылку, на досуге почитаю

> Можно сколько угодно говорить, что размер исходников больше и прочее ля-ля, но 0.72 секунды вместо 4.59 вполне того могут стоить.

Могут стоить того, чтобы переписать отдельно взятый фрагмент. Переводить весь проект на С - вряд ли.

> но факт, что расчет 3-мерного изображения в медицинской томографии до сих пор требует нехилых и совсем неписюковых вычислительных ресурсов.

А вы знаете сколько $ на покупке в наши больницы новых рентгенаппаратов делают? Отож. Торговля фармацевтикой и медтехникой в наши дни по прибыльности превосходит торговлю наркотиками и при этом легитимна

Сбило решение на скале, которое отожрало 156 мб оперативки.

Зато хоть не тормоза, как на питоне

>Только причем здесь "хаскелисты и уделавший их программист на си" непонятно.

А это как в том анекдоте: "Рыбка моя" ... "Граждане, он меня сукой обозвал!!!" =)

Ничего не понял, но зачем там свич вместо таблицы?

Интересно, многие ли из критиков сишный код смотрели? Между тем там всё сделано совершенно адекватно, те кто грят что там всё через опу или прогать не умеют или сырцов не видели. И то и другое глупо.

А разве компилятор не превратит свич в таблицу сам?

Наверное превратит.