Re[12]: Хамелеоны быстрые и очень быстрые
От: thesz Россия http://thesz.livejournal.com
Дата: 23.09.09 12:08
Оценка:
T>>Мне неинтересен [b]конкретно этот[b] эксперимент. У меня своих висящих штуки три или больше, с потенциально гораздо большим выхлопом.
FR>Угу вполне стандартная отмазка

Я уж столько надоказывал и тут и всюду, что имею право на занятия тем, что интересно мне лично.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Хамелеоны быстрые и очень быстрые
От: thesz Россия http://thesz.livejournal.com
Дата: 23.09.09 12:12
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, thesz, Вы писали:


T>>>>Надо достичь баланса в этом самом межпроцессном обмене, а для этого средства есть.

CC>>>Подтверди на практике.
T>>Уже неоднократно, поэтому обратись к кому ещё.
CC>Где можно наглядно ознакомиться с результатами, сравнить?

В разных местах.

T>>Конкретно этот эксперимент мне неинтересен, поскольку у меня своих покрупней и повыгодней есть штуки три.

CC>О да!

Да.

http://thesz.mskhug.ru/svn

Последний из них http://thesz.mskhug.ru/svn/hhdl и он же самый интересный. Это не шутаут, это много прикольней. Это то, чего C++ никогда не сможет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[13]: Хамелеоны быстрые и очень быстрые
От: CreatorCray  
Дата: 23.09.09 12:20
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Мне неинтересен [b]конкретно этот[b] эксперимент. У меня своих висящих штуки три или больше, с потенциально гораздо большим выхлопом.

FR>>Угу вполне стандартная отмазка

T>Я уж столько надоказывал и тут и всюду, что имею право на занятия тем, что интересно мне лично.

Это вторая стандартная отмазка.

Да и в целом, не пристало сеньёру сказав "А" замять тему и таки не говорить "Б".
Тем более делов то: ткнуть носом нубов в те самые примитивы, которых недостаёт хаскель программе чтоб таки догнать сишный код remark-а.
Ну или признать что их на самом деле попросту нет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Хамелеоны быстрые и очень быстрые
От: thesz Россия http://thesz.livejournal.com
Дата: 23.09.09 12:41
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, thesz, Вы писали:


T>>>>Мне неинтересен [b]конкретно этот[b] эксперимент. У меня своих висящих штуки три или больше, с потенциально гораздо большим выхлопом.

FR>>>Угу вполне стандартная отмазка

T>>Я уж столько надоказывал и тут и всюду, что имею право на занятия тем, что интересно мне лично.

CC>Это вторая стандартная отмазка.

CC>Да и в целом, не пристало сеньёру сказав "А" замять тему и таки не говорить "Б".

CC>Тем более делов то: ткнуть носом нубов в те самые примитивы, которых недостаёт хаскель программе чтоб таки догнать сишный код remark-а.

Фиксирование зелёных нитей на процессорах есть. Во что я "ткнул носом нубов" в том сообщении FR.

CC>Ну или признать что их на самом деле попросту нет.


Да мне на это наплевать. Есть они, нет их. Для работы это неважно.

Это важно для раздутия чьей-то (моей, чьей-то ещё, неважно) пиписьки прямо здесь и прямо сейчас, и совершенно не имеет смысла в длительной перспективе.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[13]: Хамелеоны быстрые и очень быстрые
От: remark Россия http://www.1024cores.net/
Дата: 23.09.09 12:47
Оценка: 1 (1) +4
Здравствуйте, thesz, Вы писали:

T>>>Мне неинтересен [b]конкретно этот[b] эксперимент. У меня своих висящих штуки три или больше, с потенциально гораздо большим выхлопом.

FR>>Угу вполне стандартная отмазка

T>Я уж столько надоказывал и тут и всюду, что имею право на занятия тем, что интересно мне лично.


