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

Это понятно. Но всё равно один и тот же алгоритм на списках всегда будет медленнее, чем на массивах/указателях.

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

С точки зрения процессора, лучше помолотить побольше команд, но над более локальными/компактно расположенными данными.

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

Я когда работал в EMC, у нас в середине 10-х годов присутствовал код, написанный в 84-м. Когда падал процесс с RSS 700 Гб, 120 мб страниц исполняемого кода и 15000 тредов, то стек-фреймы были глубиной больше 90.

В основном, код был на C++, но его было 15 млн. строк и 30 лет истории. Полностью с нуля сборка делалась за три, что ли, дня. Даже запускался на системе до полностью готового вида где-то 10-15 минут.

Переписать нереально: слишком много ресурсов уйдёт, плюс клиенты покупали не за скорость, а за стабильность.

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

Это понятно. Но всё равно один и тот же алгоритм на списках всегда будет медленнее, чем на массивах/указателях.

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

С точки зрения процессора, лучше помолотить побольше команд, но над более локальными/компактно расположенными данными.

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

Я когда работал в ECM, у нас в середине 10-х годов присутствовал код, написанный в 84-м. Когда падал процесс с RSS 700 Гб, 120 мб страниц исполняемого кода и 15000 тредов, то стек-фреймы были глубиной больше 90.

В основном, код был на C++, но его было 15 млн. строк и 30 лет истории. Полностью с нуля сборка делалась за три, что ли, дня. Даже запускался на системе до полностью готового вида где-то 10-15 минут.

Переписать нереально: слишком много ресурсов уйдёт, плюс клиенты покупали не за скорость, а за стабильность.

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

Это понятно. Но всё равно один и тот же алгоритм на списках всегда будет медленнее, чем на массивах/указателях.

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

С точки зрения процессора, лучше помолотить побольше команд, но над более локальными/компактно расположенными данными.

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

Я когда работал в ECM, у нас в середине 10-х годов присутствовал код, написанный в 84-м. Когда падал процесс с RSS 700 Гб, 120 мб страниц исполняемого кода и 15000 тредов, то стек-фреймы были глубиной больше 90.

В основном, код был на C++, но его было 15 млн. строк и 30 лет истории. Полностью с нуля сборка делалась за три, что ли, дня. Даже запускался на системе до полностью готового вида где-то 10-15 минут.

Переписать нереально: слишком много ресурсов, уйдёт, плюс клиенты покупали не за скорость, а за стабильность.

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