Здравствуйте, AndrewVK, Вы писали:

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

AVK>Здесь не понял. То есть как это не позволяют?

Ключевые слова — "произвольного размера". То есть, позволяют, конечно же, но образно говоря, на уровне макрокосма (какой там размер страницы?).
На микроуровне (контейнеры и проч.) — это все-таки слишком дорого. Да, было бы конечно круто иметь такую возможность — не надо никаких реаллокаций, просто говоришь — "добавь-ка мне еще памяти". Но не факт, что это было бы лучше. Ключевой момент в автоматической сборке мусора — это именно SQUEEZE, которая четко работает за линейное время. За счет этого, куча в .Net всегда содержится в состоянии, близкому к идеальному порядку (я правильно понимаю?), в то время как defragment является NP-полной задачей — могу ошибаться, но уж точно не O(N).

Здравствуйте, McSeem2, Вы писали:

MS>Завсегда пожалуйста.
Шпасибо!

MS>Единственный неприятный момент — я мог где-то согрешить против истины, просто в силу того, то уже не помню конкретных цифр. Например, я не уверен, что модем работал на скорости 1200 бод, вроде-бы на 1200, но гарантии дать не могу.
Ну так... у меня, я думаю, ума хватит цифирьки проверить. Но они — не главное.

Здравствуйте, LaptevVV, Вы писали:

LVV>Только положительно, но тебе придется проверять конкретные цифры, если они возникнут...
Праверим-праверим Спасибо

Здравствуйте, SchweinDeBurg, Вы писали:

ЗХ>>С сохранением, естественно, авторства и вообще — на ваших условиях .
ЗХ>>Как на это смотрят авторы историй?

SDB>Да Бога ради. Взамен — экземпляр книжки с автографом.

Всенепременно

Здравствуйте, McSeem2, Вы писали:

MS>Ключевые слова — "произвольного размера". То есть, позволяют, конечно же, но образно говоря, на уровне макрокосма (какой там размер страницы?).

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

MS>На микроуровне (контейнеры и проч.) — это все-таки слишком дорого.

Что дорого? А какой размер страницы нужен? 1к, 4 байта, 1 байт, 1 бит? А, главное, зачем? Современные менеджеры памяти умеют выделять сразу большой кусок под мелкие выделения и особых проблем с размером страницы нет. Более того — даже если у нас будет эффективная реализация микространиц, все равно в какой то момент у тебя машина ляжет из-за огромных размеров таблицы маппинга.
Вобще, не все технологии старых машин применимы на сегодняшних. И дело даже не в неправильном векторе развития. Например красивый и простой способ реализации окошек в текстовом режиме для графики не годится и приходится рожать очень сложные графические движки. И если когда нибудь мы вернемся к той модели, то это будет стоить навороченнейших видеоускорителей и огромных объемов набортной памяти. Вобщем не все технологии масштабируемы.

MS> Да, было бы конечно круто иметь такую возможность — не надо никаких реаллокаций, просто говоришь — "добавь-ка мне еще памяти". Но не факт, что это было бы лучше. Ключевой момент в автоматической сборке мусора — это именно SQUEEZE, которая четко работает за линейное время.

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

Продолжим.

В 1974 году в Ташкенте проходила всесоюзная конференция по операционным системам. Приехали все тогдашние киты... Удивительно, но я совсем не помню докладов про ЕС ЭВМ... Наверное они были, но я не обратил внимание, так как в Институте Кибернентики Уз.ССР стояла БЭСМ-6, а ЕС еще не было. Вот на доклады об осях БЭСМ-6 я внимание обратил...
Тогда в Союзе было три школы по осям: В Москве, в институте прикладной математики создавали ось ИПМ на принципах максимального универсализма... Она не нашла большого распространения — время еще не пришло... А вот две других!... Одна — Ось "Дубна". Классная система, созданная в Дубне в ОИЯИ. Там в то время работала классная команда под руководством Говоруна. Они написали великолепный транслятор с Фортрана... Эти ребята исходили из своих потребностей, так и писали...
Третья система ОС ДИСПАК была создана под руководством Тюрина.. Не помню, но кажется из Челябинска (или из Свердловска — в общем, с Урала ) Эти ребята считали, что ось должна быть написана так, чтобы максимально использовать возможности аппаратуры... И это им удалось! ОС Диспак была самой распространенной осью на БЭСМ-6.
А сама машина была уникальной! Она была одноадресной, с регистром-сумматором. Длина слова — 48 разрадов. В слове помещалось 6 символов (уже 8-разрядных, но байта еще не было...), или целое или плавающее, или 2 команды по 24 разряда... А памяти помнится, было почти бесконечность — 32768 ячеек! Скорость была бешеная — миллион операций в секкунду... Регистровых. конечно... Кто не знает, для 60-х (да и для 70-х в СССР) годов это было ОЧЕНЬ МНОГО... В то время американская фирма CDC только начала выпускать CDC-6600 со скоростью порядка трех миллионов.