Не вопрос, никто и не говорит, что тебе делать. Просто пока всё, что ты сказал несёт практически нулевую информацию, и складывается впечатление, что интересно тебе переливание из пустого в порожнее. Я тоже могу сказать, что у меня есть программа, которая в 1000 раз быстрее всех ваших, но больше ничего говорить и показывать не буду. Смысл? Это уже попахивает троллингом в техническом форуме. Да, полезное общение в форуме требует времени, это надо понимать, и ИМО сообщать либо хоть какую-то информацию, либо не говорить ничего. Уже мог бы за это время лучше набросать программу (благо там всего-то 65 строчек в программе на Haskell, некоторую часть можно прям оттуда и скопи-пастить), и запостить здесь, а я могу её туда засабмитить (с твоим именем естественно). Делов-то? Тем более, я так понимаю, что для тебя это достаточно тривиальная задача.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: Эрланг
От: remark Россия http://www.1024cores.net/
Дата: 23.09.09 13:08
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>>>Кстати , какие причины столь тормознутой реализации на Erlang? который вроде и был задуман для таких задач ?

E>>Re[2]: Хамелеоны быстрые и очень быстрые
Автор: remark
Дата: 19.09.09
тут написано почему Erlang столь медленный на этой задаче, если я правильно понял, Erlang создает легковесные потоки, которые прекрасно подходят для распараллелевания вычислений, а здесь ботлнек в доступе к разделяемым ресурсам.


M>Так это и поражает, легковесные потоки в Эрланге не являются потоками системы, точнее не обязаны ими быть. Поэтому казалось бы что на подобных задачах Эрланг должен как минимум быть удовлетворительным.


Случай, когда легковесные потоки не являются ядерными, можно видеть здесь:
http://shootout.alioth.debian.org/u32/benchmark.php?test=chameneosredux&amp;lang=all
и тут Эрланг действительно показывает "удовлетворительный" результат в 8.3 секунды

А вот когда легковесные потоки становятся ядерными:
http://shootout.alioth.debian.org/u32q/benchmark.php?test=chameneosredux&amp;lang=all
время уже становится 111 секунд.

Т.е. проблема не в легковесных потоках, проблема в том, что взаимодействие между действительно параллельными потоками очень дорого в Эрланг. Этому будет подвержена любая программа на Эрланг, в которой процессы более-менее часто взаимодействуют между собой. А это как раз то, к чему призывает философия Эрланг — процессы и обмен сообщениями легковесные, так что используйте их по полной.

Кстати, по поводу "удовлетворительного" результата с легковесными потоками. Моя реализация показывает в такой ситуации 10.4 секунды, но каждое взаимодействие есть честное переключение ядерного потока ОС (при ожидании я всегда делаю sched_yield()). Т.е. "легковесные" Эрланг потоки легче честных ядерных потоков всего на 25%, вот и судите несколько они "легковесные", и насколько разница в 25% может порождать другой стиль программирования.

Интересно было бы сделать реализацию на С с использованием fibers. На Windows их переключение примерно раз в 40 быстрее переключения ядерных потоков, т.к. там всего пара десятков инструкций. Насколько я понимаю такую реализацию не примут, т.к. там запрещено использование кооперативного планирования (хотя не понятно, языки с легковесными потоками её используют; а фиберы предоставляет ОС, что практически тоже самое для С). Но будет интересно сравнить "легковесность" с процессами Эрланг.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: Эрланг
От: FR  
Дата: 23.09.09 13:27
Оценка:
Здравствуйте, remark, Вы писали:

R>Кстати, по поводу "удовлетворительного" результата с легковесными потоками. Моя реализация показывает в такой ситуации 10.4 секунды, но каждое взаимодействие есть честное переключение ядерного потока ОС (при ожидании я всегда делаю sched_yield()). Т.е. "легковесные" Эрланг потоки легче честных ядерных потоков всего на 25%, вот и судите несколько они "легковесные", и насколько разница в 25% может порождать другой стиль программирования.


Ну учитывая насколько эрланг медленнее чем си, то очень даже легковесные.
Еще учти что на Эрланге можно без проблем создать десять тысяч потоков, системные же несколько тысяч потоков будут в основном тратить время на переключения друг на друга.
Re[14]: Хамелеоны быстрые и очень быстрые
От: thesz Россия http://thesz.livejournal.com
Дата: 23.09.09 13:30
Оценка:
Здравствуйте, remark, Вы писали:

R>Здравствуйте, thesz, Вы писали:


T>>>>Мне неинтересен [b]конкретно этот[b] эксперимент. У меня своих висящих штуки три или больше, с потенциально гораздо большим выхлопом.

FR>>>Угу вполне стандартная отмазка

T>>Я уж столько надоказывал и тут и всюду, что имею право на занятия тем, что интересно мне лично.


R>Не вопрос, никто и не говорит, что тебе делать.


И завершил тираду, сказав, что мне надо делать.

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

R>Просто пока всё, что ты сказал несёт практически нулевую информацию, и складывается впечатление, что интересно тебе переливание из пустого в порожнее. Я тоже могу сказать, что у меня есть программа, которая в 1000 раз быстрее всех ваших, но больше ничего говорить и показывать не буду. Смысл? Это уже попахивает троллингом в техническом форуме. Да, полезное общение в форуме требует времени, это надо понимать, и ИМО сообщать либо хоть какую-то информацию, либо не говорить ничего. Уже мог бы за это время лучше набросать программу (благо там всего-то 65 строчек в программе на Haskell, некоторую часть можно прям оттуда и скопи-пастить), и запостить здесь, а я могу её туда засабмитить (с твоим именем естественно). Делов-то? Тем более, я так понимаю, что для тебя это достаточно тривиальная задача.


Э, нет.

Я FR показал, что есть примитивы фиксации нитей на процессорах, пусть он теперь ваяет, если захочет.

Или пусть это дело ваяешь ты.

Иными словами, те люди, которым интересна производительность языков программирования.

Если нет желания, то я не против.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Хамелеоны быстрые и очень быстрые
От: remark Россия http://www.1024cores.net/
Дата: 23.09.09 13:46
Оценка: +7
Здравствуйте, thesz, Вы писали:

T>>>Я уж столько надоказывал и тут и всюду, что имею право на занятия тем, что интересно мне лично.

CC>>Это вторая стандартная отмазка.

CC>>Да и в целом, не пристало сеньёру сказав "А" замять тему и таки не говорить "Б".

CC>>Тем более делов то: ткнуть носом нубов в те самые примитивы, которых недостаёт хаскель программе чтоб таки догнать сишный код remark-а.

T>Фиксирование зелёных нитей на процессорах есть. Во что я "ткнул носом нубов" в том сообщении FR.


Этого не достаточно. Все 4 аспекта, который я описал критичны. Если убрать хотя бы 1, то время выполнения увеличивается в разы.
Я думаю, что для Haskell просто не разумно гнаться "один-в-один" за С/С++, и показывать на наличие конкретных аналогичных возможностей. На Haskell это будет реализовывать просто до-другому, поэтому наличие аналогичной возможности не релевантно. Соотв. вопрос — какой производительности может достичь программа на Haskell реализованная "по-другому", по его законам, так сказать?


CC>>Ну или признать что их на самом деле попросту нет.


T>Да мне на это наплевать. Есть они, нет их. Для работы это неважно.

T>Это важно для раздутия чьей-то (моей, чьей-то ещё, неважно) пиписьки прямо здесь и прямо сейчас, и совершенно не имеет смысла в длительной перспективе.

Ну так об этом как раз и есть этот топик. Можно назвать это "переньем пиписьками", можно назвать соревнованием в реализации конкретной задачи.
Если тебе на это наплевать, то зачем и о чём ты тут вообще пишешь? Проходи мимо. Или говори по теме.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[15]: Хамелеоны быстрые и очень быстрые
От: remark Россия http://www.1024cores.net/
Дата: 23.09.09 13:55
Оценка: +1
Здравствуйте, thesz, Вы писали:

T>>>>>Мне неинтересен [b]конкретно этот[b] эксперимент. У меня своих висящих штуки три или больше, с потенциально гораздо большим выхлопом.

FR>>>>Угу вполне стандартная отмазка

T>>>Я уж столько надоказывал и тут и всюду, что имею право на занятия тем, что интересно мне лично.


R>>Не вопрос, никто и не говорит, что тебе делать.


