Почему мы создали Джулию, новый ЯП для технических вычислений

http://julialang.org/blog/2012/02/why-we-created-julia/
  • Перевод
Если вкратце, потому что мы жадные.

Мы продвинутые пользователи Matlab. Некоторые из нас хакеры Lisp. Некоторые питонисты, другие рубисты, есть ещё Perl-хакеры. Среди нас есть такие, кто использовал Mathematica раньше, чем у него начали расти волосы на лице. Есть и такие, у кого до сих пор не выросли. Мы построили больше графиков на R, чем способен любой здравомыслящий человек. C — это язык, который мы бы взяли на необитаемый остров.

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

Мы жадные: мы хотим больше.

Мы хотим язык с открытыми исходниками, под свободной лицензией. Мы хотим скорость C и динамизм Ruby. Мы хотим язык с равнозначностью кода и данных, с настоящими макросами как в Lisp, но с очевидными, знакомыми математическими нотациями, как в Matlab. Мы хотим удобное средство для обобщённого программирования как Python, простое для статистики как R, естественную обработку строк как Perl, мощную линейную алгебру как Matlab, хорошую склейку программ как shell. Что-то абсолютно простое в изучении, но при этом делающее счастливыми большинство серьёзных хакеров. Мы хотим это интерактивным и мы хотим это скомпилированным.

(Мы упомянули, что оно должно быть быстрым, как C?)

Пока мы продолжаем требовать, добавим ещё что-нибудь, обеспечивающее распределённую производительность Hadoop — без килобайтов boilerplate-кода Java и XML; без необходимости пробираться через гигабайты логов на сотнях машин, чтобы отловить баги. Мы хотим мощь без оболочек непроходимой сложности. Мы хотим писать простые скалярные циклы, которые компилируются в компактный машинный код, используя только регистры на одном CPU. Мы хотим написать A*B и запустить тысячу процессов на тысяче машин, вместе вычисляющих огромную матрицу.

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

Мы ведь не слишком многого просим, верно?

Даже хотя мы осознаём свою непозволительную жадность, мы по-прежнему хотим всё это. Около двух с половиной лет назад мы начали создавать язык своей мечты. Он ещё не закончен, но пришло время для релиза 1.0 — язык программирования, который мы создали, называется Джулия. Она уже удовлетворяет 90% наших грубых запросов, и теперь ей нужно ещё больше грубых запросов от других людей, чтобы развиваться дальше. Так что, если вы жадный, безрассудный, требовательный программист, вы должны попробовать.


Микробенчмарк на MacBook Pro с 2,53 ГГц Intel Core 2 Duo CPU и 8 ГБ DDR3 RAM 1066 МГц, для C++ указано абсолютное время выполнения в миллисекундах, остальные относительно к C++ (меньше — лучше)

Исходники всех бенчмарков

Пример кода Julia для множества Мандельброта и статистики случайных матриц
function mandel(z)
    c = z
    maxiter = 80
    for n = 1:maxiter
        if abs(z) > 2
            return n-1
        end
        z = z^2 + c
    end
    return maxiter
end

function randmatstat(t)
    n = 5
    v = zeros(t)
    w = zeros(t)
    for i = 1:t
        a = randn(n,n)
        b = randn(n,n)
        c = randn(n,n)
        d = randn(n,n)
        P = [a b c d]
        Q = [a b; c d]
        v[i] = trace((P.'*P)^4)
        w[i] = trace((Q.'*Q)^4)
    end
    std(v)/mean(v), std(w)/mean(w)
end
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 19
  • +2
    Перевод как-то не очень законченным кажется. Но спасибо за то, что нашли и рассказали об этом новом языке.
    • +6
      Не взлетит
      • 0
        Для любителей R и Matlab может и взлетит, но C или хотя бы Ruby не заменит, конешно. Но не для элого он создавался.
        • +4
          не нравятся мне все эти end
      • +4
        А как же benchmark для Fortran?
        Этот самый Formula Translator создавался для математических вычислений и, насколько я слышал, делает это еще быстрее, чем C/C++.
        • 0
          Синтаксис один-в-один похож на фортран.
          • 0
            Подозреваю, что это не случайно. Так будет проще продвигать среди целевой аудитории.
            • +9
              «Программист на Фортране может на любом языке писать на Фортране»
            • 0
              А мне на первый взгляд больше напомнило Lua.
            • +2
              Matlab… Matlab…

              Кто бы реализовал Simulink под Octave?))
              • 0
                А разве нет аналогов для Scilab?
              • 0
                По C++ также результаты по верхним 4-м функциям вызывают сомнения. Как же нужно извернуться, чтобы так медленно их написать? ИМХО, довольно противоречивая табличка у Вас по быстродействию. Судя по таблице — чем же лучше Ваш язык по сравнению с остальными?
                • +4
                  Ализар как всегда упустил важный комментарий к таблице:
                  C++ numbers are absolute benchmark times in milliseconds;
                  other timings are relative to C++ (smaller is better).
                  • 0
                    Так бы сразу, и таким же крупным шрифтом — иначе и не заметишь. А если бы оригинальный английский текст оставили — было бы даже понятнее.
                • +4
                  > C is our desert island programming language.

                  Более по-русски это звучит «C — это язык, который мы бы взяли на необитаемый остров».
                  • +2
                    Какие-то невероятные результаты — отличие на порядки то в одну, то в другую сторону. За счет разных алгоритмов, такое, понятно дело быть может, но лишь из-за различных языков… Лично мне сомнительно.
                    • +1
                      У одного языка оптимизируется хвостовая рекурсия, у второго — значительно более быстрая работа с массивами
                    • +2
                      Интересно вот что. Согласно тестам автора JS по скорости очень близок к Си++ (5 раз разница — это копейки) кроме последнего — rand_mat_mul, который ВСЕ языки выполняют очень быстро кроме него. Почему? Вообще похоже, что по ошибке поставили время, а не фактор замедления (291/227=1,28)

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.