Пульт у нее был уж совсем похож на пульт космического корабля... Был он такой — закругленный... Если поставить крутящееся кресло — то можно снимать сцены: Капитан управляет полетом своего космического корвета. Лампочек было столько, что с помощью них высвечивалось слово "ЖДУ", если машине нечего было делать На этой машине я впервые познакомился с перфокартами.
В то время в Институте кибернетики было несколько разных компьютеров и на всех был фортран, только разный. И уже появилась ЕС 1020, но я пока на ней не работал... И вот дипломный мой проект состял в том, чтобы оттранслировать один фортран в другой... Вообще — это типичная задача тех лет. У моей шефини диссер был Алгэк-Алгол. Алгэк — это расширение Алгола, придуманное в СССР для решения экономических задач... Хотя я сейчас думаю, что содрали его просто с Виртовского Алгола-W. Но это ИМХО.
Из-за разной мощности компьютеров эти фортраны довольно здорово отличались друг от друга... Естественно, менее мощный переводился в более мощный. И делалось это на БЭСМ-6 на автоводе, как тогда называли ассемблер, БЭМШ. Колода состяла примерно из 1200 перфокарт. Это пачка высотой примерно сантиметров около 20. На одной перфокарте — одна команда... Но, формат свободный. Единственное ограничение — если нет метки, то надо было делать один пробел. А метку набивали с первой позиции. Естественно, кодировка была советская. но сейчас не скажу какая. Правда, в то время я еще не вырезал и не заклеивал дырки — это случилось позже, на ЕС ЭВМ.
Время заказывали за неделю вперед, и весь это огромный комп (8 или 16 лентопротяжек ростом примерно 2 метра, и еще масса шкафов... ) был в моем полном распоряжении! Я ставил колоду на перфоввод, он "глотал перфокарты со страшной скоростью, но все одно 1200 перфокарт — это довольно долго... Но после ввдоа последней карты мгновенно начинало печатать АЦПУ (алфавитно-цифровое печатающее устройство) — такова была скорость компа, что промежутка просто не было...
В общем я на этой дипломной работе еще и макробемш освоил — он на меня произвел неизгладимое впечатление... Вообще, мне видимо, здорово повезло, что я начинал писать программы на уровне команд машины — это здорово способствовало формированию алгоритмического мышления... Ведь любую формулу приходилось раскладывать по полочкам. и команды писать в нужном порядке, ибо компьютер о приоритетах операций ничего не знает... И это сразу как-то вправляло мозги в нужную сторону. Вот теперь думаю — а не начать ли мне ту же методику применять к студентам?

Здравствуйте, AndrewVK, Вы писали:

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

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

MS>>На микроуровне (контейнеры и проч.) — это все-таки слишком дорого.

AVK>Что дорого? А какой размер страницы нужен? 1к, 4 байта, 1 байт, 1 бит?

Наверное, 1 байт.

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

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

AVK>Современные менеджеры памяти умеют выделять сразу большой кусок под мелкие выделения и особых проблем с размером страницы нет. Более того — даже если у нас будет эффективная реализация микространиц, все равно в какой то момент у тебя машина ляжет из-за огромных размеров таблицы маппинга.

Ляжет. Но думаю, что это — вопрос времени. После dot-net нам предложат super-dot-net, где вместо существующей сейчас сборки мусора будет еще и дефрагментация. Шутка!

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

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

MS>> Да, было бы конечно круто иметь такую возможность — не надо никаких реаллокаций, просто говоришь — "добавь-ка мне еще памяти". Но не факт, что это было бы лучше. Ключевой момент в автоматической сборке мусора — это именно SQUEEZE, которая четко работает за линейное время.

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