T>И завершил тираду, сказав, что мне надо делать.


Ну хорошо, да, я говорю/призываю людей высказываться по существу и аргументированно. Мне кажется, это вполне разумно.


T>Чтобы два раза не вставать и не разбивать сообщение на две смысловые части, скажу, что я не принуждал тебя к написанию программы упоминанием о "запахе троллинга".


R>>Просто пока всё, что ты сказал несёт практически нулевую информацию, и складывается впечатление, что интересно тебе переливание из пустого в порожнее. Я тоже могу сказать, что у меня есть программа, которая в 1000 раз быстрее всех ваших, но больше ничего говорить и показывать не буду. Смысл? Это уже попахивает троллингом в техническом форуме. Да, полезное общение в форуме требует времени, это надо понимать, и ИМО сообщать либо хоть какую-то информацию, либо не говорить ничего. Уже мог бы за это время лучше набросать программу (благо там всего-то 65 строчек в программе на Haskell, некоторую часть можно прям оттуда и скопи-пастить), и запостить здесь, а я могу её туда засабмитить (с твоим именем естественно). Делов-то? Тем более, я так понимаю, что для тебя это достаточно тривиальная задача.


T>Э, нет.

T>Я FR показал, что есть примитивы фиксации нитей на процессорах, пусть он теперь ваяет, если захочет.
T>Или пусть это дело ваяешь ты.
T>Иными словами, те люди, которым интересна производительность языков программирования.
T>Если нет желания, то я не против.

Если ты говоришь, о том, что можно сделать эффективную реализацию на Haskell, образно выражаясь, "скопировав" реализацию на С, то привязки потоков к ядрам не достаточно. Очень сильно не достаточно. Необходимы все 4 момента, которые я описал, включая определение топологии системы. Отсутствие любого из них увеличит время выполнения в разы.
Так что пока что мы ничего не имеем с твоей стороны.

А то, что есть возможность привязки потоком в процессорам, это и так было ясно, потому что бывшая самая быстрая реализация на Haskell как раз и использует forkOnIO, и за счёт этого и была относительно быстрой.
Так что вот эти 4.5 секунд как раз и есть предел с использованием forkOnIO.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Эрланг
От: remark Россия http://www.1024cores.net/
Дата: 23.09.09 14:20
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, remark, Вы писали:


R>>Кстати, по поводу "удовлетворительного" результата с легковесными потоками. Моя реализация показывает в такой ситуации 10.4 секунды, но каждое взаимодействие есть честное переключение ядерного потока ОС (при ожидании я всегда делаю sched_yield()). Т.е. "легковесные" Эрланг потоки легче честных ядерных потоков всего на 25%, вот и судите несколько они "легковесные", и насколько разница в 25% может порождать другой стиль программирования.


FR>Ну учитывая насколько эрланг медленнее чем си, то очень даже легковесные.


Не понял мысль.
Я говорил о следующем.
Апологеты Эрланг говорят примерно следующее. Переключение ядерных потоков дорого, поэтому вы не можете их использовать в ряде задач, т.к. время переключения будет слишком большим. В Эрланге потоки легковесные и переключаются быстро, поэтому вы можете из использовать для некоторых из тех целей, для который вы не могли это делать с ядерными потоками.
А на практике получается что время переключения практически одинаковое, и если я пишу на С с использованием ядерных потоков, то я могу их использовать точно там же, где на Эрланге я бы использовал легковесные потоки.


FR>Еще учти что на Эрланге можно без проблем создать десять тысяч потоков, системные же несколько тысяч потоков будут в основном тратить время на переключения друг на друга.


Это бесспорно. В плане памяти они легковесные.
Ядерных потоков можно создать, ну там допустим, 32*Количество_процессоров, что бы всё нормально работало. Но O(N) (по размерности входных данных) потоков всё равно создавать нельзя. На Эрланге можно создавать O(N) процессов.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Эрланг
От: FR  
Дата: 23.09.09 14:30
Оценка:
Здравствуйте, remark, Вы писали:


R>Апологеты Эрланг говорят примерно следующее. Переключение ядерных потоков дорого, поэтому вы не можете их использовать в ряде задач, т.к. время переключения будет слишком большим. В Эрланге потоки легковесные и переключаются быстро, поэтому вы можете из использовать для некоторых из тех целей, для который вы не могли это делать с ядерными потоками.

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

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

FR>>Еще учти что на Эрланге можно без проблем создать десять тысяч потоков, системные же несколько тысяч потоков будут в основном тратить время на переключения друг на друга.


R>Это бесспорно. В плане памяти они легковесные.

R>Ядерных потоков можно создать, ну там допустим, 32*Количество_процессоров, что бы всё нормально работало. Но O(N) (по размерности входных данных) потоков всё равно создавать нельзя. На Эрланге можно создавать O(N) процессов.

Ну так это тоже компонент цены.
Re[5]: Эрланг
От: remark Россия http://www.1024cores.net/
Дата: 23.09.09 14:35
Оценка:
Здравствуйте, FR, Вы писали:

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

FR>Да и по скорости переключений надо мерять, мне кажется оценивать по одной задаче будет неправильно.

FR>>>Еще учти что на Эрланге можно без проблем создать десять тысяч потоков, системные же несколько тысяч потоков будут в основном тратить время на переключения друг на друга.


R>>Это бесспорно. В плане памяти они легковесные.

R>>Ядерных потоков можно создать, ну там допустим, 32*Количество_процессоров, что бы всё нормально работало. Но O(N) (по размерности входных данных) потоков всё равно создавать нельзя. На Эрланге можно создавать O(N) процессов.

FR>Ну так это тоже компонент цены.


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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: Хамелеоны быстрые и очень быстрые
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.09 14:48
Оценка: +3
Здравствуйте, remark, Вы писали:

R>Дабы немного разжечь интерес:...

R>

Ты не хочешь все это дело оформить соответствующим образом, доработать чтобы материал был более развернутым и понятным, добавить туда результаты и т.п. и прислать нам для размещения в качестве статьи?

А то ведь через некоторое время тема уйдет вниз и все про нее забудут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Хамелеоны быстрые и очень быстрые
От: remark Россия http://www.1024cores.net/
Дата: 23.09.09 15:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ты не хочешь все это дело оформить соответствующим образом, доработать чтобы материал был более развернутым и понятным, добавить туда результаты и т.п. и прислать нам для размещения в качестве статьи?


VD>А то ведь через некоторое время тема уйдет вниз и все про нее забудут.


Очень хочу... но, блин, время, сами понимаете.
Написать работающую программу под Windows заняло пару часов от силы. Казалось бы вот и все трудозатраты. Ан нет, портировать, причесать, протестировать, засабмитить, исправить, засабмитить заняло наверное где-то день. Засабмитил, думаю, как-то глупо получается, всё, что получилось в результате 1 циферка в таблице. Написание описания заняло наверное ещё день. Для статьи нужны таблицы, картинки, подробные описания, редакторская правка и т.д. в итоге дня 3 как минимум.
Тем более, что всё остаётся в моих блогах:
http://software.intel.com/ru-ru/blogs/author/dmitriy-vyukov/
http://software.intel.com/en-us/blogs/author/dmitriy-vyukov/


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[16]: Хамелеоны быстрые и очень быстрые
От: thesz Россия http://thesz.livejournal.com
Дата: 23.09.09 15:36
Оценка: -3
Здравствуйте, remark, Вы писали:

R>Здравствуйте, thesz, Вы писали:


T>>>>Я уж столько надоказывал и тут и всюду, что имею право на занятия тем, что интересно мне лично.

CC>>>Это вторая стандартная отмазка.

CC>>>Да и в целом, не пристало сеньёру сказав "А" замять тему и таки не говорить "Б".

CC>>>Тем более делов то: ткнуть носом нубов в те самые примитивы, которых недостаёт хаскель программе чтоб таки догнать сишный код remark-а.

T>>Фиксирование зелёных нитей на процессорах есть. Во что я "ткнул носом нубов" в том сообщении FR.

