Пожалуй, повторюсь про архитектуры.
Ленивые вычисления Хаскеля - не более, чем ещё одна компьютерная архитектура.
Мне легко, под моей лысиной ассемблеры десятка (если не двух) процессоров, Пролог, Тикль (да, "всё строка" это тоже архитектура), Форт (три машины, от простой до оптимизирующей через реализацию на Си), NESL, и машины потока данных. И тут с кластерами да GPU поковырялся поплотнее.
Так вот, даже разница между процессором с внеочередным выполнением и процессором без такового заставляет переписывать заметную часть кода. Если я всё правильно понимаю, то это где-то в районе 30%. А иначе отставание в разы (до порядков)
Что интересно, при переходе на in-order архитектуры абстракции начинают протекать со страшной силой. Мне даже известно про проект для PS2 на C++, где всё было запихнуто в шаблоны, ибо иначе не хватало быстродействия.
Поэтому удивление от проблем с производительностью вычисления среднего арифметического односвязного списка может возникнуть только у неопытного человека, я так думаю.
Скачайте симулятор Cell BE и попробуйте написать среднее арифметическое односвязного списка, чтобы задействовать все ядра. Да зачем писать, просто почитайте про архитектуру и попробуйте прикинуть, во что это вам обойдётся. В процессе обязательно почитайте про подход NESL (list ranking), поскольку именно оттуда надо черпать идеи.
Если вы испытываете недоумение по поводу производительности среднего арифметического в Хаскеле, то, я думаю, вы испытаете не менее сильные чувства в проектировании кода для Cell BE. И это я вам ещё подсказку дал!
Мне легко, под моей лысиной ассемблеры десятка (если не двух) процессоров, Пролог, Тикль (да, "всё строка" это тоже архитектура), Форт (три машины, от простой до оптимизирующей через реализацию на Си), NESL, и машины потока данных. И тут с кластерами да GPU поковырялся поплотнее.
Так вот, даже разница между процессором с внеочередным выполнением и процессором без такового заставляет переписывать заметную часть кода. Если я всё правильно понимаю, то это где-то в районе 30%. А иначе отставание в разы (до порядков)
Что интересно, при переходе на in-order архитектуры абстракции начинают протекать со страшной силой. Мне даже известно про проект для PS2 на C++, где всё было запихнуто в шаблоны, ибо иначе не хватало быстродействия.
Поэтому удивление от проблем с производительностью вычисления среднего арифметического односвязного списка может возникнуть только у неопытного человека, я так думаю.
Скачайте симулятор Cell BE и попробуйте написать среднее арифметическое односвязного списка, чтобы задействовать все ядра. Да зачем писать, просто почитайте про архитектуру и попробуйте прикинуть, во что это вам обойдётся. В процессе обязательно почитайте про подход NESL (list ranking), поскольку именно оттуда надо черпать идеи.
Если вы испытываете недоумение по поводу производительности среднего арифметического в Хаскеле, то, я думаю, вы испытаете не менее сильные чувства в проектировании кода для Cell BE. И это я вам ещё подсказку дал!