Здравствуйте, minorlogic, Вы писали:
M>А я считаю что дело не в массовости , потому что FFMPEG ядро делают несколько человек. Я уверен, что если бы использование FP дало бы хоть 5% к производительности программы ядро бы уже переписали.
Сейчас эти технологии могут ускорить разработку скажем в полтора-два раза (при сложной логике и побольше) и в эти же полтора-два раза замедлить (тот же Ocaml) работу готового кода.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, minorlogic, Вы писали:
M>>>>Почему по твоему мнению , серезные приложения которые я перечислял FFMPEG — JASPER написанны без использования FP ? на традиционных C/C++. ?
IT>>>Если бы они были написаны с использованием FP, то они были бы ещё серьёзней.
M>>Попробую еще раз , а почему они не написанны с использованием FP ?
FR>Потому что для подобных вещей важна не эффективность разработки а эффективность работы готового кода. Пока FP компиляторы не достигли уровня хороших C++ компиляторов.
Здравствуйте, minorlogic, Вы писали:
IT>>Если бы они были написаны с использованием FP, то они были бы ещё серьёзней.
M>Попробую еще раз , а почему они не написанны с использованием FP ?
Потому что в C/C++ нет ни одной фишки FP.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, minorlogic, Вы писали:
FR>>По моему это вполне нормальная практика. Таким образом пишут приложения например на очень даже не шустром питоне, при этом эффективность разработки существенно выше чем на чистом C++.
M>Ну да , я полностью согласен. А почему ВСЕ приложение не пишется нв питоне?
Потому что пока нет эффективных компиляторов питона выдающих код хотя бы на уровне плохих (хотя бы борландовского) компиляторов C++.
Но попытки есть, например тот же PyPy http://codespeak.net/pypy/dist/pypy/doc/home.html который дал очень неплохие вначале надежды.
Другой путь более успешный это язык со статической типизацией максимально похожий и имеющий многие вкусности от питона http://www.cython.org/
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, minorlogic, Вы писали:
M>>А я считаю что дело не в массовости , потому что FFMPEG ядро делают несколько человек. Я уверен, что если бы использование FP дало бы хоть 5% к производительности программы ядро бы уже переписали.
FR>Сейчас эти технологии могут ускорить разработку скажем в полтора-два раза (при сложной логике и побольше) и в эти же полтора-два раза замедлить (тот же Ocaml) работу готового кода.
Именно , вот про цену которую придется заплатить за использование FP. Кажется никто и не сказал.
Здравствуйте, FR, Вы писали:
FR>Потому что для подобных вещей важна не эффективность разработки а эффективность работы готового кода. Пока FP компиляторы не достигли уровня хороших C++ компиляторов.
Компилятор ocaml выплевывает код, сравнимый по быстродействию с тем, что выплевывает g++. Иногда даже более быстрый — за счет более оптимальной реализации вызова функции.
Здравствуйте, minorlogic, Вы писали:
M>Именно , вот про цену которую придется заплатить за использование FP. Кажется никто и не сказал.
Ровно ту же цену приходится платить за любую высокоуровневость, за тот же ООП например. В те же 90ые годы эта цена в очень большом числе случаев была слишком дорогой, сейчас скорее наоборот, но это после 10 — 15 лет развития оптимизиторов и прогресса вычислительной техники.
Никто пока не занимался серъезной оптимизацией (на уровне хороших компиляторов для C++ ) для ФП языков. Но лед уже тронулся так что цена будет дешеветь.
Здравствуйте, Pzz, Вы писали:
Pzz>Компилятор ocaml выплевывает код, сравнимый по быстродействию с тем, что выплевывает g++. Иногда даже более быстрый — за счет более оптимальной реализации вызова функции.
Я тестировал и смотрел асм выход от Ocaml'а, по сравнению с хорошими C++ компиляторами все-таки слабавато.
Здравствуйте, minorlogic, Вы писали:
M>Именно , вот про цену которую придется заплатить за использование FP. Кажется никто и не сказал.
Ну и какова будет цена за использование tuples, например, immutable паттерна или pattern matching? Ты видимо не понял смысла основного поста. Там нет призыва переходить на FP и тем более на чистые FP языки. Там высказано желание получить арсенал FP фич в мэйнстрим языках.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
When we were measuring the performance improvement of the SIMD extensions we wrote our own home-grown tests and they showed some nice improvements. But I wanted to implement a real game workload and compare it to the non-accelerated case.
I picked a C++ implementation and did a straight-forward port to Mono.Simd without optimizing anything to compare Simd vs Simd. The result was surprising, as it was even faster than the C++ version:
Based on the C++ code from F# for Game Development
The source code for the above tests is available here.
I use the C++ version just because it peeked my curiosity. If you use compiler-specific features in C++ to use SIMD instructions you will likely improve the C++ performance (please post the updated version and numbers if you do).
I would love to see whether Johann Deneux from the F# for Game Development Blog could evaluate the performance of Mono.Simd in his scenarios.
If you are curious and want to look at the assembly code generated with or without the SIMD optimizations, you want to call Mono's runtime with the -v -v flags (yes, twice) and use -O=simd and -O=-simd to enable or disable it.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Klapaucius, Вы писали:
K>Потому, что так оно и есть. Я считаю суммы столбцов в матрице со 128000 столбцов и 1024 строками. K>Т.к. мне нужно считать столбцы — я выбираю адекватное задаче представление матрицы. Она хранится транспонированной.
Вообще-то об этом стоило бы сказать с самого начала.
PD>>Условие — расположение массива не менять!
K>Ход игры, в которой правила меняет в процессе только одна сторона слишком предсказуем, чтобы быть интересным.
Если даже согласиться с этим тезисом, то суть проблемы от этого не исчезнет. Здесь выбор "адекватного представления не пройдет". А если придется идти и так и так, скажем, в алгоритмах линейной алгебры ?
Кстати, вопрос без подвоха. А вообще это хоть как-то сделать можно с помощью LinQ ? Я просто не знаю, я с ним очень поверхностно знаком. Разумееется, без транспонирования матрицы и без заведения каких-бы то ни было дополнительных массивов любой размерности хоть явно, хоть неявно.
K>С другой стороны, мне совершенно не понятно, какое отношение эти упражнения имеют к теме разговора и доказательству/опровержению тезиса о существовании abstraction gain?
А никакого. Тебе захотелось показать, что можно ускорить вычисление. Я ответил. Вот и все. Инициатива твоя была
Здравствуйте, gandjustas, Вы писали:
PD>>Но я-то его писал для других целей. Не могу же я отвечать за использование моего цикла в иной ситуации. G>Какой иной ситуации. Ситуация та же — суммирование массива по столбцам. Только способ получения массива другой.
Ничего себе! В одном (твоем случае) речь идет об операциях в памяти. В другом (моем) — системные вызовы. И массива как такового в памяти, между прочим, нет вообще
G>Вообще изначально код ущербный был. Надо получить весь массив пикселей, а потом сумировать вместо GetPixel на каждой итерации.
Если не секрет, чем это лучше ? Я вижу в этой идее только дополнительный массив, который тут совсем не нужен, и никаких плюсов.
PD>>Да, но я ее использовал там, где время было 1500-2000 мсек G>Ну сегодня это 1500 мс, а послезавтра 15 мс.
Так в том-то и дело. Если замеряется время порядка 1500 мсек — точность в 15 мсек достаточна, чтобы делать какие-то выводы. Если же замеряется время порядка 70 мсек — недостаточна и выводы делать не стоит.
G>Согласен. Я вполне могу убрать оттуда и окно, и GetPixel, а просто предложить просуммировать столбцы некоего двумерного массива, каким-то образом заданного. Правда, чтобы время померить, придется либо в цикл это вставить, либо уж очень большой массив использовать. G>Кто же это писал???
Я писал и я выделил сейчас то, на что ты внимание не обратил
Здравствуйте, AndrewVK, Вы писали:
PD>>"Этот прекрасный новый мир" (О.Хаксли) не читал ? Кстати, управляемый
AVK>Демагогия.
А все же почитай.
AVK>>>Самому не смешно?
PD>>Ну тогда зайди в форум по Win32 и объяви во всеуслышание — все, что вы тут делаете — смешно. Потому что там именно такой код и пишут, и мой — не лучше и не хуже. Зайди и напиши, честное слово. Посмотрим на реакцию.
AVK>Демагогия.
Почему же ? Вот ответь прямо — имеет право программирование на Win32 право на существование или нет ? Да или нет ?
PD>>А ты готов забыть в этом топике про C#, .Net. LinQ ? Либо уж оба забудем, либо оба нет
AVK>Уже два раза объяснял, почему твоя аналогия не годится.
Почему ты считаешь, что если ты объяснял — это означает, что твое объяснение и есть истина в последней инстанции ? Я тоже объяснил, что для меня эта аналогия годится. Ты хочешь оставить себе все средства, а меня почему-то лишить части их и после этого требовать сравнения. В конце концов, если уж на то пошло, объясни, почему вызов метода некоего класса (AsParallel) есть корректное действие, а вызов библиотечной функции — нет ? Не кругло это как-то...
PD>> Не хочешь окна и пикселей — возьми массив двумерный произвольного происхождения с цветами в качестве элементов. Что изменится, кроме ожидания, конечно ?
AVK>Ты чего то попутал — у меня с абстрагированием от конкретики проблем нет, это ты все пытаешься на обсуждение Win32 свернуть.
????
PD>>Андрей, ну некорректные же аргументы.
AVK>Некорректно, это когда ты упорно пытаешься сменить тему. Сразу скажу — со мной это не пройдет.
>Обсуждать здесь Win32 я не буду, и не надейся.
Ну если мне понадобится что-то из Win32 обсуждать, я это буду делать в друом форуме и с другими людьми.
>Речь про функциональное программирование. Не нравится шарп — ОК, давай возьмем ML или Немерле, годится?
Упаси боже
PD>> Не хочешь Win32 — не надо, но зачем педалировать-то ?
AVK>Опять же, не переваливай с больной головы не здоровую. Все что я хочу — чтобы Win32 здесь не обсуждалось.
Да никто и не требует от тебя, чтобы ты его обсуждал.
PD>> Там распараллеливание алгоритма, это главное, остальное второстепенное. А про конструкции vs бмблиотеки я уже сказал.
AVK>Распараллеливание тоже не главное. Главное — конструкции языка, которые его использование позволяют упростить.
AVK>>>А ты SQL не знаешь?
PD>> А если бы нет ? Вот предстваь себе — пишет некий X математическую обработку, ему SQL совсем не нужен.
AVK>А мне этот Х не интересен. Мне интересно реальное положение дел. Как ты думаешь, сколько народу в этом форуме ничего не знают про SQL?
То , что интересно или нет тебе лично, есть не более, чем твое личное дело. Мне, к примеру, совсем не интересен Немерле, и я нигде в дискуссиях о нем не участвовал.
PD>> А матрицы по диагоналям он сплошь и рядом проходит — в линейной алгебре диагональных, трехдиагональных и нижне- или верхне- треугольных матриц хоть пруд пруди.
AVK>Вобщем понятно, кода так и не будет. Приятно, когда твои предсказания сбываются .
Здравствуйте, AndrewVK, Вы писали:
AVK>Не надо фантазировать. Смотреть мне не смешно, а, скорее, грусто.
Недавно было смешно, теперь грустно. А нельзя ли вообще без эмоций обойтись ?
PD>>Но нет, подайте им все, они на меньшее не согласны
AVK>Цитату в студию, где я предлагал все писать в функциональном стиле.
Напоминаю целиком фразу, часть которой ты процитировал. Кое-что выделил
PD>Проблема же в том, что адепты этих новых технологий претендуют на их универсальность для всех задач. Тому же AndrewYK просто смешно смотреть на Win32 код — именно потому, что он не те средства (язык, АПИ) использует, что ему надо. Если бы он сказал — для твоей задачи это хорошо, для других — не годится — я бы немедленно согласился, тут и сказке конец. Я разве предлагал web-сайты на С++ писать или XML на ассемблере парсить ? Но нет, подайте им все, они на меньшее не согласны, а поэтому все, что под их методы не подходит — им смешно. Вот я и пытаюсь побудить их просто зафиксировать это простенькое утверждение — независимо от того, какие сферы покрывает то или иное направление.
Приведи в этой фразе место, где речь идет именно о ФП. Для меня это — лишь часть проблемы, а речь идет о более важном — о претензии на универсальность для всех задач. А Linq — это лишь часть.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>На самом деле мне и правда непонятно. Вот сегодня заказчик хочет чтобы у тебя было за 200 мс, завтра он передумал и хочет за 20 мс — т.е. так ни с того с сего требования по производительности изменились на порядок
Ну он понимает, что с этим железом такого не будет.
>А что в действительности-то заказчику нужно?
Массовая обработка входных данных большого размера в реальном масштабе времени. Это все. что я скажу.
>Это вообще похоже на какие-то упражнения для ума.
За упражнения для ума деньги не платят.
ВВ>Ты вот сам пишешь — десять лет назад занимался "текстурированием" на асме.
Насчет асма я не писал, его там не было. И вообще это было на Delphi
>Сейчас есть куча движков написанных на С# — да, это конечно не мейн-стрим подход (пока) — но почему спустя еще 10 лет эта задача не должна выполняться на дотнете без всяких "но"? Я вот правда не вижу причин
Я другое не понимаю. Почему, как только заходит речь о работе на пределе возможностей железа, так сразу начинается нечто в роде "да , сейчас это еще не очень, но вот лет через 10 будет..." Не знаю я, что через 10 лет будет, и мне это сейчас не так уж важно. Будет — тогда и говорить будем. А мне сейчас работать надо.
ВВ>Тезис "в перспективе любую задачу можно решить на ЯВУ" возникает не потому что все так ненавидят асм, а потому что непонятны те самые таинственные задачи, для которых он будет нужен всегда — ведь это основной тезис, не так ли? что асм никогда не умрет? Да ты и сам тумана напускаешь. ВВ>Помножение матриц — да, для меня это не задача. У меня мозг по-другому устроен И мне так кажется, что многие думают примерно также.
ВВ>Здесь речь в первую очередь о мейнстриме. И тенденции мейнстрима у меня лично сомнений не вызывают. Код становится все более высокоуровневым. Я не удивлюсь, если через -надцать лет C# будет восприниматься как низкоуровневое средство разработки, а большинство программистов будут какие-нибудь UML-и компилить.
Опять светлое будущее
>И при этом доказывать "ветеранам" вроде меня, что C# уже почти мертв, а UML 6.0 — это видите ли супер-уровень абстракции, благодаря которому программы проще оптимизировать.
Однажды у первобытного человека первобытный журналист взял первобытное интервью. На вопрос о том, что он ожидает от светлого будущего, интервьюируемый ответил — "огромных и великолепно обточенных кремней"
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Pavel Dvorkin, Вы писали:
ВВ>Ну вот, кстати, в тему "развития" этой задачи. Как ты думаешь, будет выглядеть эта задача, скажем, еще через 10 лет? Т.е. твоему заказчику будет нужно ровно то же самое, что в другом веке? Ну наверное ведь нет. И при реализации задачи придется рассчитывать честное освещение, "физику" ткани, завязанную на материал ткани опять же — и еще кучу всяких факторов. Алгоритмы еще более усложняются — и насколько реально — т.е. вообще в человеческих стилах — будет описывать все это на низком уровне?
Дело в том, что алгоритмы либо придется писать самому, либо брать их реализации откуда-то (а это тоже значит, что кто-то их писал сам). Физику ткани — ее что, автоматизировать можно ? Там свои вычислительные задачи, их хочешь не хочешь, а надо программировать. Либо уж такой ИИ тут задействовать, чтобы он смог это запрограммировать
И на чем это писать — не суть важно. И на С++, и на С# — это примерно одинаково по сложности и времени. Потому что здесь не дизайн и не сборка мусора главное, а программирование сложного расчета. Все равно на чем его писать, он от этого проще не станет.
А асм — да никто и не предлагает на нем писать все. Его используют только тогда, когда надо оптимизировать какой-то кусочек, вот и все. В той же программе для одежды, да, написал я свою реализацию дыойного цикла на асме — не понравилось мне, как Delphi его реализовал.
ВВ>Ведь, согласись, помимо производительности еще и не менее важный "ресурс" — время называется
Если нам не помогут, то мы тоже никого не пощадим.