R>Этого не достаточно. Все 4 аспекта, который я описал критичны. Если убрать хотя бы 1, то время выполнения увеличивается в разы.

Понятно.

Но неинтересно.

R>Я думаю, что для Haskell просто не разумно гнаться "один-в-один" за С/С++, и показывать на наличие конкретных аналогичных возможностей. На Haskell это будет реализовывать просто до-другому, поэтому наличие аналогичной возможности не релевантно. Соотв. вопрос — какой производительности может достичь программа на Haskell реализованная "по-другому", по его законам, так сказать?


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

CC>>>Ну или признать что их на самом деле попросту нет.

T>>Да мне на это наплевать. Есть они, нет их. Для работы это неважно.
T>>Это важно для раздутия чьей-то (моей, чьей-то ещё, неважно) пиписьки прямо здесь и прямо сейчас, и совершенно не имеет смысла в длительной перспективе.
R>Ну так об этом как раз и есть этот топик. Можно назвать это "переньем пиписьками", можно назвать соревнованием в реализации конкретной задачи.
R>Если тебе на это наплевать, то зачем и о чём ты тут вообще пишешь? Проходи мимо. Или говори по теме.

И вот зачем ты это сказал?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Хамелеоны быстрые и очень быстрые
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.09 15:49
Оценка:
Здравствуйте, remark, Вы писали:

VD>>А то ведь через некоторое время тема уйдет вниз и все про нее забудут.


R>Очень хочу... но, блин, время, сами понимаете.


Это понятно. Но и результат более ценный будет.

R>Написать работающую программу под Windows заняло пару часов от силы. Казалось бы вот и все трудозатраты. Ан нет, портировать, причесать, протестировать, засабмитить, исправить, засабмитить заняло наверное где-то день.


Для статьи все это не так нужно. В прочем все равно уже все сделано.

R> Засабмитил, думаю, как-то глупо получается, всё, что получилось в результате 1 циферка в таблице. Написание описания заняло наверное ещё день.


Так оно и бывает. Но при этом ценность такого результата намного выше. Сам по себе тест — не более довольно бесполезная пенисометрия. И так понятно, что чем ниже уровень языка, тем проще на оптимизировать на нем код для простой (не объемной) задачи. Но вот идеи использованные при оптимизации дорогого стоят, так как именно их можно будет использовать на практике (в реальных задачах).

R>Для статьи нужны таблицы, картинки, подробные описания, редакторская правка и т.д. в итоге дня 3 как минимум.

R>Тем более, что всё остаётся в моих блогах:
R>http://software.intel.com/ru-ru/blogs/author/dmitriy-vyukov/
R>http://software.intel.com/en-us/blogs/author/dmitriy-vyukov/

Ну, так потрать эти 3 дня на пользу человечества .
Тем более, что можно делать это потихоничку. Выкрить эти 3 дня в течении месяца.

Что до картинок, то тут мы можем тебе помочь. У нас на то есть редакторы. Сделай макет картинок в том формате в котором тебе будет удобнее, а мы переделаем их в красивом виде и в том формате в котором их буде удобнее размещать на вебе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Хамелеоны быстрые и очень быстрые
От: thesz Россия http://thesz.livejournal.com
Дата: 23.09.09 15:49
Оценка: -1 :)
Здравствуйте, remark, Вы писали:

R>Здравствуйте, thesz, Вы писали:


T>>>>>>Мне неинтересен [b]конкретно этот[b] эксперимент. У меня своих висящих штуки три или больше, с потенциально гораздо большим выхлопом.

FR>>>>>Угу вполне стандартная отмазка

T>>>>Я уж столько надоказывал и тут и всюду, что имею право на занятия тем, что интересно мне лично.


R>>>Не вопрос, никто и не говорит, что тебе делать.


T>>И завершил тираду, сказав, что мне надо делать.

R>Ну хорошо, да, я говорю/призываю людей высказываться по существу и аргументированно. Мне кажется, это вполне разумно.

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

Это нормально.

