Ссылку на презентацию "Modern Garbage Collection in Theory and Practice" нашел в G+ ленте Сергея Теплякова. Вот слайды этой презентации:
По ходу просмотра слайдов ловил себя на мысли о том, что GC продвигался в мейнстрим под флагом упрощения разработки и уменьшения количества ошибок. Но в современных условиях, когда производительности софта опять стали уделять внимание, оказалось, что для ускорения приложения нужно хорошо разбираться в особенностях работы современных процессоров. О том, что оперативная память медленная, поэтому хорошо бы, чтобы данные оказывались в кэше. О том, что системы многоядерные и хорошо бы, чтобы исполняющиеся на разных ядрах задачи не конкурировали друг с другом за один и тот же фрагмент памяти (или даже за разные фрагменты, но находящиеся слишком близко друг к другу). О том, чтобы данные располагались в памяти последовательно и так же последовательно обрабатывались (и, как следствие, выделение и освобождение памяти чтобы происходило единовременно и последовательно, а не хаотично). И т.д. и т.п.
Т.е. даже работая близко к железу и держа все под контролем, геморроя у разработчиков требовательных к производительности приложений, и так хватает. А если еще они вынуждены бороться не только с особенностями железа, но и вынуждены считаться с тонкостями конкретного сборщика мусора в конкретной версии конкретной виртуальной машины... То все становиться намного интересатее и интересатее :)
Из чего следует вывод, что есть некий водораздел между задачами, в которых производительность не слишком важна. И тогда разработчику не суть важно, какой именно сборщик мусора, какие у него бывают задержки и пр. Или же производительность таки важна и лучше бы тогда работать на самом низком уровне (т.е. полностью самостоятельно управляя памятью), чтобы не бороться с особенностями поведения еще одного уровня абстракции.
Хотя я сейчас, наверное, какую-то глупость сказал. Ведь все равно все упирается либо в сидящего перед компьютером пользователя, либо в базу :)
Комментариев нет:
Отправить комментарий