Ускорение алгоритма

Ну-блин, давайте реально подходить к делу, зря наверное пишу...

Ну вот где реально нужен этот Си и ассемблер ?

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

- Малварная разработка:
Блин ну хз. Много также на С++ пишут, также ещё даже больше на всяких-там C#, PowerShell и прочее...

Поэтому Си, мне кажется такое себе, если вы конечно позиционируете себя каким-то очень низкоуровневым спецом, то может-быть, но в РФ это мало где нужно по факту.)

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

 

Ну я уже говорил об этом, но еще раз. В глобальном плане (не в головах спецов, а в реальной жизни) есть всего два типа задач cpu-bound и io-bound. Для io-bound задач подойдет любой язык, способный проводить асинхронный ввод/вывод, скажем Python или Elixir будет популярным выбором. Для cpu-bound задач желателен нативный язык (сишечка, плюсы, раст или ним), или язык с хорошим JIT-компилятором (JVM или CLR языки например или новомодная Julia). Язык - это инструмент, адекватный человек выбирает тот язык, который лучше подходит для решения проблемы. И во многих ситуациях время разработки и время отладки является более ценным ресурсом, чем память или скорость исполнения. И в этом нет ничего плохого, потребитель с большей охотой выберет софт, который будет работать чуть медленнее, но будет предоставлен ему быстрее и не будет падать из-за утечек памяти, юз афтер фри и других проблем. В частности поэтому наши васмовские спецы черствые булки без соли и доедают.

 

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

 

Ща Инде прийдет и всех вздрючит реализацией на ассемблере, максимально быстрый код....)))

Хотя может и не вздрючит, не факт что напишет лучше Си.

 

X-Shar,
Код на сишечке, кстате, совсем даже не оптимизирован. Это обычное решение "в лоб" уровня лабы первокурсника. И даже в таком виде оно уделывает модные прогрессивные в десятки раз. Разумному человеку тут сразу станет очевидна достоверность синтетически тестов, на которых петон в первую десятку с сишечкой попадает

 

Нет, не вздрючит, он даже не знал разницу между аверским эмулем и виртуальной машиной, "такой позор" (с).

 

Вообще может Intel parallel studio заюзать? не? ) Я как раз тренируюсь, давно профайлеры и прочее не юзал...
Когда то давно VX - Tune использовал для белого софта с расчётами, щас чутка все поменялось... Осваиваю.

 

X-Shar,

Оптимизация даёт эффект не на уровне инструкций обычно, а на системном уровне. К примеру используется какой то пайп вместо простого быстрого синхрона на системных примитивах - профайл упадёт на десятки сотни порядков и не важно на каком яп это собрано. Или например используется какая то апи гуя для обмена данными, вместо нэйтив обмена - это архитектурный косяк разраба, который создаёт тормоза.

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

 

Indy_, да, любой выполз в ядро вызывает тормоза , про пайпы (индусские поделки с которыми M$ Сам никак не разберется) я вообще молчу..
Вот как раз про циклы и мат вычисления я и имел ввиду.

 

под виртой и быстро

 

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

 

задача решена