Здравствуйте, Аноним, Вы писали:

А>Если ли оценки производительности языка в матричных вычислениях?

В этом вопросе практически все языки дотнета идентичны.

В итоге все определяется качеством jit/ngen-компиляции MSIL-а в исполнимый код процессора. Современный джит порождает вычислительный код как середнячковый С-компилятор.

До Intel Fortran или до Intel C++ в суровом режиме оптимизации он несколько не дотягивает, но для большинства применений скорости за глаза хватает.

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

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

Кроме того в немерле есть макросы котоыре позволяют описав задачу в терминах простого встроенного DSL-я сгенерировать эффективный низкоуровневый код не использующий не эффективных технологий. В итоге можно получить очень быстыре решения при высоком уровне абстракции. Платой за это буедет силы которые нужно потратить на разрабоку DSL-я и его преоразование в эффективный код.

Здравствуйте, <Аноним>, Вы писали:

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

А в чем удобен PHP?

Здравствуйте, Don Reba, Вы писали:

DR>Я много занимался тяжёлой обработкой изображений на Немерле, с вынесением самых медленных операций на GPU через связку ATI Brook+ и C++/CLI. Матричные операции в .NET ощутимо тормозят, по причине медленной работы с массивами.

Знаю, просто мне написали что это язык общего назначения, вот я и привел область где он не годится

Здравствуйте, Аноним, Вы писали:

А>Веб тоже.

А веб то каким боком "мимо"?

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

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Веб тоже.

VD>А веб то каким боком "мимо"?

VD>Вообще, у логика ваша непостижима. Абстрактные вопросы не о чем, и какие-то выводы полностью высасываемые из пальца.

возможно. Немерли так же удобен как пхп?

Здравствуйте, Аноним, Вы писали:

А>Знаю, просто мне написали что это язык общего назначения, вот я и привел область где он не годится

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

просто интересно понять какие элементы планируется добавить

Здравствуйте, Аноним, Вы писали:

А>просто интересно понять какие элементы планируется добавить

Огласите весь список, пожалуйста! (с) Гайдай, операция "Ы"

Язык программирования общего назначения, он и есть общего назначения. Можно офисной автоматизацией занимать, можно компиляторы писать, а можно крестиком вышивать (с) кот Матроскин.
Платформа (.Net/Mono) и отсутствие низкоуровневых механизмов работы с памятью отсекают такие задачи как, например, написание драйверов для Линукс и Виндовс. В остальном ограничений нет.

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

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

VD>Здравствуйте, Аноним, Вы писали:

А>>просто интересно понять какие элементы планируется добавить

VD>Огласите весь список, пожалуйста! (с) Гайдай, операция "Ы"

VD>Язык программирования общего назначения, он и есть общего назначения. Можно офисной автоматизацией занимать, можно компиляторы писать, а можно крестиком вышивать (с) кот Матроскин.
VD>Платформа (.Net/Mono) и отсутствие низкоуровневых механизмов работы с памятью отсекают такие задачи как, например, написание драйверов для Линукс и Виндовс. В остальном ограничений нет.

VD>В целом, чем сложнее задача, тем более выгодным для ее решение будет Nemerle.
VD>Естественно, задачи которые можно эффективно решить с помощью введения DSL-ей, так же хорошо решаются.

Если ли оценки производительности языка в матричных вычислениях?

Я много занимался тяжёлой обработкой изображений на Немерле, с вынесением самых медленных операций на GPU через связку ATI Brook+ и C++/CLI. Матричные операции в .NET ощутимо тормозят, по причине медленной работы с массивами.

Здравствуйте, Аноним, Вы писали:

А>Знаю, просто мне написали что это язык общего назначения, вот я и привел область где он не годится

А с чего же не годится то? Тебе же как раз обратное написали.

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

Уж обычные вычисления точно ничем отличаться не будут.

Ну, а то что GPU быстрее, так это нормально. Он будет быстрее любого супер-опримизирующего компилятора.
Зато народ по наклепал интерфейсов

