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

N>Понятно, что быстродействие у него за счёт библиотек, но всё равно.

Нет, не все равно.

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

___>Странно, что никто дальше приведенной цитаты не смотрит.

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

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

N>>Понятно, что быстродействие у него за счёт библиотек, но всё равно.

K>Нет, не все равно.

Мне, как пользователю Матлаба, всё равно. За меня делает работу среда, а не язык — какая разница? Главное, что язык позволяет себя так, незаметно для пользователя ускорять.
А тебе почему нет?

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

N>>Так кто же видит за Матлабом его библиотеки? Пишут на языке, получается быстро. Всё путём.

AVK>Ты путаешь Матлаб как платформу и Матлаб как язык.

А что ещё есть? Octave? Он тоже не медленный.
Все математические среды работают поверх производительных, отлаженных библиотек. Никто не будет их переписывать под свой язык, а просто сделает их незаметной пользователю частью стандартной библиотеки. Поэтому пользователям языка плевать на то, что за них ускоряет программу: компилятор, интерпретатор или готовые библиотеки.


AVK>Потому что динамику даже на богатый x86 оттранслировать эффективно не получается. А уж на куцый GPU ... mission impossible.

Я так понимаю, что имеются результаты с неудовлетворительной производительностью матлабовского кода на GPU. Или нет?
Известные мне факты противоречат твоему утверждению.

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

AVK>>Ты путаешь Матлаб как платформу и Матлаб как язык.

N>А что ещё есть?

Что то я логики не уловил.

N>Поэтому пользователям языка плевать на то, что за них ускоряет программу: компилятор, интерпретатор или готовые библиотеки.

Мы сейчас не про пользователей, а про утверждение создателей.

N>Известные мне факты противоречат твоему утверждению.

Там матлабовский язык в GPU укладывается, или написанная на статически типизированном языке умеет это делать?

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


AVK>Автоматично транслировать динамику на GPU ... ох.
Матлаб состоит из логики и кусков типа "бери большой массив и колоти его до упаду". Последнее транслируется просто отлично.

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

D>Матлаб состоит из логики и кусков типа "бери большой массив и колоти его до упаду". Последнее транслируется просто отлично.

Так я и не спорю — транслировать на GPU написанные на С++ вычислительные блоки руками — вполне возможно. Но тут то речь про язык.

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

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

D>>Матлаб состоит из логики и кусков типа "бери большой массив и колоти его до упаду". Последнее транслируется просто отлично.

AVK>Так я и не спорю — транслировать на GPU написанные на С++ вычислительные блоки руками — вполне возможно. Но тут то речь про язык.
Ну это как с ленивыми вычислениями в C++, с помощью бубна и шаблонной матери можно сделать что-то подобное. И потом говорить, что в С++ они существуют. Здесь примерно та же ситуация, насколько я себе представляю.

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

AVK>>>Ты путаешь Матлаб как платформу и Матлаб как язык.
N>>А что ещё есть?

AVK>Что то я логики не уловил.

Что ещё бывает с языком "Матлаб", но без среды "Матлаб". Octave?

N>>Поэтому пользователям языка плевать на то, что за них ускоряет программу: компилятор, интерпретатор или готовые библиотеки.
AVK>Мы сейчас не про пользователей, а про утверждение создателей.

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


AVK>Там матлабовский язык в GPU укладывается, или написанная на статически типизированном языке умеет это делать?

Матлабовский динамический, ориентированный на матричные вычисления язык.
"или написанная на статически типизированном языке умеет это делать?" — это о чём вообще?

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

N>Если за языком будут стоять быстрые, невидимые библиотеки, ...

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

AVK>>Там матлабовский язык в GPU укладывается, или написанная на статически типизированном языке умеет это делать?

N>Матлабовский динамический, ориентированный на матричные вычисления язык.
N>"или написанная на статически типизированном языке умеет это делать?" — это о чём вообще?

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

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

___>Перевели запись в блоге на Хабрахабре.

Разжуйте пожалуйста лентяю красоту языка. Что то я даже примеров кода нормальных быстро не нашел.

Мне например совершенно не нравятся конструкция:

for line = lines

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

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

