История изменений
Исправление DonkeyHot, (текущая версия) :
Почему выгодно … развернуто … нищие сегменты
Всё правильно. За исключением одного. Не-нищие сегменты тоже выигрывают, экономя на полноценной разработке. Если не теряют больше на электричестве и факапах – что далеко не всегда.
и если ядро работает со своей областью памяти
Именно. Заставлять массового програмца думать о задержках при обращении к памяти – неконструктивно, он и без этого ошибок наделает на 2 багтрекера. Потому абстракции растут, производительность падает, и это выгодно.
что производители железа не могут …
… [b]продать[/b] сильно паралельное железо. Потому, что слабопаралельные программы не выигрывают от этого. Внезапно оказалось, что GIL весьма полезен – он заставляет кодеров учиться паралелить. И чем больше будут задержки, тем быстрее они научатся, т.ч. на разные компы и общаться TCPями. И снова получается QED :)
что удобство написания монолита теряется
Да, я говорил про «построение системы». Писать распределённый код таки сложнее(впрочем, не всегда заметно). Но чем усложнение от распаралеливания хуже усложнения от оптимизации производительности(которое, кстати, всегда)?
Раньше ты мог просто прочитать переменную или вызвать функцию
Да, и ленивые програмцы решли, что это бесплатно. А вот же, переменная в чужом кеше, и программа стоит а деньги текут. И пойди докажи, что это дебужить проще.
Ты, часом, не заметил, что отстаиваешь права ленивых кодеров, производить неэффективный код?
Исходная версия DonkeyHot, :
Почему выгодно … развернуто … нищие сегменты
Всё правильно. За исключением одного. Не-нищие сегменты тоже выигрывают, экономя на полноценной разработке. Если не теряют больше на электричестве и факапах – что далеко не всегда.
и если ядро работает со своей областью памяти
Именно. Заставлять массового програмца думать о задержках при обращении к памяти – неконструктивно, он и без этого ошибок наделает на 2 багтрекера. Потому абстракции растут, производительность падает, и это выгодно.
что производители железа не могут …
… [b]продать[/b] сильно паралельное железо. Потому, что слабобаралельные программы не выигрывают от этого. Внезапно оказалось, что GIL весьма полезен – он заставляет кодеров учиться паралелить. И чем больше будут задержки, тем быстрее они научатся, т.ч. на разные компы и общаться TCPями. И снова получается QED :)
что удобство написания монолита теряется
Да, я говорил про «построение системы». Писать распределённый код таки сложнее(впрочем, не всегда заметно). Но чем усложнение от распаралеливания хуже усложнения от оптимизации производительности(которое, кстати, всегда)?
Раньше ты мог просто прочитать переменную или вызвать функцию
Да, и ленивые програмцы решли, что это бесплатно. А вот же, переменная в чужом кеше, и программа стоит а деньги текут. И пойди докажи, что это дебужить проще.
Ты, часом, не заметил, что отстаиваешь права ленивых кодеров, производить неэффективный код?