Автор: hardcase
Дата: 16.06.10

к тем самым GPU-шным библиотекам. Так что даже C++CLI особо не нужен.

ЗЫ

В обещм, я гяжу к нам забрел еще один орел которому нужны причины почему ему не нужен немерл.

Что их искать то? Если есть сильное предубеждение, то не стоит и начинать.

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Знаю, просто мне написали что это язык общего назначения, вот я и привел область где он не годится

VD>А с чего же не годится то? Тебе же как раз обратное написали.

VD>У дотнета есть свои узкие места, типа обязательной проверки выхода за пределы массиво и не лучшей реализации многомерных массивов, но в обще производительность будет не хуже чем у кода написанного на С.

VD>Уж обычные вычисления точно ничем отличаться не будут.

VD>Ну, а то что GPU быстрее, так это нормально. Он будет быстрее любого супер-опримизирующего компилятора.
VD>Зато народ по наклепал интерфейсов

Автор: hardcase
Дата: 16.06.10

к тем самым GPU-шным библиотекам. Так что даже C++CLI особо не нужен.

VD>ЗЫ

VD>В обещм, я гяжу к нам забрел еще один орел которому нужны причины почему ему не нужен немерл.

VD>Что их искать то? Если есть сильное предубеждение, то не стоит и начинать.

Абсолютно не правы. Я просто стараюсь понять. Одна ниша есть это языки программирования. Вторая ДСЛ. Математика мимо как я понял. Веб тоже.

Здравствуйте, Аноним, Вы писали:

А>Абсолютно не правы. Я просто стараюсь понять. Одна ниша есть это языки программирования. Вторая ДСЛ. Математика мимо как я понял. Веб тоже.

Да что за загадочная математика такая? 2 + 2 тоже математика.

Если скажем говорить об обработке потокового видео, то наверно дотнет не лучшее решение. А так...

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Абсолютно не правы. Я просто стараюсь понять. Одна ниша есть это языки программирования. Вторая ДСЛ. Математика мимо как я понял. Веб тоже.

VD>Да что за загадочная математика такая? 2 + 2 тоже математика.

VD>Если скажем говорить об обработке потокового видео, то наверно дотнет не лучшее решение. А так...

Просто язык либо вводит расширения для переходв в новую область либо расширяет существующие.

Под матиматикой я понимаю например решение уравнений гидродинамики.
там полезен ДСЛ, но нужна крайне эффективная работа с массивами.

мысль об optimization(a:Matrix*b:Matrix+c:Matrix*b->(a+c)*b)) пришла после разбора исходников openfoam. Часто я коде лучше написать не оптимизированно, но понятно, чем оптимизированно, так как любой код приходится рано или поздно менять.

Здравствуйте, Аноним, Вы писали:

А>Под матиматикой я понимаю например решение уравнений гидродинамики.
А>там полезен ДСЛ, но нужна крайне эффективная работа с массивами.

Вот это уже что-то. А то просто не ясно о чем идет разговор.

Слова о том, что работа с массивами медленная несколько не корректны.
Многомерные массивы не быстры по причине проверок границ массивов.
Одномерные довольно быстры. Особенно если осуществятся последовательный перебор.

Если нужна действительно очень высокая производительность в области матричных вычислений, то возможно действительно имеет смысл подумать о перекладывании оных на GPU, потому как никакой универсальный язык програмиирования не позволит добиться такого распараллеливания примитивных вычислений как GPU.

Тут стоит посоветоваться с тем же Don Reba и hardcase-ом. Последний сделал обертку над OpenCL

Автор: hardcase
Дата: 16.06.10

.

А>мысль об optimization(a:Matrix*b:Matrix+c:Matrix*b->(a+c)*b)) пришла после разбора исходников openfoam. Часто я коде лучше написать не оптимизированно, но понятно, чем оптимизированно, так как любой код приходится рано или поздно менять.

Поймите, оптимизации вроде этой — это мелочь на фоне того, что действительно само перемножение матриц требует массового копирования данных. Будучи выполненным на через тот же OpenCL даже "не оптимизированная" версия будет выполняться в сотни раз быстрее (за счет массового распараллеливания).