VD>То это будет скрипт. И как любой скрипт он будет негоден для реализации самих вычислений, а будет использоваться для "склеивания и запуска".

Хорошо, давай разберёмся. Пример: создать матрицу с заданными значениями и транспонировать её:

A = [1 2 0; 2 5 -1; 4 10 -1]
B = A'

Операция транспонирования, как и множество других матричных операций, где-то внутри Матлаба захардкорена и выполняется очень быстро. Зачастую программы на С проигрывают таким коротеньким матлабовским скриптам.
Я пользуюсь динамическим языком? Да. Он быстрый? Да. Какая разница, что его назвали скриптом или DSL'ем? Какая разница, за счёт чего он такой быстрый?
Я так понял, что разработчики Джулии делают быстрый динамический язык для решения технических задач. Быстрый — значит, программы на нём будут выполняться быстро, а шустрый интерпретатор или нет — это ерунда. Задачи-то выполняться будут тяжёлые, типа решения больших систем уравнений и другой математики, а интерпретация — всего лишь разбор коротенькой строки.


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

Сам скрипт нет смысла переносить на GPU. Разбор строки из 6 символов (строка с транспонированием матрицы) — это не проблема. Проблема — сами вычисления, организация работы с памятью, чтобы результаты промежуточных вычислений не копировать туда сюда (host <-> device).
И это у Матлаба получается.

P.S. Неужели никто не удосужился прочитать новость целиком? Они делают язык для решения технических задач:
"Мы любим все эти языки; они прекрасны и могучи. Для той работы, которую мы делаем — научные вычисления, машинное обучение, дата-майнинг, крупномасштабная линейная алгебра, распределённые и параллельные вычисления — каждый идеально подходит в определённом аспекте, но ужасен в других. Каждый из них — это компромисс."

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

AVK>>Что то я логики не уловил.
N>Что ещё бывает с языком "Матлаб", но без среды "Матлаб". Octave?

Неважно что бывает. Тут главное (с точки зрения разработчика языка, если тебе так угодно, не сточки зрения пользователя) — сам язык, даже в составе матлаба.

AVK>>Мы сейчас не про пользователей, а про утверждение создателей.
N>Если за языком будут стоять быстрые, невидимые библиотеки, но пофиг на на скорость интерпретации самого языка.

Может и пофиг, но это не будет означать, что сам язык быстрый.

N>"или написанная на статически типизированном языке умеет это делать?" — это о чём вообще?\

О бибилотеке, которая умеет использовать GPU.

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

N>Я пользуюсь динамическим языком? Да. Он быстрый? Да.

Нет.

N> Какая разница, что его назвали скриптом или DSL'ем? Какая разница, за счёт чего он такой быстрый?

Он — не быстрый. А уметь вызывать готовые нативные быстрые модули — в этом никакой заслуги нет, это умеет почти любой, даже самый тормозной, язык.

N>Сам скрипт нет смысла переносить на GPU.

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

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

N>Хорошо, давай разберёмся. Пример: создать матрицу с заданными значениями и транспонировать её:
N>

N>A = [1 2 0; 2 5 -1; 4 10 -1]
N>B = A'

N>Операция транспонирования, как и множество других матричных операций, где-то внутри Матлаба захардкорена и выполняется очень быстро. Зачастую программы на С проигрывают таким коротеньким матлабовским скриптам.
N>Я пользуюсь динамическим языком?

Зависит о реализации. В принципе, приведенный код вполне может быть статически типизирован.

N>Да. Он быстрый?

Он никакой, так как вычислений в нем не производится.

N>Да.

Чё, да? Сам с собой разговариваешь?

N> Какая разница, что его назвали скриптом или DSL'ем?

Огромная. Язык медленный. Библиотеки у него могут быть быстрыми. Но если речь о библиотеках, на фиг нужно новые языки изобретать? Опиши матрицу на С или ЯваСктипте и получи тот же результат.

N> Какая разница, за счёт чего он такой быстрый?

Огромная. В случае библиотек все быстрые вычисления заранее заданы. Если придется написать новое, то это просто не получится. Они будут медленными, так как язык медленный. Точнее медленная реализация, но динамическая типизация языка не даст добиться идеальной производительности.

N>Я так понял, что разработчики Джулии делают быстрый динамический язык

