Сага о ферритовых кольцах

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

Сага о ферритовых кольцах Феррит, Оперативная память, Олдскул, Раритет, Длиннопост

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

Сага о ферритовых кольцах Феррит, Оперативная память, Олдскул, Раритет, Длиннопост

Внешний вид. 8 банок по 1024 колечка в каждом — образуют 8х1024 бита или один килобайт.

А это один из банков крупным планом. Какой бисер, а ведь это все вручную собиралось!

Сага о ферритовых кольцах Феррит, Оперативная память, Олдскул, Раритет, Длиннопост

Если выше плашка оперативки, то ниже "память в кубе" с несколько иным плетением.

Кубик состоял из 18 рамок, в каждой из которых было 4096 ферритовых колечек, сгруппированных в группы по 256 (квадратами 16*16). Итого 4096*18/8=9216 байт памяти.

Сага о ферритовых кольцах Феррит, Оперативная память, Олдскул, Раритет, Длиннопост

Одной из фишек этой памяти то, что она может довольно длительное время хранить информацию без электричества — несколько суток. Это было полезно, когда компы были на лампах и часто ломались, чтобы не терять результат вычислений, а потом продолжить с этого же места. Такой вот хибернейт :)

Сага о ферритовых кольцах Феррит, Оперативная память, Олдскул, Раритет, Длиннопост

Вот матрица ферритовой памяти суперкомпьютера CDC 6600 (1964). Размер 10,8 × 10,8 см, ёмкость 4096 бит. Посмотрите на нее.

Сага о ферритовых кольцах Феррит, Оперативная память, Олдскул, Раритет, Длиннопост

Сравните масштабы и какое терпение должно быть у тех женщин, которые плели оперативку, словно фенечки бисером современные девушки. Да-да, такую работу поручали нашим дамам. 

Сага о ферритовых кольцах Феррит, Оперативная память, Олдскул, Раритет, Длиннопост

В марте 1950 года Форрестер со своей командой разработал ферритовую память, а в мае 1951 года Форрестер подал заявку на патент, и получил его в 1956 году. 

Но время идет, и в 1970 году Intel выпустила память DRAM на полупроводниковой микросхеме. В отличие от памяти на магнитных сердечниках, память на микросхемах не требовала мощного источника питания при работе и кропотливого ручного труда при производстве, а её ёмкость росла экспоненциально согласно закону Мура. Таким образом в 1970-х годах память на магнитных сердечниках была вытеснена с рынка.

Сага о ферритовых кольцах Феррит, Оперативная память, Олдскул, Раритет, Длиннопост

Однако, в отличие от полупроводников, магнитные сердечники не боялись радиации и ЭМИ, и поэтому память на магнитных сердечниках некоторое время продолжали использовать в военных и космических системах — в частности, её использовали в бортовых компьютерах Шаттлов до 1991 года.


Вот и саге конец, кто не понял - молодец!

Сага о ферритовых кольцах Феррит, Оперативная память, Олдскул, Раритет, Длиннопост
Вы смотрите срез комментариев. Показать все
27
Автор поста оценил этот комментарий

Фак мой мозг, 9216 в здоровенном кубе, 9216, Карл. А сейчас приложка начала жрать лишний гиг памяти по не понятным причинам - да и хуй с ним, в спецификации сказано что надо минимум 6 гб. А на серваках у кастомеров обычно и по 32 стоит. Это я к чему - как они тогда работали на таких машинах...

раскрыть ветку (26)
25
Автор поста оценил этот комментарий
Преподы в инсте рассказывали. Как они в очередь записывались к компу. А код свой на бумаге сперва в блок схемах рисовали. Потом писали. И только после этого получали доступ к компу. И на перфоленту потрм все сохраняли)
раскрыть ветку (3)
17
Автор поста оценил этот комментарий

Код и сейчас надо в блок- и прочих схемах/диаграммах продумывать, как и архитектуру на различных уровнях в целом, прежде чем бросаться сочинять :) Одно из отличий программиста от быдлокодера.

раскрыть ветку (1)
7
Автор поста оценил этот комментарий

Есть разные подходы к программированию.

Автор поста оценил этот комментарий

Попытка только одна была, это сейчас можно тестить и фиксить.

11
Автор поста оценил этот комментарий
Это я к чему - как они тогда работали на таких машинах...

Ни в чем себе не отказывали.

Иллюстрация к комментарию
раскрыть ветку (2)
6
Автор поста оценил этот комментарий

Баян?

раскрыть ветку (1)
6
DELETED
Автор поста оценил этот комментарий

хочешь - не хочешь, а баян :))

12
Автор поста оценил этот комментарий

Да и сейчас работают с такими объемами памяти - добро пожаловать в мир embedded )

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

раскрыть ветку (8)
15
Автор поста оценил этот комментарий

Самая маленькая игра в мире (58 байт)


Для тех, кто читал статью в песочнице: добавил раздел «Можно ли сделать игру меньше?».


Прочитав историю одного байта, вспомнил свою историю.


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


