Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Poopy Joe, Вы писали:

PJ>>Скорость работы ПО так же не определяется пряностью доступа к памяти.

_>Как раз определяется в очень большой степени. Потому что оперативная память — это жуткий тормоз по сравнению с процессором (хуже неё только IO). В какой-то степени эти тормоза компенсирует кэш процессора, но только в том случае, если им правильно пользоваться. Так вот, ФП как раз приводит к максимально не правильному использованию кэша...

Общая скорость определяется самым медленным элементом. Иногда это память, иногда процессор, но в 99% это IO. Именно оно и определяет в большей степени. Штука в том, что места где узкое место это числодробилка, они сами по себе небольшие, в сравнении с остальной частью, и часто имеют альтернативные решения в виде GPU или FPGA.

_>О, забавно. Ты тут умудрился в одном предложение и высказать абсолютно верное утверждение и наврать на 100%. В реальности практически любой канонический ФП код серьёзно ускорится при его умелом переписывание на императивном подмножестве C/C++.

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

_> Однако в 90% случае это просто не нужно, как раз потому, что этот код не является бутылочным горлышком (это не означает что он такой же быстрый, как на C/C++, а означает что его быстродействия хватает для выполнения бизнес-задач — быстрее просто не нужно).

Я ровно это и сказал. Хоть на ассемблере перепиши, если приложение ждет сетевой пакет, или просто реагирует на таймер, его общая скорость никак не изменится от переписывания. Где я тут чего наврал?