LINUX.ORG.RU

В MIT разработали новый язык программирования

 , simit, ,


3

7

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

Язык программирования Simit основан на обратимом автоматическом переводе низкоуровневого описания алгоритмов в высокоуровневое, или графиков в матрицы, с помощью численных методов линейной алгебры. Дальнейшее моделирование не требует от программиста дополнительного переключения и предполагает традиционное написание кода только на языке линейной алгебры. Программы, написанные на Simit, могут работать на обычных (CPU) и графических (GPU) микропроцессорах без адаптации кода.

Вместе с тем новый язык отличается высокой скоростью выполнения алгоритмов. Тесты показали, что на GPU код Simit работает в 4–20 раз быстрее, чем на CPU. Скорость написания кода на Simit в десятки и сотни раз превзошла показатель других языков научного программирования. По словам исследователей, такого результата удалось достичь за счет повышения производительности языка: для выполнения одного и того же алгоритма ему потребовалось 0,1 от стандартного объема кода.

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

Участие в разработке Simit принимали ученые из MIT, Калифорнийского университета в Беркли, Торонтского университета, Техасского университета A&M, Техасского университета в Остине, а также исследователи из компании Adobe Systems Inc.

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

GitHub

Источник

Примеры кода и описание языка

>>> Подробности

☆☆

Проверено: Falcon-peregrinus ()
Последнее исправление: unfo (всего исправлений: 2)

Тесты показали, что на GPU код Simit работает в 4–20 раз быстрее, чем на CPU.

Было бы странно, если бы наоборот.

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от Esper

Для кодогенерации совершенно безразлично, писать там write("...;") или write("...\n").

Для конференций... честно говоря не пойму, зачем там. Писать «foo(bar); foo(baz)» в одну строчку чтоб в слайд влезло? Сомнительно, это ж конференция, всё должно красиво быть.

khrundel ★★★★
()

Эх, мне бы этот язык лет 20 назад, когда надо было векторы и матрицы перемножать... :-) Сколько человеко-часов бы сэкономил. Но с другой стороны практического опыта было бы меньше.

А теперь — где бы его вредн...тьфу!...внедрить?

DeVliegendeHollander ★★
()
Ответ на: комментарий от DeVliegendeHollander

Эх, мне бы этот язык лет 20 назад, когда надо было векторы и матрицы перемножать

Штоу? В 96 ооп не было, операторы не перегружались?

TooPar
()
Ответ на: комментарий от RazrFalcon

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

anonymous
()

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

Zeta_Gundam
()
Ответ на: комментарий от Zeta_Gundam

так им денег не дадут.

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

i36_zubov
()

Заголовок - желтизна!

h4tr3d ★★★★★
()
Ответ на: комментарий от anonymous

Чуть ли не единственный человек в треде, кто прошёл по ссылкам и почитал перед тем, как что-либо писать.

nezamudich ★★
()

Надо же, кому-то в двадцать первом веке пришло в голову делать язык программирования не под JVM.

CARS ★★★★
()

лень искать, но каким макаром оно выполняется на гпу? нужен опенкл? или оно сразу компилируются в код для amdgpu или nvptx?

Novell-ch ★★★★★
()
Ответ на: комментарий от StReLoK

Ну я тоже табофил. Его ведь для этого и придумали.

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

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

Собственно, еще в 2000 Джейми Завински по косточкам разобрал эту ситуацию:

My opinion is that the best way to solve the technical issues is to mandate that the ASCII #9 TAB character never appear in disk files: program your editor to expand TABs to an appropriate number of spaces before writing the lines to disk.

northerner ★★★
()
Последнее исправление: northerner (всего исправлений: 1)
Ответ на: комментарий от anonymous

Ты, конечно, много компиляторов разработал на базе LLVM и хорошо понимаешь какой это объем работ --- портировать, скажем, с 3.4 на 3.6 что-то сильно завязанное на API векторизатора, например.

мы делаем так: каждое божье утро чекаутим develop базовых проектов, и нашего проекта тоже. И мерджим, если есть конфликты. Читаем важные коммиты. Это правило номер 1, если несколько дней не мерджиться с develop, то есть шанс не смерджиться с develop больше никогда. (Нарочно использовано слово «develop» вместо «master», ибо мастер у нас имеет специальное значение)

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)

Кому-то сильно захотелось типизированный питон без табов)))

anonymous
()

массивы как в C или как в фортране?

и главный вопрос: умеет ли оно на видеокартах параллелить алгоритмы сложнее чем a=b+c

Slackware_user ★★★★★
()

Очереднойненужный язык №49823.

bs1988
()
Ответ на: комментарий от anonymous

нет, мы же на jvm, нет vm кроме jvm и java пророк её. На базе других фреймворков, которые часто меняются. Вот только сегодня корный коммитер поменял компонент, куда мы внесли кучу своих правок (и не заливали в апстрим - апстриму наши правки не нужны). Фигак, а там в файлах всё совсем другое. Мыло-мочало, начинай всё сначала - надо адаптировать наш код под эти правки. Но пока это всего несколько файлов - можно налечь и переинтегрироваться. А если постоянно сидеть на релизе, то взяв новую версию будет проще всё выбросить и написать заново - а на «написать заново» денег никто не даст - так и будешь всю жизнь на тухлятине багованой сидеть.

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

нет, мы же на jvm, нет vm кроме jvm и java пророк её. На базе других фреймворков, которые часто меняются.

Всё понятно, уровень сложности используемых компонент совсем не тот. Приходи когда пару компиляторов на базе LLVM напишешь, хотя бы относительно простеньких, но с какой-нибудь фишкой.

А если постоянно сидеть на релизе, то взяв новую версию будет проще всё выбросить и написать заново - а на «написать заново» денег никто не даст - так и будешь всю жизнь на тухлятине багованой сидеть.

Я бы не сказал, что стабильные релизы LLVM, это багованная тухлятина. Фреймворки на которых вы сидите --- вполне может быть.

Фигак, а там в файлах всё совсем другое. Мыло-мочало, начинай всё сначала - надо адаптировать наш код под эти правки.

Ну, зато тебе есть чем заняться, судя по всему. Давай дальше мержи каждый день.

anonymous
()
Ответ на: комментарий от stevejobs

полностью поддерживаю i_gnatenko_brain

Любому важна поддержка такого наркомана, как ты.

tailgunner ★★★★★
()

вот когда они на этим «семите» перепишут фортрановские математические библиотеки - тогда посмотрим. в основном же новые языки как-то не выходят за пределы узких кружков фанатов-любителей.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

вот когда они на этим «семите» перепишут фортрановские математические библиотеки - тогда посмотрим.

Ещё один иксперт подтянулся: зачем при помощи нишевой системы моделирования на графах переписывать фортрановские математические библиотеки? Где такую дурь отсыпают?

anonymous
()
Ответ на: комментарий от anonymous

Всё понятно, уровень сложности используемых компонент совсем не тот. Приходи когда пару компиляторов на базе LLVM напишешь,

зачем мне компилятор на базе какого-то llvm, если у нас виртуальная машина поверх другой виртуальной машины (jvm), и для неё язычок код на котором рисуют мышкой в Еклипсе? Нет бога кроме jvm и джава пророк её :)

твоё самомнение пылает и слепит как свет тысячи солнц =)

олсо, я не совсем понимаю, в чем сложность писать компиляторы именно поверх llvm. Это ваше llvm такое говно, что на нём технически невозможно просто работать, нужно жестоко пердолиться?

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 2)
Ответ на: комментарий от northerner

то _любые символы табуляции_ в файлах исхоного кода неизбежно ведут к необходимости введения пачки общих соглашений о форматировании кода табами и настройках IDE,

не нужно смешивать «красивое» выравнивание на некратное количество символов в отступе и отступы. и проблем не будет. семантика таба замечательно отвечает отступам вложенных конструкций. а в целом - ерунда это всё. лишь бы один стиль был. у меня исторически есть личные проекты и с табами и с пробелами. не напрягает одновременно кодить и так и так. и переделывать их под что-то одно не собираюсь.

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

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

dzidzitop ★★
()

end.. end.. end.. дальше не смотрел

barberry ★★
()
Ответ на: комментарий от anonymous

лучше форматирование закрепить в грамматике, как в go, и неправильно отформатированная программа будет просто не компилироваться.

А по факту получится как питон — компилируется, но выполняется какая-то херня.

anonymous
()

Вот это да!

Выше релиз Golang 1.7!

anonymous
()
Ответ на: комментарий от kedr

Пробел хорош тем, что ты уверен в его размере. Таб плавает от настроек.

Ты там выравниваешь что ли? Сначала придумывают наркоманские практики, а потом отступы делать не могут.

anonymous
()
Ответ на: комментарий от khrundel

Практика писать несколько инструкций в одну строку не то что бы сильно распространена и не то что бы достойна поощрения.

К сожалению программы не пишутся сразу из головы в один заход. Гораздо быстрее и удобнее писать, когда язык в процессе разработки позволяет насрать на выравнивание и лепить 9000 инструкций в одну строку, а потом применить автоформатирование. Без точки с запятой и выделения блоков {}, а не отступами, так не получится. Для школьников сойдёт, конечно.

no-such-file ★★★★★
()

Чего они haskell до ума не доведут, чтобы быстро работал? Вот на чём приятно описывать математику.

swar0g ★★★★
()
Ответ на: комментарий от swar0g

Потому что для погромирования на хаскеле нужно для начала поехать крышей. А тут всё просто и понятно.

StReLoK ☆☆
() автор топика
Ответ на: комментарий от swar0g

а где он пашет медленно? А то я чёт пропустил.

kedr
()
Ответ на: комментарий от Iron_Bug

для графов можно на С писать.

Да чего уж там, можно и на ассемблере писать. Вопрос в том, нужно ли...

anonymous
()
Ответ на: комментарий от stevejobs

зачем мне компилятор на базе какого-то llvm, если у нас виртуальная машина поверх другой виртуальной машины (jvm), и для неё язычок код на котором рисуют мышкой в Еклипсе? Нет бога кроме jvm и джава пророк её :)

Например, чтобы разбираться немного в примере обсуждения. Касательно язычка, сочувствую вам, а ведь есть люди, которые просто пользуются MPS.

олсо, я не совсем понимаю, в чем сложность писать компиляторы именно поверх llvm.

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

anonymous
()
Ответ на: комментарий от anonymous

А что в этом богомерзкого? :)

anonymous
()
Ответ на: комментарий от i36_zubov

Что тебе в этом примере напомнило паскаль, болезный?

Хотя ... судя по твоим другим комментам ты просто дурачок с С++ головного мозга.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.