Это оксюморон. Или быстрый, или димически-типизированный. Зачем превращать обсуждение в рекурсивное?

N> Задачи-то выполняться будут тяжёлые, типа решения больших систем уравнений и другой математики, а интерпретация — всего лишь разбор коротенькой строки.

На фиг нужен этот язык? Матлаб уже есть. Язык быстрым не будет. Это мы уже выяснили. Это будет очередной скрипт для вызова готовых библиотек. Так сделайте библиотеки для Питона, Руби и ЖабаСкрипта и не морочьте людям голову.

N>Сам скрипт нет смысла переносить на GPU.

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

N>Разбор строки из 6 символов (строка с транспонированием матрицы) — это не проблема. Проблема — сами вычисления, организация работы с памятью, чтобы результаты промежуточных вычислений не копировать туда сюда (host <-> device).
N>И это у Матлаба получается.

Замечательно. Какова цель этого нового языка? Чем Матлаб то не угодил?

N>P.S. Неужели никто не удосужился прочитать новость целиком? Они делают язык для решения технических задач:
N>"Мы любим все эти языки; они прекрасны и могучи. Для той работы, которую мы делаем — научные вычисления, машинное обучение, дата-майнинг, крупномасштабная линейная алгебра, распределённые и параллельные вычисления — каждый идеально подходит в определённом аспекте, но ужасен в других. Каждый из них — это компромисс."

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

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

Z>Разжуйте пожалуйста лентяю красоту языка. Что то я даже примеров кода нормальных быстро не нашел.

Я бы с радостью, но у меня времени совсем пока на это нет. Тем более в мануале все достаточно хорошо описано. Вчера за вечер прошелся по всему мануалу. Вкратце, это один из немногих языков, ознакомившись с которыми я получал такое удовольствие (последним таким был Clojure). Когда смотришь на дизайн языка и думаешь, как грамотно это сделано и что будь моя воля, я бы сделал также.

Что касается фич языка, так их легко можно посмотреть в мануале, перечислять каждый из них тут смысла нет. Смысл моего поста в том, чтобы тем кому интересно узнали о появлении такого языка. А разбираться в нем или нет право каждого. Я не собираюсь и не буду тут доказывать о нужности и полезности этого языка (т.к. я не автор этого языка). Тут уже кое-кто высказал мнение, например, мол на нем нельзя написать ОС, значит я его не буду изучать Вот, например даже ты, смотришь на нее с призмы Немерла, сравнивая с метапрограммированием на Немерле. А меня например, эта часть языка абсолютно не интересна. Придет VladD2 и найдет 100500 отличий от Немерла и уйдет сказав, фигня эта ваша Julia При это все мы любим цитировать про известный парадокс блаб программиста.

ЗЫ: Что касается меня, я хочу в будущем сменить ею связку python+numpy+scipy.

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

VD>Замечательно. Какова цель этого нового языка? Чем Матлаб то не угодил?

Язык хуже Матлаба ещё надо поискать: все недостатки динамической типизации, ужасный синтаксис, отдельные файлы для каждой функции. Помню, мучался с ним в университете.

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

N>>Я пользуюсь динамическим языком? Да. Он быстрый? Да.

AVK>Нет.
AVK>Он — не быстрый. А уметь вызывать готовые нативные быстрые модули — в этом никакой заслуги нет, это умеет почти любой, даже самый тормозной, язык.

Почему нет? Я могу на нём в пару строк написать на нём решение большой разреженной системы линейных уравнений. Он отработает быстрей, чем кто-то сделает на статически типизированном С#. Почему нет? При этому, заметь, я не буду использовать никаких сторонних тулбоксов, только средства языка.


N>>Сам скрипт нет смысла переносить на GPU.

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

Все написанные расчёты переносятся на GPU, не переносится интерпретация скрипта. А кэп как бы намекает, что именно расчёты, а не интерпретация являются узким местом.

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

VD>Зависит о реализации. В принципе, приведенный код вполне может быть статически типизирован.

Может быть? Мы говорим о динамическом языке Матлаб.

N>>Да. Он быстрый?
VD>Он никакой, так как вычислений в нем не производится.
N>>Да.
VD>Чё, да? Сам с собой разговариваешь?