Здравствуйте, Аноним, Вы писали:

А>возможно. Немерли так же удобен как пхп?

Думаю, что во многом он в разы удобнее. Вряд ли в ПХП есть такие вещи как LINQ.

Советую посмотреть вот этот проект: nemerle on rails.

Ну, а по производительности ПХП и рядом не стоял.

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Под матиматикой я понимаю например решение уравнений гидродинамики.
А>>там полезен ДСЛ, но нужна крайне эффективная работа с массивами.

VD>Вот это уже что-то. А то просто не ясно о чем идет разговор.

VD>Слова о том, что работа с массивами медленная несколько не корректны.
VD>Многомерные массивы не быстры по причине проверок границ массивов.
VD>Одномерные довольно быстры. Особенно если осуществятся последовательный перебор.

VD>Если нужна действительно очень высокая производительность в области матричных вычислений, то возможно действительно имеет смысл подумать о перекладывании оных на GPU, потому как никакой универсальный язык програмиирования не позволит добиться такого распараллеливания примитивных вычислений как GPU.

VD>Тут стоит посоветоваться с тем же Don Reba и hardcase-ом. Последний сделал обертку над OpenCL

Автор: hardcase
Дата: 16.06.10

.

А>>мысль об optimization(a:Matrix*b:Matrix+c:Matrix*b->(a+c)*b)) пришла после разбора исходников openfoam. Часто я коде лучше написать не оптимизированно, но понятно, чем оптимизированно, так как любой код приходится рано или поздно менять.

VD>Поймите, оптимизации вроде этой — это мелочь на фоне того, что действительно само перемножение матриц требует массового копирования данных. Будучи выполненным на через тот же OpenCL даже "не оптимизированная" версия будет выполняться в сотни раз быстрее (за счет массового распараллеливания).

просто выйгрыш почти в 2 раза на такой простой оптимизации... насчет opencl — там просто вызовы операций будут транслироваться в вызовы opencl, но подобной оптимизации сделано не будет.

почти всегда ясный код(кроме случаев библиотек) лучше чем оптимизированный.

Здравствуйте, Аноним, Вы писали:

А>просто выйгрыш почти в 2 раза на такой простой оптимизации... насчет opencl — там просто вызовы операций будут транслироваться в вызовы opencl, но подобной оптимизации сделано не будет.

Аппаратная акселерация круче любой оптимизации. К тому же сама библиотека или код скармливающий ей данные может делать оптимизации в лучшем виде.

А>почти всегда ясный код(кроме случаев библиотек) лучше чем оптимизированный.

Это понятно. Но я говорю о другом.

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

VD>Поймите, оптимизации вроде этой — это мелочь на фоне того, что действительно само перемножение матриц требует массового копирования данных. Будучи выполненным на через тот же OpenCL даже "не оптимизированная" версия будет выполняться в сотни раз быстрее (за счет массового распараллеливания).

Для лучших результатов все вычислительное ядро надо на OpenCL фигачить, т.е. фактически скомпилировать некий DSL для матриц в Си.
Моя библиотека позволяет просто и быстро пристыковаться к opencl.dll и выполнить OpenCL программу.

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

H>Для лучших результатов все вычислительное ядро надо на OpenCL фигачить, т.е. фактически скомпилировать некий DSL для матриц в Си.
H>Моя библиотека позволяет просто и быстро пристыковаться к opencl.dll и выполнить OpenCL программу.

Это, да.
Жаль ее для парсера приспособить нельзя .

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

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

H>>Для лучших результатов все вычислительное ядро надо на OpenCL фигачить, т.е. фактически скомпилировать некий DSL для матриц в Си.
H>>Моя библиотека позволяет просто и быстро пристыковаться к opencl.dll и выполнить OpenCL программу.

VD>Это, да.
VD>Жаль ее для парсера приспособить нельзя .

да, было бы интересно... сразу ясно где использовать.