Именно он и является ключевым. Можно и на C++ сделать модель, гарантирующую освобождение ненужной памяти, с подсчетом ссылок, например. Но много кайфа от этого не будет, наоборот — породит серьезные скрытые проблемы, хоть с той же фрагментацией. Возможность перемещать объекты (при автоматическом отслеживании data integrity) — является фундаментальной во всей схеме управления пямятью в dot-net. И только при наличии такой возможности можно себе позволить роскошь автоматического удаления ненужных объектов. Если не делать squeeze — все очень быстро встанет раком.

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

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

Кстати, шальная мысль (может и не по делу). Когда дело дойдет до издательства (или даже раньше) — может имеет смысл попробовать законтачить с Алексом Экслером? Не знаю, насколько это будет ему интересно, но думаю, что попробовать имеет смысл. Найти грамотное издательство на приемлемых условиях не так-то просто. Алекс в издательских делах человек опытный, у него, вроде как есть собственное издательство.

Здравствуйте, McSeem2, Вы писали:

MS>Кстати, шальная мысль (может и не по делу). Когда дело дойдет до издательства (или даже раньше) — может имеет смысл попробовать законтачить с Алексом Экслером? Не знаю, насколько это будет ему интересно, но думаю, что попробовать имеет смысл. Найти грамотное издательство на приемлемых условиях не так-то просто. Алекс в издательских делах человек опытный, у него, вроде как есть собственное издательство.

Кстати, дельно.
Я, в принципе, об издательстве задумываюсь; просто хочу прийти в него все же не с пустыми руками (то есть с какими-то уже готовыми кусками). По моим расчетам, ребром этот вопрос должен встать к весне.
Эту тему мы уже немножко с Валерием Викторовичем (Лаптевым) вентелировали; есть мнение, что серьезное издательство мне не доверится за малостью лет моих (а если увидят лично....)
Так что вопрос больной.

Здравствуйте, LaptevVV, Вы писали:

LVV>Вот теперь думаю — а не начать ли мне ту же методику применять к студентам?

ИМХО не стоит. Все эти знания о ассемблерах PDP-11, Z-80, 8080, x86, системах команд VLIW и прочая на практике почти невостребованны. Птица (ПТЦА) пожалуй даже полезнее будет.

Здравствуйте, 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>Память больше не ресурс?

В данном случае не память не ресурс, а адресное пространство не ресурс. Согласись, это не одно и то же.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, LaptevVV, Вы писали:

LVV>>Вот теперь думаю — а не начать ли мне ту же методику применять к студентам?

AVK>ИМХО не стоит. Все эти знания о ассемблерах PDP-11, Z-80, 8080, x86, системах команд VLIW и прочая на практике почти невостребованны. Птица (ПТЦА) пожалуй даже полезнее будет.
Не, имеется ввиду — ассемблерные вставки в С++ — формулы всякие вычислять...

Здравствуйте, LaptevVV, Вы писали:

LVV>Не, имеется ввиду — ассемблерные вставки в С++ — формулы всякие вычислять...

Ну и кому оно нынче надо?

Здравствуйте, Privalov, Вы писали:

P>Первое что я сделал — перевел на PC набор программ, работавших до этого на ЕС 1036. Мне это удалось без особых проблем. С тех пор я уверен, что переносимость между платформами вполне можно реализовать без всяких виртуальных машин и прочей лабуды.

Зато, реализовать ВМ гораздо проще, чем компилятор.

Здравствуйте, AndrewVK, Вы писали:

AVK>ИМХО не стоит. Все эти знания о ассемблерах PDP-11, Z-80, 8080, x86, системах команд VLIW и прочая на практике почти невостребованны. Птица (ПТЦА) пожалуй даже полезнее будет.

Тут дело не только в ассемблере. На мой консервативный взгляд, обязательно надо посвящять прежде всего в фундаментальные понятия, как то — дополнительный код, адресация, плавающая точка, последовательность операций. Конкретный ассемблер здесь ни при чем — можно взять, к примеру MSIL или любой другой псевдокод. Но обязательно надо дать почувствовать, что происходит на уровне ниже. Без этого — получаются недоучки, которые лихо шпарят формы мышью, но удивляются, когда при перемножении двух целых положительных чисел получается отрицательное значение (компьютер сломался!!!). Для финансовых расчетов — почему нельзя использовать плавающую точку для хранения сумм денег и т.д. Короче говоря, надо обязательно прорабатывать теорию. Например, один мой приятель с прикладной математики ННГУ (Нижний Новгород) чуть ли не целый семестр гоняет народ по базовым структурам данных — именно таким, как числа с плавающей точкой (кстати, на Фортране). У него студенты проходят "первичную обработку", закладку фундамента. Далее уже идут конкретные языки и прикладные направления (если Вове Савину не сдал, дальше тебе в программировании делать нечего).

Мне было гораздо проще, поскольку я имел представление о схемотехнике и о том, что же происходит на уровне ниже ассемблера. Не уверен, что надо уходить в такие дебри, но то, что эти знания были для меня полезными — это неоспоримый факт. Другое дело — надо быть реалистом и соотношениие стоимость/качество вряд-ли будет оптимальным, если начинать с электроники и схемотехники.

Здравствуйте, McSeem2, Вы писали:

MS>Тут дело не только в ассемблере. На мой консервативный взгляд, обязательно надо посвящять прежде всего в фундаментальные понятия, как то — дополнительный код, адресация, плавающая точка, последовательность операций.

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

MS> Конкретный ассемблер здесь ни при чем — можно взять, к примеру MSIL или любой другой псевдокод. Но обязательно надо дать почувствовать, что происходит на уровне ниже. Без этого — получаются недоучки, которые лихо шпарят формы мышью, но удивляются, когда при перемножении двух целых положительных чисел получается отрицательное значение (компьютер сломался!!!).

Недоучки получаются из неумения учится, а не из-за того что кто то когда то не пытался научить. Если у человека есть желание и потребность, то рано или поздно он разберется с тем что ему нужно. Главное чтобы на начальном этапе человек не занимался ерундой (у него просто нет еще умения понимать что ему нужно), а ассемблер это самое удачное средство для того чтобы заняться тем, чем не нужно. Новичек, как показывает практика, увидев ассемблер, изучает не алгоритмику и скушные команды ALU, а стремится изобразить что нибудь модное и хардкорное, типа драйверов с подержкой SSE3. И еще — изучение ассемблера без знания принципов построения цифровых автоматов вобще и процессоров в частности напоминает изучение черного ящика.

MS> Для финансовых расчетов — почему нельзя использовать плавающую точку для хранения сумм денег и т.д.

А при чем тут ассемблер? Предмет называется алгоритмы и структуры данных и преподается в профильных вузах довольно давно и на 1-2 курсе.

MS> Короче говоря, надо обязательно прорабатывать теорию.

А при чем тут ассемблер? Тем более что в IL, который ты упомянул, ничего про форматы плавучки ты не узнаешь, поскольку это примитивные для него типы данных.

MS>Мне было гораздо проще, поскольку я имел представление о схемотехнике и о том, что же происходит на уровне ниже ассемблера. Не уверен, что надо уходить в такие дебри, но то, что эти знания были для меня полезными — это неоспоримый факт. Другое дело — надо быть реалистом и соотношениие стоимость/качество вряд-ли будет оптимальным, если начинать с электроники и схемотехники.

Для меня они тоже были полезны. Тогда. А сейчас практически бесполезны.

Здравствуйте, McSeem2, Вы писали:

MS>Мне было гораздо проще, поскольку я имел представление о схемотехнике и о том, что же происходит на уровне ниже ассемблера. Не уверен, что надо уходить в такие дебри, но то, что эти знания были для меня полезными — это неоспоримый факт. Другое дело — надо быть реалистом и соотношениие стоимость/качество вряд-ли будет оптимальным, если начинать с электроники и схемотехники.

А еще можно начать с квантовой физики

Спсибо, Андрей! Извиняюсь, что своим провокационным вопросом отнял столько времени, но это было сказано хорошо!

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

Воот. О том и речь. Создай миллион файлов размером 1 байт. Сколько места понадобится? Но у нас, как правило, нет потребности в миллионе файлов по 1 байту, а вот потребность в миллионе объектов в памяти — есть. И чтобы каждый объект имел возможность расширяться без реаллокаций. Эх, мечты...

AVK>Да я вроде подробно объяснил.
[...skipped...]

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

Эвона как!!! Процессоры так обнаглели, что бедным программистам из Microsoft приходится из кожи лезть вон, чтобы загрузить всю эту бездонную прорву (вспомнился анекдот про мужика — "не знаю что там, но как оно сыр любит...").

AVK>Совсем свежий пример — современные десктопы оказались оснащены мощными графическими ускорителями, которые нигде кроме игрушек не используются (миф о 3D-визуализации бизнес-данных на офисных компах и 3D-интернете лопнул как мыльный пузырь). Оказалось тем не менее что благодаря сверхмощным сопроцесорам и огромным объемам набортной памяти можно вернутся к старой модели безоконных приложений, возложив проблемы работы с окнами на графический ускоритель. А заодно практически бесплатно приобретя возможность 3D выпендрежа вроде плавающих, извивающихся, вращающихся, переливающихся окон, motion blur и прочей муры. И вот мы уже видим Aqua на маках, а в перспективе Aero на PC.

Это отдельная песня, о которой я тоже имею некоторое представление. Может быть напишу как-нибудь — душа-то просит

AVK>Лично я совсем не жалею что не надо ковырять регистры видеоадаптера, писать куски на ассемблере, изучать малоисследованные фишки, обходится без 21 прерывания, поскольку оно тормозное и т.п. Нет, конечно когда в свое время я написал оконную библиотеку, работающую в режиме 90х25 символов без дублирующего 9 бита, благодаря чему графический мышиный курсор был честным, без волнышек, то это было круто.

Я до сих пор не могу толком сформулировать одну свою мысль, хотя суть ее кажется простой. Для примера — в текстовом режиме нафиг не уперся графический курсор. Не надо пытаться решать неуместные задачи, точнее говоря, можно, но лишь в качестве упражнения и, возможно, некого озорства. Но по большому счету — эмуляция графического курсора в текстовом режиме — это изврат. Да, помню такие времена — люди хвастались графическим курсором в текстовом режиме EGA, а на VGA он почему-то кривел...

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

Согласен. Но кто все это обеспечивает?

AVK>Еще один момент — этот процесс практически непрерывен, пока непрерывно увеличение мощностей компьютерных железок. Неделю назад забыли про прямое программирование котроллеров, позавчера про прерывания, вчера про ассемблер, сегодня про рукописную графику, звук, завтра забудем про управление ресурсами, сетевые протоколы. А взамен получаем GC, JIT, интеллектуальные ФС, паттерны, широкое использование метапрограммирования, Software Factories, громадные стандартные библиотеки, слоднейшие IDE и много другого.

О как! Прямо-таки апокалипсис! Но кто-то же должен программировать те самые контроллеры и изобретать GC и JIT?! Или оно само? Теоретически, я не исключаю и такого варианта, что само...
Навеяло диалог из Пелевина, Поколение "П"

   - Слушай, - сказал он, - я чего  понять  не  могу,  Вот,  допустим,
копирайтеры им всем тексты пишут. Но кто за тексты-то отвечает? Откуда
мы берем темы и как мы определяем, куда завтра  повернет  национальная
политика?
   - Большой бизнес, -  коротко  ответил  Морковин.  -  Про  олигархов
слышал?
   - Ага. И что они,  собираются  и  решают?  Или  в  письменном  виде
концепции присылают?
   Морковин зажал большим пальцем горлышко бутылки, потряс ее  и  стал
вглядываться в пузырьки  -  видимо,  его  что-то  захватывало  в  этом
зрелище. Татарский молча ждал ответа.
   - Ну как они могут где-то собираться, - отозвался наконец Морковин,
- когда их всех этажом выше делают.  Ты  же  сейчас  сам  Березовского
видел.
   - Ага, - вдумчиво  ответил  Татарский.  -  Ну  да,  конечно.  А  по
олигархам кто сценарии пишет?
   - Копирайтеры. Все то же самое, только этаж другой.
   - Ага. А как мы выбираем, что эти олигархи решат?
   - Исходя из  политической  ситуации.  Это  ведь  только  говорят  -
"выбираем". На самом деле особого выбора  нет.  Кругом  одна  железная
необходимость. И для тех, и для этих. Да и для нас с тобой.
   - Так что, олигархов тоже нет никаких? Но ведь у  нас  снизу  доска
висит - "Межбанковский комитет"...
   - Да это чтоб мусора уважали, - ответил  Морковин,  -  и  с  крышей
своей не лезли. Комитет-то мы межбанковский, это да, только все  банки
эти - межкомитетские. А комитет - это мы. Во как.
   - Понял, - сказал Татарский.  -  Кажется,  понял...  То  есть  как,
подожди... Выходит, что те определяют этих, а  эти...  Эти  определяют
тех. Но как же тогда... Подожди... А на что тогда все опирается?
   Не договорив, он взвыл от боли - Морковин изо всех сил ущипнул  его
за кисть руки - так сильно, что даже оторвал маленький лоскуток кожи.
   - А вот про это, - сказал он, перегибаясь через стол и заглядывая в
глаза Татарскому почерневшим взглядом, - ты не думай никогда.  Никогда
вообще, понял?
   - А как?  -  спросил  Татарский,  чувствуя,  что  боль  только  что
откинула его от края какой-то глубокой и темной  пропасти.  -  Как  не
думать-то?
   - Техника такая, - сказал Морковин. -  Ты  как  бы  понимаешь,  что
вот-вот эту мысль подумаешь в полном объеме, и тут же себя щипаешь или
колешь чем-нибудь острым. В руку, в ногу  -  неважно.  Надо  там,  где
нервных окончаний больше.  Типа  как  пловец  в  икру,  когда  у  него
судорога. Чтобы не утонуть. И потом, постепенно, у  тебя  вокруг  этой
мысли образуется как бы мозоль, и ты ее уже можешь без особых  проблем
обходить стороной. То есть ты чувствуешь, что она есть, но никогда  ее
не думаешь.  И  постепенно  привыкаешь.  Восьмой  этаж  опирается   на
седьмой, седьмой опирается на восьмой, и везде,  в  каждой  конкретной
точке в каждый конкретный момент, есть  определенная  устойчивость.  А
завалит делами, нюхнешь кокоса и будешь конкретные вопросы  весь  день
решать на бегу. На абстрактные времени не останется.
   Татарский залпом выпил остаток водки и несколько раз подряд ущипнул
себя за ляжку. Морковин грустно усмехнулся.

AVK>Хорошо это или плохо не знаю.

Как сказал LLeo в своем "овощном дозоре" — "Это не хорошо и не плохо. Это — удобрение"...
...Что-то меня сегодня прёт, как удава по стекловате. Вроде ничего подозрительного не курил...

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

На этот счет приведу другую цитату:

     Но  ведь  какая  штука,  спроси  любого  ублюдка  на  улице, что бы  он
предпочел: жить долго, но  скучно, или  коротко, но радостно? И  но  выберет
последнее. Ну да, не все. Но большинство!
     Так что? Все наркоманы? Пусть и в потенциале.
     Но, ***,  почему  этот  уличный опрашиваемый  не  согласится  на  такой
вариант: долго  и радостно?  А  потому,  что он думает,  что так не  бывает.
Столько  лет  все  рвались  к   счастливой   жизни,  что  абсолютно  в   ней
разуверились!

Почему именно "бурчать по поводу" или "скрипя зубами"? Что, третьего не дано? Лично я выбираю "осваивать без зубовного скрежета". Но по-буркивая, ибо нельзя терять критический взгляд на вещи...

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

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

Об том и речь! Прямая работа с указателями по большому счету не мешает автоматическому удалению. А вот чему она точно мешает — так это сохранению целостности данных при перемещении объектов в памяти.

В конце концов — GC не решает проблему утечки памяти! Vlad2 это прекрасно продемонстрировал в Янусе (когда забывал отписываться от событий). GC лишь автоматизирует этот процесс. А вот что действительно ценно — так это постоянное поддержание кучи в порядке. По этой, кстати причине, дот-нетовская аллокация работает в среднем быстрее, чем в C++. И это, соратники, наполняет нас невыразимым блаженством...

Здравствуйте, prVovik, Вы писали:

V>А еще можно начать с квантовой физики

Неплохая мысль! Особенно в свете модной науки о квантовых компьютерах и кубитах (надо ввести новый термин, из Кин-Дза-Дзы, КюБайт).

MS>> Короче говоря, надо обязательно прорабатывать теорию.

AVK>А при чем тут ассемблер? Тем более что в IL, который ты упомянул, ничего про форматы плавучки ты не узнаешь, поскольку это примитивные для него типы данных.

Наверное, ты прав. Ассемблер хорош лишь тем, что позволяет заглянуть под капот и наглядно увидеть, как двигаются поршни и клапаны, когда чего вспыхивает и толкает... Не уверен, что это так уж нужно современному водителю "моторова возидла"... Но еще раз повторю свою мысль — кто-то же должен придумывать новые клапана! Или оно само?