>>1258388 (OP)
Да, кстати, мне бы ещё CUDA прикрутить, и ресурсы вычислетиельные полностью использовать, а не а-ля Питон 19% от процессора максимум.

>>1258388 (OP)
Сишка, фортран и-и-и все

>>1258397
Хаскель и плюсы что?
Ассемблер и машкоды?

>>1258398
>Хаскель
Медленный, даже медленне питона, из-за ебанутой чистоты и ленивых вычислений.
>плюсы
Будешь юзать stl - соснешь с перфомансом (тебе же надо совсем быстро, так), а так можешь использовать как си с классами
>Ассемблер и машкоды?
Тебе байтоебствовать или считать?

>>1258388 (OP)
R, Julia

>>1258404
Я точно не знаю, но подозреваю, что Julia/Java в плане производительности сосёт.

Про R не знаю.

>>1258397
Встречал утверждения, мол, Фортран в математику быстрее, чем С, типа заточен под неё, но встречал и обратные утверждения, что на С всё быстрее, если руки откуда надо растут.

Ещё сразу стоит отметить, что Фортран, грубо говоря, мёртвый язык, и я пока сомневаюсь, что туда можно припилить CUDA без проблем.
Опять же не проверял, что так да как.

>>1258401
А R и Erlang, как?

>>1258418
Там все считается в быстрых нативных библиотеках, ты их дергаешь только.

>>1258424
Эрланг вообще про другое.

>>1258424
>R
Это для работы с данными, это не совсем числодробилка.
>Erlang
Это тоже не числодробилка, да и вообще медленнее жабы той же и нужен для других вещей.

>>1258421
>Ещё сразу стоит отметить, что Фортран, грубо говоря, мёртвый язык, и я пока сомневаюсь, что туда можно припилить CUDA без проблем.
https://developer.nvidia.com/cuda-fortran

>>1258429
>>1258431
Ок, спс, но Фортран или С брать?

>>1258435
Сишку юзай. Привычнее и понятнее.

>>1258436
А вдруг Фортран реально быстрее окажется для моих задач, я вот включу на недельку комп и будет он вычислять, на фортране может сделает, а на си вдруг так месяц придётся сидеть.
Или не может быть такого?

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

>>1258438
Вряд ли, современные кокомпеляторы сишки далеко шагнули вперед. Но если ты любитель обратной польской нотации, то можешь и фортран попробовать, ради интереса.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/fortran.html

>>1258441
пффф, проблема в том, что я вот пока вообще не курсах об этих языках, поэтому и спрашиваю.

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

>>1258443
Ну почитай, хули
https://habr.com/post/400523/

>>1258445
лол,
https://ru.wikipedia.org/wiki/Intel_Fortran_Compiler

оказывается быстрый компилер для фортран для Интел имеет лицензию фри для нонкомерц, проприетарная.

Я думаю, я беру С и gcc, только поэтому.
Не ожидал, что ИНтел такие жлобы, хах!
Надо же даже на сраном компиляторе для Фортнана пытаются до сих пор заработать.

>>1258443
Вот ты скажи лучше по своему опыту, что думаешь? С, да? Потому что популярней, а скорость примерно та же?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/fortran.html

Потыкал на тесты, местами C++ заметно опережает С, удивился даже. Больше, чем на секунду или две даже.
Т.е. в сумме может быть очень критично, типа раза в два быстрее будет работать С++, и это ещё неизвестно, как там будет с CUDA.
Может, он и умножение со степенями и тригонометрию даже быстрее считает, чем С?

>>1258388 (OP)
ASM если нужен максимум, либо сижка с пиздоном поверх

>>1258401
> Будешь юзать stl
CUDA если быстро.

PS: Для математики производительность не очень нужна. Тому же R и Matlab оно нахуй не упало. Совет даю исходя из того, что оп спрашивал про вычисление чего-то в риалтайме, как в играх или в симуляторах, например.

>>1258503
Это тебе кажется так. Когда всякие алгоритмы машинного зрения работают на больших видеофайлах, то они топовые процессоры поджаривают по полной.

>>1258505
А мне нужно астрономические цифры перебирать от и до, мне тоже производительность нужна.

В общем у меня вчера возникли вопросы тут насчёт производительности:
C VS C++ VS Fortran.

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