Ну, пошутил так пошутил! Весь смысл Матлаба в том, что все вычисления происходят в нём с матрицами, поэтому можно писать в векторной форме. Не оперировать циклами, переменными, а матрицами и векторами. Поэтому код получается маленьким, интерпретируется быстро, а все вычисления оптимизированы.

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

VD>Огромная. В случае библиотек все быстрые вычисления заранее заданы. Если придется написать новое, то это просто не получится. Они будут медленными, так как язык медленный. Точнее медленная реализация, но динамическая типизация языка не даст добиться идеальной производительности.

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

N>>Я так понял, что разработчики Джулии делают быстрый динамический язык
VD>Это оксюморон. Или быстрый, или димически-типизированный. Зачем превращать обсуждение в рекурсивное?

Твоё утверждение в некоторых частных случаях неверно. Ещё раз посмотри на мой пример — транспонирование матрицы является частью синтаксиса языка, задаётся всего одним символом, интерпретируется быстро, выполняется на реальных данных тоже. Какая разница во что интерпретируется код (ассемблер виртуальной машины, бинарные коды для процессора или высокопроизводительные функции), если он реально быстро работает.

VD>На фиг нужен этот язык? Матлаб уже есть. Язык быстрым не будет. Это мы уже выяснили. Это будет очередной скрипт для вызова готовых библиотек. Так сделайте библиотеки для Питона, Руби и ЖабаСкрипта и не морочьте людям голову.

Они же пишут для чего делают язык. Почитай. Они пишут, что знают и Питон, и С, и Матлаб, и R, и Matematica. Создатели языка ясно говорят, что именно им не нравится. Не надо быть таким узколобым и смотреть на мир только лишь глазами программиста. Работают и программируют ещё и биологи, и математики, и медики, и физики. У меня перед глазами есть пример — младший брат-медик, которому надо обрабатывать результаты экспериментов. И ему нафиг не сдался твой Питон с библиотеками — гораздо удобней работать (программировать, да) на специализированном языке, ориентированном на обработку статистических данных. Добро пожаловать в реальный мир!

N>>Сам скрипт нет смысла переносить на GPU.
VD>Кроме матриц у вас других задач нет? Если нет, то потрудитесь называть вещи своими именами. "Новый, высокоуровневый, медленный язык с быстрыми библиотеками для матричных вычисления.

О, кэп! Матлаб и есть такой язык, который быстро работает на матрицах за счёт. Никто на нём компиляторы не пишет, поэтому медлительность работы языка на таких задачах никто не видит. Давай инкриминировать микроскопу, что им неудобно гвозди забивать.
А создатели языка Джулия хотят совместить вместе удобный синтаксис для матриц, статистики и других технических задач. И скорость работы, написанных на этом языке программ, должна быть высока. И, судя по тестам, у них получается.

VD>Замечательно. Какова цель этого нового языка? Чем Матлаб то не угодил?

Почитай статью, они пишут, чем им не угодил Матлаб. Зачем отвечать, не разобравшись в теме?

N>>P.S. Неужели никто не удосужился прочитать новость целиком? Они делают язык для решения технических задач:
VD>Это треп. Общие слова. В прочем, сейчас каждый норовит выпустить новый крутой язык, который, рально на фиг никому не упал. А так как делать скрипты намного проще, вот и лепят их в промышленных количествах.

Ты не разобрался в их целях и критикуешь. Также ты не знаком с их предметной областью. Но авторитетно заявляешь про трёп. Круто!

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

N>Почему нет?

Потому что язык это одно, а библиотеки — это другое.

N> Я могу на нём в пару строк написать на нём решение большой разреженной системы линейных уравнений. Он отработает быстрей, чем кто-то сделает на статически типизированном С#.

Нет, не отработает. Потому что в C# я точно так же могу подключить ту же самую библиотеку.

N> Почему нет?

Потому что, если мы сравниваем языки, это лишено смысла.

N>Все написанные расчёты переносятся на GPU, не переносится интерпретация скрипта.

Раньше ты немного другое писал:

К тому же у него есть автоматическая трансляция в код на GPU

Так в чем автоматичность, если использование GPU сделано ручками на совсем другом языке?