R>>>Просто пока всё, что ты сказал несёт практически нулевую информацию, и складывается впечатление, что интересно тебе переливание из пустого в порожнее. Я тоже могу сказать, что у меня есть программа, которая в 1000 раз быстрее всех ваших, но больше ничего говорить и показывать не буду. Смысл? Это уже попахивает троллингом в техническом форуме. Да, полезное общение в форуме требует времени, это надо понимать, и ИМО сообщать либо хоть какую-то информацию, либо не говорить ничего. Уже мог бы за это время лучше набросать программу (благо там всего-то 65 строчек в программе на Haskell, некоторую часть можно прям оттуда и скопи-пастить), и запостить здесь, а я могу её туда засабмитить (с твоим именем естественно). Делов-то? Тем более, я так понимаю, что для тебя это достаточно тривиальная задача.


T>>Э, нет.

T>>Я FR показал, что есть примитивы фиксации нитей на процессорах, пусть он теперь ваяет, если захочет.
T>>Или пусть это дело ваяешь ты.
T>>Иными словами, те люди, которым интересна производительность языков программирования.
T>>Если нет желания, то я не против.
R>Если ты говоришь, о том, что можно сделать эффективную реализацию на Haskell, образно выражаясь, "скопировав" реализацию на С, то привязки потоков к ядрам не достаточно. Очень сильно не достаточно. Необходимы все 4 момента, которые я описал, включая определение топологии системы. Отсутствие любого из них увеличит время выполнения в разы.

У тебя четыре пункта, отставание у Хаскеля в пять раз. Если каждый пункт обеспечивает ускорение в разы (в два раза), то твоя программа должна опережать Хаскельную в 16 раз. Чего мы не наблюдаем.

Поэтому я думаю, что из твоих четырёх пунктов только один или два являются значимыми, а остальные только на подхвате.

Какие из них какие, меня мало волнует. В любом случае я смогу обеспечить выполнение любого пункта из перечисленных тобой.

А в реальной жизни так я вообще возьму C. Или сгенерю его.

R>Так что пока что мы ничего не имеем с твоей стороны.

R>А то, что есть возможность привязки потоком в процессорам, это и так было ясно, потому что бывшая самая быстрая реализация на Haskell как раз и использует forkOnIO, и за счёт этого и была относительно быстрой.
R>Так что вот эти 4.5 секунд как раз и есть предел с использованием forkOnIO.

Ура!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[17]: Хамелеоны быстрые и очень быстрые
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.09 15:53
Оценка: 1 (1) +4
Здравствуйте, thesz, Вы писали:

R>>Если ты говоришь, о том, что можно сделать эффективную реализацию на Haskell, образно выражаясь, "скопировав" реализацию на С, то привязки потоков к ядрам не достаточно. Очень сильно не достаточно. Необходимы все 4 момента, которые я описал, включая определение топологии системы. Отсутствие любого из них увеличит время выполнения в разы.


T>У тебя четыре пункта, отставание у Хаскеля в пять раз. Если каждый пункт обеспечивает ускорение в разы (в два раза), то твоя программа должна опережать Хаскельную в 16 раз. Чего мы не наблюдаем.


T>Поэтому я думаю, что из твоих четырёх пунктов только один или два являются значимыми, а остальные только на подхвате.


А что тут думать то? Все выкладки он разжевал. Тебе остается только изучить его код и его описание и реализовать с их учетом оптимизировать хаскелевскую программу. Результат будет говорить сам за себя.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Хамелеоны быстрые и очень быстрые
От: remark Россия http://www.1024cores.net/
Дата: 23.09.09 15:54
Оценка:
Здравствуйте, thesz, Вы писали:

R>>Если ты говоришь, о том, что можно сделать эффективную реализацию на Haskell, образно выражаясь, "скопировав" реализацию на С, то привязки потоков к ядрам не достаточно. Очень сильно не достаточно. Необходимы все 4 момента, которые я описал, включая определение топологии системы. Отсутствие любого из них увеличит время выполнения в разы.


T>У тебя четыре пункта, отставание у Хаскеля в пять раз. Если каждый пункт обеспечивает ускорение в разы (в два раза), то твоя программа должна опережать Хаскельную в 16 раз. Чего мы не наблюдаем.


Зависимость не линейная.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.