Re[8]: Как-бы продолжение...
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.01.05 17:15
Оценка: 180 (15)
Здравствуйте, McSeem2, Вы писали:

AVK>>4 или 8 килобайт. И я что то не слышал чтобы кто то считал его слишком большим.


MS>Это очень большой размер. Представь что будет, если понадобится миллион мелких независимых объектов, например, для дерева XML-DOM.


Я уже сказал — эту проблему давно научились решать весьма эффективно.

AVK>>А, главное, зачем?


MS>Можно вообразить и помечтать, что память представлет собой файловую систему, типа NTFS...


А в файловой системе точно так же пространство организовано ввиде страниц ака кластеров. В том числе и в NTFS.

MS>Ляжет. Но думаю, что это — вопрос времени.


Вряд ли. Сколько помню — память всегда была узким местом вычислительных систем.

AVK>>Вобще, не все технологии старых машин применимы на сегодняшних. И дело даже не в неправильном векторе развития. Например красивый и простой способ реализации окошек в текстовом режиме для графики не годится и приходится рожать очень сложные графические движки. И если когда нибудь мы вернемся к той модели, то это будет стоить навороченнейших видеоускорителей и огромных объемов набортной памяти. Вобщем не все технологии масштабируемы.


MS>Можно эту мысль по-подробнее? Она весьма интересна.


Да я вроде подробно объяснил. Хорошо, попробую иначе. Пусть у нас была некая система Х с вычислительной можностью 1 попугай, объемом памяти 1 удав, объемом диска 1 слон и размером фреймбуфера 4х3 мартышки. На нем присутствует некий софт со своими проектными решениями. Проходит время и у нас появляется система Y с вычислительной мощностью 10000 попугаев, объемом памяти 1000 удавов, объемом диска 10000 слонов и размером фреймбуфера 400х300 горилл.
Так вот — если мы попытаемся тупо перенести проектные решения, то результат будет печален. Дело в том что не все системы улучшились в одинаковое количество раз. И если на системе Х у нас все было более менее сбалансированно, то на новой процессор практически ненагружен, дискового пространства море, зато память вся забита и с графикой жуткие тормоза. Но это еще не все — потребности в отдельных ресурсах тоже растут неравномерно. В итоге имеем как правило упершуюся в какой то один ресурс систему. Выход один — менять проектные решения на более равномерно загружающие систему.
Перейдем от гипотетических рассуждений к конкретным примерам. Возьмем опять же те же окошки. При работе оконных систем основная проблема это отработка взаимно пересекающихся слоев. В текстовых режимах отсечение примитивно донельзя, а с отрисовкой все просто — запоминаем содержимое окна в массиве и когда нужно строим в фреймбуфере изображение. Но как только с текстового режима мы уходим на графику все становится намного сложнее. Отсечение уже требует отработки не только текста, но и различной геометрии. Содержимое всех окон в память не загонишь — памяти не хватит. А если вспомнить непрямоугольные окна, альфа-канал и т.д. то все становится еще интереснее.
Теперь еще ближе к практике. Возьмем JIT и GC. Применение подобных технологий на старых системах неоправдано, поскольку с процессором на них все очень печально и для обеспечения нормальной скорости реакции в интерактивном режиме приходилось потеть по полной — выдавливать из процесора все соки ценой ненадежности, неуправляемости, плохой масштабируемости, плохой переносимости кода. Те, кто давно компами занимается наверное помнит что незапускающаяся из-за каких то несовместимостей программа была вполне обычным явлением. Но с пересечением процессорами некоторой черты (где то 300-500МГц) они перестали быть узким местом. Для современных настольных систем производительность процессора на многих задачах сверхизбыточна. И даже если мы напишем софт по старинке — с морем оптимизаций и хардкода, ничерта это не даст в потребительском плане. Вот JIT и GC как раз и утилизируют эту лишнюю процессорную мощность.
Совсем свежий пример — современные десктопы оказались оснащены мощными графическими ускорителями, которые нигде кроме игрушек не используются (миф о 3D-визуализации бизнес-данных на офисных компах и 3D-интернете лопнул как мыльный пузырь). Оказалось тем не менее что благодаря сверхмощным сопроцесорам и огромным объемам набортной памяти можно вернутся к старой модели безоконных приложений, возложив проблемы работы с окнами на графический ускоритель. А заодно практически бесплатно приобретя возможность 3D выпендрежа вроде плавающих, извивающихся, вращающихся, переливающихся окон, motion blur и прочей муры. И вот мы уже видим Aqua на маках, а в перспективе Aero на PC.
Поэтому когда начинают разговоры о том что раньше воздух был чище, а трава зеленее, то чаще всего это означает одно — старые ориентиры устарели, а новых тот кто сокрушается не видит.
Лично я совсем не жалею что не надо ковырять регистры видеоадаптера, писать куски на ассемблере, изучать малоисследованные фишки, обходится без 21 прерывания, поскольку оно тормозное и т.п. Нет, конечно когда в свое время я написал оконную библиотеку, работающую в режиме 90х25 символов без дублирующего 9 бита, благодаря чему графический мышиный курсор был честным, без волнышек, то это было круто. Но заниматься этим на современных компах, когда функциональная сложность фофанного януса выше чем сложности многих тогдашних больших коммерческих систем? Выглядит как неумная забава.
Еще один момент — этот процесс практически непрерывен, пока непрерывно увеличение мощностей компьютерных железок. Неделю назад забыли про прямое программирование котроллеров, позавчера про прерывания, вчера про ассемблер, сегодня про рукописную графику, звук, завтра забудем про управление ресурсами, сетевые протоколы. А взамен получаем GC, JIT, интеллектуальные ФС, паттерны, широкое использование метапрограммирования, Software Factories, громадные стандартные библиотеки, слоднейшие IDE и много другого. Хорошо это или плохо не знаю. С одной стороны обидно что то, что ты вчера делал огромными усилиями, сегодня может любой студент. С другой стороны стоять на месте смерти подобно. Вобщем каждый решает для себя, что ему делать — бурчать по поводу нынешних нравов и всеми силами противодействовать новому или, скрипя зубами, начинать все по новой.

AVK>>Ключевым я бы его называть не стал. Просто один из бенефитов GC. Ключевой момент это гарантия освобождения ненужной памяти.


MS>Именно он и является ключевым. Можно и на C++ сделать модель, гарантирующую освобождение ненужной памяти,


Нельзя. Не существует способа запретить на С++ прямую работу с указателями.

MS> с подсчетом ссылок, например.


А с подсчетом ссылок например вобще нельзя. Проблема циклических графов хорошо известна.

MS> Но много кайфа от этого не будет, наоборот — породит серьезные скрытые проблемы, хоть с той же фрагментацией.


Ты часто на практике сталкивался с проблемами фрагментации адресного пространства?

MS> Возможность перемещать объекты (при автоматическом отслеживании data integrity) — является фундаментальной во всей схеме управления пямятью в dot-net.


Там много подобных фишек. GC решает значительно больше задач, нежели дефрагментация кучи.


AVK>>В любом случае даже при современных 2Г адресного пространства проблема его фрагментации стоит перед относительно небольшим процентом приложений, а с переходом на 64 бита такой проблемы просто не станет.


MS>Память больше не ресурс?


В данном случае не память не ресурс, а адресное пространство не ресурс. Согласись, это не одно и то же.
... << RSDN@Home 1.1.4 beta 3 rev. 272>>
AVK Blog
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.