Как я понял, С в основном делает по тестам Фортран, Фортран лучше в паре тестов, но там какие-то крутые тесты же, может, они для меня вообще роли не играют.
А С++ местами заметно делает С, при этом С местами делает С++, но не так заметно.
Даже складывается впечатление из-за этих тестов, что лучше С++ брать, а не С, вроде быстрее они.

>>1258388 (OP)
Зонтик, залогиньтесь. Я нихуя не понял про Марс.

>>1258487
>ASM если нужен максимум

Хуяксимум.

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

>>1258569

Другое дело, что заставить компилятор видеть где можно оптимизировать тоже придется поебаться, расставляя все эти declspec и __attribute__

>>1258569
>>1258573
Но можно же для начала сделать программу на листе, всё подготовить, а потом набрать идеальную программу ноликами и единичками.
И она будет супербыстрой.

Тредж не будет полон без упоминания J.

>>1258468
Там разные компиляторы используются. Тебе никто не мешает сишный код прогнать через g++

>>1258393
ну если cuda - то си/плюсы точно, все числодробилки на них делают

олдовые наукофаги до сих пор че-то на фортране пишут

>>1258388 (OP)
ононе, а что ты посчитать-то хочешь?

>>1258393
да, кстати, писанина под куду - это вообще отдельная пляска с бубном, там надо понимать архитектуру очень хорошо чтобы ее эффективно использовать

нр есть библиотеки, в которых уже че-то написано, типа thrust

>>1258718
Зарплату свою. Там сотни тысяч в миллисекунду, скоро в 32битный регистр перестанет помещаться, вот и встал вопрос об эффективных вычислениях.

>>1258700
>тебя один только механизм MMU отжирает процентов 30

На самом деле не MMU, а механизм кеширования и увеличивающееся с каждым годом отставание скорости оперативной памяти от скорости CPU.

И спасает тут не байтодрочка, а правильные cache-friendly структуры данных , которые очень плохо вяжутся с ООП головного мозга.

>>1258720

Достаточно понимать, что GPGPU - это разворачивание цикла/операции map() по ядрам, и что параллельные там обрабатываемые данные причем быстро обрабатыва5емые только тогда, когда друг от друга соседние элементы не зависят, иначе ебля с атомиками и блокировками целых варпов, а логика там однопоточная.

>>1258714
А что разе он не заточен под плюсы, какая разница тогда? Каждая вещь для своего дела же, нет?

>>1258777
Для этих целей есть R.
Для этих целей есть специальные питоновские библиотеки.
https://ru.wikipedia.org/wiki/NumPy
https://ru.wikipedia.org/wiki/SciPy

А главное это все гуглится в течении нескольких секунд.
Оно тебе точно надо?

>>1258569
Ты там совсем даун чтоль? А компиляторы на чем пишутся? И кто, блять, сделал твои компиляторы? У ебанных школьников совсем обострение по сентябрю начинается.

>>1259009
> А компиляторы на чем пишутся?
Ты, блядь, не поверишь
https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
У ебаной первокурсоты совсем обострение по сентябрю начинается.

>>1259009
>А компиляторы на чем пишутся?

На абсолютно любых языках. Вангую, что прототип компилятора очередного языка в 99% случае писали раньше на перле и на сишке с применением flex и bison а сейчас пишут на питоне.

>>1258777
Ты бы объяснил, зачем тебе такая херня нужна, тогда бы тебе и посоветовали.

Wolfram Mathematica

>>1258388 (OP)
Си и фортран.
На чистом asm писать ни в коем случае не надо, это неэффективно, непереносимо, сложно. Современные компиляторы делают это гораздо лучше.
Оптимально будет писать на голом си (плюсы не надо, тянут за собой stl). inline, register.
Программы запускай под профайлером, самые нагруженные части кода перепиши на ассемблере.

>>1259009
>А компиляторы на чем пишутся?
В основном на окамле, хаскелее и с++. А что?

>>1258777
Если тебе надо лабу в универе сделать, то бери любой язык (про питон тебе правильно сказали тут >>1258884)
Если тебе по работе какое-то серьёзное дерьмо надо вычислять, то спроси коллег или сформулируй задачу более точно

>>1258388 (OP)
>Интересует работа с огромными числами
Если нужно лопатить bigint, тогда лишп или хачкель бери.