Первый прототип, размером 80 байт, был готов на следующий день. (Поскольку о контроле версий тогда я даже не догадывался, то остается верить воспоминаниям). С этого момента началась моя борьба за байты. Помню, довольно быстро размер был уменьшен до 65 (или около того), дальше каждый байт давался все с большим и большим трудом. К концу лета результат был 58 байт.


Сюжет и управление


Вы несетесь по трассе на грузовике с двумя прицепами. Слева от вас разделительная полоса, справа обочина укрытая травой. На дороге встречаются люди и деревья (может ямы). Ваша задача: не сбивать людей и не врезаться в деревья (не попадать в ямы).

Управление: стрелки влево-вправо — поворот; Esc — пауза.



Скриншот



Исходный код


begin: <br> <i>; ds указывает на видеопамять </i> <br> <b>push</b> 0b800H <br> <b>pop</b> ds <br> <i>; установить графический режим 40×25</i> <br> <b>int</b> 10H <br> <i>; bx = 700H - смещение, по которому находиться грузовик</i> <br> <b>mov</b> bh, 7H <br> <br> main_loop: <br> <i>; Задержка и вывод грузовика на экран</i> <br> <b>xchg</b> cx, ax <i>; mov ah, 0</i> <br> <b>int</b> 1AH <br> <b>mov</b> [bx], dl <br> delay: <br> <b>int</b> 1AH <br> <b>cmp</b> [bx], dl <br> <b>je</b> delay <br> <br> <i>; si - смещение следующего препятствия</i> <br> <b>xchg</b> ax, si <br> <b>add</b> al, dl <br> <b>xchg</b> ax, si <br> <br> <b>xchg</b> ax, cx <i>; mov cx, 0</i> <br> <br> <i>; Получение нажатой клавиши</i> <br> <b>in</b> al, 60H <br> <b>cmp</b> al, 77 <br> <b>jnz</b> keytest1 <br> <i>; вправо</i> <br> <b>inc</b> bx <br> <b>inc</b> bx <br> keytest1: <br> <i><i>; влево</i></i> <br> <b>ja</b> keytest2 <br> <b>dec</b> bx <br> <b>dec</b> bx <br> keytest2: <br> <i>; очистка буфера клавиатуры</i> <br> <b>mov</b> ah, 0CH <br> <b>int</b> 21H <br> <i>; скролл экрана на 1 строчку</i> <br> <b>mov</b> ax, 0701H <br> <b>mov</b> dx, 1827H <br> <b>int</b> 10H <br> <br> <i>; вывод препятствия</i> <br> <b>mov</b> [si], ax <br> <i>; вывод травы и разделительной полосы</i> <br> <b>mov</b> [di+51], dx <br> <i>; проверка что перед грузовиком нет препятствий</i> <br> <b>cmp</b> [bx], dh <br> <b>ja</b> main_loop <br> <br> <b>ret</b> <br>

Архив с исходником и бинарником (для компиляции использовался Tasm)

отсюда: https://habrahabr.ru/post/64254/


А вот Doom мелкоскопических размеров найти не смог. :'-(

раскрыть ветку (1)
8
Автор поста оценил этот комментарий

95 килобайт для 3d шутера пойдет? )

http://virtuallab.by/news/kkrieger_samaja_malenkaja_igra_v_m...


Для любителей покричать "разработчики обленились, че это игры под десятки и сотни гигабайт весят", скажу сразу: 90-99% места в современных играх это ресурсы. Графика, музыка, звуки и пр. 

1
Автор поста оценил этот комментарий

Та у меня тоже был в универе курс по микроконтроллерах(ну как курс, специальность у меня такая в универе была, и вообщем то целых 4 года у нас были микроконтроллеры) - на 5 по предмету заставляли в различных задачах вложится в регистры контроллера, и не использовать другую память, вот там и был жестяк.

раскрыть ветку (5)
1
Автор поста оценил этот комментарий

А вообще реально нормальную найти работу по этой тематике? Чтоб как у настоящих программистов с печёнками и чаем. Ну и паяльником/макеткой :)  Думою в встраемые решения подастся.

раскрыть ветку (4)
Автор поста оценил этот комментарий

Спроси DI HALT'а =)
Вполне себе работал фрилансом(!) по схемотехнике.

Мне тоже довелось поработать по электронике, в частности Миландровские контроллеры, на ядре Cortex. там упирались не в объем, а в скорость работы.

Автор поста оценил этот комментарий
ПечЁнками и думОю. Нет, не найти работу.
раскрыть ветку (2)
1
Автор поста оценил этот комментарий

-_- Синдром вахтёра.


Я сам прекрасно знаю о своей  безграмости. Не нужно мне об этом напоминать. Если вас  распирает от знаний грамматики и вы всегда поправляете других с поводом или без, то могу вам посоветовать пойти учителем школу. Ваш комментарий не к месту т.к. первое слово явная опечатка и мы здесь обсуждаем не нормы русского языка. Мало того, что вы не ответили на вопрос (сорказм не ответ), но и ещё тешите своё самолюбие.  Грамматические ошибки совершают все, смиритесь с этим.

