Состоялся релиз системы для выполнения математических расчётов GNU Octave 7.1.0 (первый релиз ветки 7.x), предоставляющей интерпретируемый язык, во многом совместимый с Matlab. GNU Octave может использоваться для решения линейных задач, нелинейных и дифференциальных уравнений, вычислений с использованием комплексных чисел и матриц, визуализации данных, проведения математических экспериментов...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57000
С Matlab совместим на половину. Просто перебросив код вы сможете запустить большинство расчетов, только шрифты не определит. Когда делается рачтеты посложнее, лучшее переписать код заново под Octave. Я только начал осваивать Octave, как Matlab отозвал лицензию (
Может быть тогда объясните, в чём его фишка? Ради производительности и близкого синтаксиса с Matlab обычно переходят на Julia, при этом ещё получается существенный выигрыш в скорости. Аналога Симулинка вроде бы вообще нигде полноценного нет. По производительности Октав ещё медленнее Матлаба. Что в нём так привлекает?
> Что в нём так привлекает?наверное то, что что свободно и бесплатно, и лицензию не отзовут в силу не зависящих от простых смертных обстоятельств
Julia тоже свободная и бесплатная, лицензию тоже не отзовут. Так что этот аргумент не решает. Но вот со скоростью у Октава реально есть проблемы: https://julialang.org/benchmarks/Так что если осознанно переходить именно на него, то реально должна быть какая-то особая причина. Вот эта причина как раз и интересна, потому что обычно в обзорах пишут просто, что это свободный аналог Матлаба, и на этом всё
Октава для математических расчетов использует библиотеки BLAS.По умолчанию в ней задействована GNU Scientific Library (https://www.gnu.org/software/gsl/), которая предоставляет совместимую корректную реализацию, но не оптимизирована с точки зрения производительности.
Если заменить ее на MKL (для Intel), OpenBLAS собранный под свой процессор или вообще nvBLAS (если есть GPU от NVidia), то дела пойдут гораздо веселее.
Я бы не советовал менять blas библиотеку на MKL, по сравнению с openblas она дает менее 10% выигрыша, а вот на процессорах AMD деградация в скорости до 40%. MKL проприетарная библиотека со всеми вытекающими последствиями, скажу больше intel нaсрaлa еще в ядре linux и glibc, что процессоры AMD имели хуже производительность, но благо этот код последние годы вычищается.
Есть еще ArrayFire и использую его для расчетах на amd gpu. Все что связано с nvidia работает в linux значительно хуже AMD, дрова nv довольно кривые.
>https://julialang.org/benchmarks/
>Note that the Julia results depicted above do not include compile time.А с компиляцией? Просто интересно. По лицензиям - MIT против GPL. И у Julia есть морда? Octave это полноценная (ish) среда, а Julia только язык. Или я не правильно понимаю?
Я использую Octave именно потому что всё включено. Считать мне надо не много, но вспоминать каждый раз нюансы, а он мне и справочку и выхлоп покажет и т.д. Удобно.
>И у Julia есть морда?Есть Juno. Это вроде как IDE, но оно умеет рисовать графики. А еще есть поддержка Jupyter Notebook.
У Julia "официальное" рабочее окружение собирается из VSCode с соответствующими плагинами. Получается вполне удобная среда для научного программирования, вполне комфортная, функциональная, всё быстро работает. До позапрошлого года официальное окружение собиралось на основе Atom, кому не нравится VSCode - расширения под Atom тоже вроде бы все ещё живы. Наверняка есть какие-то расширения и для других IDE. Плюс интерактивные блокноты Jupyter и Juno - кому что больше нравится. Juno - удивительно хорош
Мне просто проще. Узнал об Octave, пока собирал материал по Matlab. Вот и решил попробовать. Для расчетов вузе прям уж очень продвинутого и производительного не нужно, ну или мои задачи не такие требовательные.
После ВУЗа времени на изучение чего-то нового может резко стать намного меньше. Так что имеет смысл сразу изучать конкурентоспособные технологии, владение которыми потом можно будет применить в реальной практике, которые помогут при устройстве на высокооплачиваемую работу
Matlab сказал россиянским предприятиям good by. Поэтому при устройсте на работу _любую_ _тут_ владение им уже не поможет.
Матлаб - собственнический продукт, который из года в год и так только теряет свою долю на рынке. Нынешние действия не добавят ему популярности ни в России, ни за рубежом. Его держат на плаву только объёмы уже написанного кода, который никто не хочет переписывать, написанные строго под него учебники и учебные занятия, ну и Симулинк. Под "конкурентоспособными технологиями" понимался конечно не он
> написанные строго под него учебникиГлядя на большинство институтов математики и информационных технологий, всё больше убеждаюсь в истинности подобных фраз. Учёба превратилась в кнопкотыкальство. По истечению ~четырёх лет обучения выпущенный студент сразу становится ненужным из-за устаревания того, что ему впихивали в голову.
Чтобы такого не случалась, не нужно учить студентов технологиям, которые устаревают. Все устаревающее стоит на плечах технологий неустаревающих. Вот этим технологиям и нужно учить. Студент, ежели пожелает, сможет самостоятельно изучить быстроустаревающие или юные технологии. Это, кстати, добавит ему полезных жопочасов помимо тех, на которых он будет изучать изнутри, например, работу динамического загрузчика или метод ISAM.
Вот уж что-что, а матлаб только студиозы используют.
Юзал джулию в таком режиме, в котором вы предлагаете. >95% времени уходит на JIT (простите, JAOT). Либо ты сильнее оптимизируешь JIT, и тратишь еще большую долю на компиляцию, либо все работает супер медленно, как на питоне. Пердолился, собирал системный образ, в который нужно не забыть скомпилять все нужные пакеты, потратив на это еще пол дня, ну тогда вот мой скрипт в 100 строк можно было запустить быстро. Надо было только скормить откомпилянный 1.2 GiB образ при запуске интерпретатора.
Зачем все это счастье простым пользователям, не тем кто на кластерах делает - непонятно.
А язык приятный, да. Но сырой - по крайней мере пакетный манагемент и попытки компиляции динамичекого языка.
> Юзал джулию в таком режиме, в котором вы предлагаете. >95% времени уходит на JIT (простите, JAOT).Значит она тебе и не нужна.
Юзал джулию для некоторых вычислений, разница с чистым питоном местами до 100 раз.
Компиляция медленная, да, но когда расчеты идут часами - это не имеет значения.
Если расчеты идут часами, имеет смысл потратить это время на фортран. В крайнем случае на си, что будет работать почти так же быстро.
скорей всего это будет ROOT
рут очень тяжёлый. с кондой его хотя бы можно быстро собрать, раньше на это уходило полдня, особенно, если не шаришь в процессах сборки.да, сейчас, 7 версия выглядит перспективно, где рут тим полностью отказались от всех самописных tobject и tlist итд в пользу stl и перешли на новый графический движок.
однако несмотря на все это, вообще не понимаю как им можно пользоваться после пого же пандас...
судя по тому, что я вижу, молодёжь в церне переходит на пайтон как в свое время с фортрана перешли на рут.
некоторые коллаборации например lhcb уже полностью клиент для анализа имеют на питоне, остальные огромные неповоротливые вынуждены поддерживать быдлософт на старом руте 5.34
Сомнительное предложение. Фортран может быть интереснее по потреблению памяти, по размеру бинарника, но явно не по скорости:https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Си обычно побыстрее, но тоже не всегда:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Но если мы говорим про общую экономию времени, то нужно учитывать не только сам запуск бинарника, но и скорость разработки. И здесь среди высокопроизводительных языков у Julia особо нет конкурентов
> Сомнительное предложение. Фортран может быть интереснее по потреблению памяти, по размеру
> бинарника, но явно не по скорости:
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> Си обычно побыстрее, но тоже не всегда:
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> Но если мы говорим про общую экономию времени, то нужно учитывать не
> только сам запуск бинарника, но и скорость разработки. И здесь среди
> высокопроизводительных языков у Julia особо нет конкурентовВсе зависит от того, что и как написано. Что касается вычислений с плавающей запятой, а фортран для другого не используется, то код на С, который грамотно использует restricted указатели на элементы массивов, иногда работает так же быстро, как фортрановский, но чаще всего немного отстает. Если использовать в си обычные указатели или оператор [] для доступа к элементам массивов, то код на си по производительности всегда отстает от фортрановского. Имеется в виду, что код не использует готовых библиотек, типа бласов и прочих лапаков, а исключительно сам всю линейную алгебру считает.
Что касается скорости разработки числодробилок, то 90% времени -- это программирование тестов и отладка целевого кода. Без отладки можно только хеловорлды писать. А сами формулы программируются одинаково по времени во всех ЯП, мало того, они вообще выглядят почти одинаково.
Кстати, как выглядит в вашей жулии возведение числа в степень, равную корню квадратному из трех?
Что такое JAOT?
Есть AOT и JIT, и это разные вещи и даже происходят на разных этапах.
Насчёт JIT вы в корне не правы, JIT код может быть даже быстрее кода на С. Насчёт предкомпиляции в julua, она в последних версиях стала очень быстрая, раньше да она медленная была, и это раздражало. Ничего там сырого нет, работает все хорошо, язык за последние года 2 стал практически идеальным. И не такой тошнотворный синтаксис как в том же R.
Есть гуй на гтк? Емакс не предлагать.
нафиг?
Несколько заинтригован. Это сказал человек - сторонник GTK? ;)
на самом деле сторонник лишь здравого смысла
Какого гуя вам ещё надо?
> Есть гуй на гтк? Емакс не предлагать.Любой редактор годится. Например, slickedit.
Раз это проект GNU, ориентированный на скриптование, а скриптование на Guile в нём поддерживается?
> Прекращена поддержка библиотеки Qt4"Ой, всё!" (с)
Добавлена поддержка qt2...
Scilab круче
> Scilab кручеМедленее, медленее и ещё раз медленее он (критически медленее). :)
Плюс от scilab только наличия xcos (некое подобие симулинка) :)
Интеграцию с sympy починили? Октава вообще покрывает 90% студенческих задач по численным рассчетам на матлабе, оставшиеся 10% это как раз где используется символическая алгебра.
Матлаб в символическую алгебру умеет настолько, наскольку в нее умеет ядро Maple, которое он использует.
Символическая алгебра -- это Maxima. Уровень, кстати, очень высокий. Что касается тензорных вычислений в индексах, то будет покруче Maple.
Хм, почитал комментарии, но мой вывод такой:Тут не попытка топить за что-то конкретное, каждому своё, что больше нравится.
Производительность на Ryzen 5 1600X в "попугаях" (:
octave 6.2
octave:1> N=10000;A=rand(N,N);b=rand(N,1);tic();x=A\b;toc()
Elapsed time is 5.87 seconds.julia 1.5.3
julia> N=10000;A=rand(N,N);b=rand(N,1);t0=time();x=A\b;time()-t0
7.421519994735718матлаб не стоит, но лет 7 назад, октава достойно соперничала. Некоторые операции делала быстрее, сейчас проверить не могу.
октаве, как и матлаб отлично векторизует операции. джулия векторно считает медленнее. Это, даже, в доке написано.
В октаве, там где требуется jit, не так много (по крайней мере для меня). В основном всё векторизуется, что позволяет более компактно и понятней оформлять скрипты.
Хороший пример, спасибо
Насчёт векторизации в julua, все зависит с какой blas библиотекой работает julua. Много нюансов при сборке, нельзя сказать, что julua медленнее. В julua есть к примеру arrayfire и на gpu amd можно ускорить вычисления.
Что-то не заметил, что кто-то медленнее или быстрее...octave:1> N=10000;A=rand(N,N);b=rand(N,1);tic();x=A\b;toc()
Elapsed time is 4.78836 seconds.julia> N=10000;A=rand(N,N);b=rand(N,1);t0=time();x=A\b;time()-t0
4.787189960479736julia> N=10000;A=randn(AFArray{Float64}, N,N);b=randn(AFArray{Float64}, N,1);t0=time();x=A\b;time()-t0
2.1178228855133057