LINUX.ORG.RU

История изменений

Исправление Legioner, (текущая версия) :

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

Это абстрактная теория, к реальности никак не относящаяся. В реальности ручной код на ассемблере будет тормозной у большинства программистов. Потому, что на ассемблере писать идеально быстрый код сложно, почти невозможно, слишком много всего надо учитывать (для компилятора как раз это несложно). На ассемблере пишут код в основном в тех случаях, когда компилятор не умеет использовать какие-то новые инструкции. Чаще всего это векторный код. И на ассемблере там буквально несколько десятков инструкций будет.

Что касается С++. В среднем он будет быстрей любого другого языка кроме, разве что, С. Но быстрей ненамного. И не факт, что это ускорение вообще кому-то нужно. Простой пример - веб-сервер. Он принимает запрос, парсит его из текста в структурированные данные, потом делает запрос в СУБД. Ждёт 100 мс, принимает ответ от СУБД и отсылает его клиенту. Если ты напишешь всё на С++, то запрос будет отрабатывать за 101 мс (100 мс на запрос в СУБД, 1 мс на всё остальное). Если ты напишешь всё на Python, то запрос будет отрабатывать за 103 мс (если считать, что Python в 3 раза медленней). Если ты напишешь всё на Java, то запрос будет отрабатывать за 101.3 мс. Вот примерно такой порядок величин будет в реальном софте.

А тут оказывается Python в большинстве софта используется

Это неправда. Python используется много где, но всё, что действительно должно работать быстро, написано на C/C++ и тд. И производительность обвязки на Python тут вообще ни на что не влияет.

это поэтому всё становится таким тяжёлым и тормозным?

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

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

Нет. Упрощение написания кода приводит к удешевлению кода. Это и есть улучшение кода. А если ты улучшаешь производительность, которая никому не нужна, это ухудшение кода. У тебя есть определённое железо, на которое ты ориентируешься. Ты не ориентируешься на 8086 процессор с 512 KB оперативной памяти. На такой процессор можно ориентироваться, но тогда код будет плохой и функционал будет куцый. Куда лучше провести исследование рынка, выяснить, какое реально железо у большинства интересующих тебя людей и ориентироваться на это железо. Именно так и делают большинство компаний.

Исходная версия Legioner, :

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

Это абстрактная теория, к реальности никак не относящаяся. В реальности ручной код на ассемблере будет тормозной у большинства программистов. Потому, что на ассемблере писать идеально быстрый код сложно, почти невозможно, слишком много всего надо учитывать (для компилятора как раз это несложно). На ассемблере пишут код в основном в тех случаях, когда компилятор не умеет использовать какие-то новые инструкции. Чаще всего это векторный код. И на ассемблере там буквально несколько десятков инструкций будет.

Что касается С++. В среднем он будет быстрей любого другого языка кроме, разве что, С. Но быстрей ненамного. И не факт, что это ускорение вообще кому-то нужно. Простой пример - веб-сервер. Он принимает запрос, парсит его из текста в структурированные данные, потом делает запрос в СУБД. Ждёт 100 мс, принимает ответ от СУБД и отсылает его клиенту. Если ты напишешь всё на С++, то запрос будет отрабатывать за 101 мс (100 мс на запрос в СУБД, 1 мс на всё остальное). Если ты напишешь всё на Python, то запрос будет отрабатывать за 103 мс (если считать, что Python в 3 раза медленней). Если ты напишешь всё на Java, то запрос будет отрабатывать за 101.3 мс. Вот примерно такой порядок величин будет в реальном софте.

А тут оказывается Python в большинстве софта используется

Это неправда. Python используется много где, но всё, что действительно должно работать быстро, написано на C/C++ и тд. И производительность обвязки на Python тут вообще ни на что не влияет.

это поэтому всё становится таким тяжёлым и тормозным?

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

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

Нет. Упрощение написания кода приводит к удешевлению кода. Это и есть улучшение кода. А если ты улучшаешь производительность, которая никому не нужна, это ухудшение кода. У тебя есть определённое железо, на которое ты ориентируешься. Ты не ориентируешься на 8086 процессор с 512 KB оперативной памяти. На такой процессор можно ориентироваться, но тогда код будет плохой и функционал будет куцый. Куда лучше провести исследование рынка, выяснить, какое реально железо у большинства интересующих тебя людей и ориентироваться на это железо. Именно так и делают большинство компаний.