раскрыть ветку (1)
Автор поста оценил этот комментарий
сАрказм
5
Автор поста оценил этот комментарий
Они делали дырки, а потом ждали...
2
Автор поста оценил этот комментарий

32? 96+ гигов сейчас норма для обычного сервака 1С в компании со штатом в 100 человек, некоторым при особой специфике при этом и 192Gb не хватает. Для среднего и крупного бизнеса - там вообще отдельная заморочка. Базы данных у бизнеса становятся всё монструознее и монструознее.

раскрыть ветку (8)
1
Автор поста оценил этот комментарий
192 гига оперативы? Не верю, давай пруфы
раскрыть ветку (7)
7
Автор поста оценил этот комментарий

У нас под БД стоят серваки по 384Гб ram, чтобы база по возможности целиком влазила в память, потому что каждая операция чтения с диска оооччень сильно сказывается на производительности.

6
Автор поста оценил этот комментарий

Это не много, просто людям далёким от серверной техники такие объёмы непривычны. Работал продукт-менеджером по серверам Intel. А так это обычный объём памяти для околотоповых конфигураций рабочих лошадок серверного рынка - двухпроцессорных раковых серверов. Для производительной работы с базы данных вся база должна помещаться в памяти, помимо ОС и обслуживающих БД служб + запас т.к базы имеют свойство расти, отсюда и объёмы. А так 2 процессора, память работает в трёхканальном режиме, соответственно минимум 6 планок памяти. 192Gb - это 12 планок памяти по 16Gb. Сейчас подобные платформы поддерживают 384Gb.. но я уже пару лет не слежу за актуальными решениями т.к. сменил вид деятельности. 

раскрыть ветку (4)
2
Автор поста оценил этот комментарий
Необходимости нет в 192 гигах ОЗУ при 100+ юзерах. Всю БД в памяти держит? Абсолютно всю и для всех по 100 раз?
На оптимизацию всем похер нынче стало? Не, я всё понимаю, но серверу 1с на 100+ юзеров надо 192 гига оперативки? Нахрена? ЧТО они могут делать для того, чтобы серверу нужно было столько держать памяти занятой?
раскрыть ветку (3)
3
Автор поста оценил этот комментарий

Не столько серверу 1С, сколько серверу на котором крутится его база данных. Как и во многих других случаях требуется держать всю базу данных и кэши в памяти для работы, по вполне очевидным причинам - огромное количество обращений к разным секторам диска при обработке запросов. Формирование визуально довольно безобидного отчета в 1С(или других системах ERP) требует сотен тысяч, а то и миллионы обращений.. И на прикладном уровне ничего лучшего чем держать базу в памяти не придумано - это просто и дёшево, оптимизировать тут не много что можно. Вот у чуваков занимающихся BigData всё намного прикольнее - т.к. в лоб проблему решить невозможно технически она превращается в очень дорогое развлечение и для программистов и для архитекторов железа, каждое решение при этом почти уникально. А на уровне мелких и средних предприятий это вообще не нужно - купил сервер с нужным объёмом ОЗУ и проблема решена, дёшево и сердито. 

раскрыть ветку (2)
Автор поста оценил этот комментарий
Развернуто ответили, но можно было короче: "нахрен оптимизировать, клиент купит оборудование". Понимаю, так проще, но как-то неправильно.
раскрыть ветку (1)
4
Автор поста оценил этот комментарий

Что оптимизировать то? Оптимизацией базы данных занимуются разработчики ПО её использующей, ну и оптимизацией запросов к этой БД, алгоритмов запросов запросов занимаются разработчики СУБД. И то и то крупные компании занимающиеся разработкой ПО. Размер БД зависит от потребностей бизнеса. Всё, что тут можно оптимизировать - это настройки сервера(эффект мизерный, к объёму БД не имеет отношение) и подобрать оптимальное железо под задачу. Про оптимизацию - это к производителям игрушек, где объём данных хранящихся в памяти и соответственно требуемый объём ОЗУ реально можно уменьшить, тут не тот случай. Тут объём базы зависит от задач. И вообще это не особенно является предметом для разговора т.к. стоимость по сути копеечная. Не стоит мерить своим личным кошельком основные производственные средства компаний с большими штатами сотрудников. Ну и да, в общем случае купить железку покруче стоит на порядки дешевле чем решать проблему пытаясь что-то оптимизировать или творить уникальные решения которые потом реально дорого и рискованно поддерживать. Но тут нужно смотреть, я говорю про большинство задач, некоторые так решать нельзя категорически.

2
Автор поста оценил этот комментарий

Да, вот пример из актуальных материнок. http://ark.intel.com/ru/products/82156/Intel-Server-Board-S2... Максимальный объём памяти мать поддерживает больше террабайта, но тут нужно смотреть на процессоры и доступность требуемой для набора такого объёма памяти. Не думаю, что в реале можно собрать больше 796Gb, 384 можно точно. Но лично мне столько ни разу не требовалось, в моей практике(года 3, а может уже и больше назад) самыми ходовыми были двухпроцессорные серваки с объёмом памяти от 24 до 96Gb.

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку