Ждём Ваших отзывов о материале.

Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
За статью можно проголосовать на странице материала.

Напоминаем о том, что на сообщения новых участников распространяется действие системы премодерации сообщений.

О нарушениях можно сообщить модератору, нажав синюю кнопку #77 справа над спорным сообщением.

Я так понимаю чтоб получить какой-то профит с нее, нужна программная поддержка. Она уже есть?

На любой плашке DDR-4 тож самое. Эт уже лет 10 как не новость для модулей памяти.

slafniy
Явно уже есть, потому как "поставки модулей Optane DC объёмом до 512 ГБ включительно компания начала ещё прошлым летом".

64гб ДДР4 на b-die стоят 50-60 тысяч рублей, считай тысяча долларов
интел обещает, что их 64гб "ССД" будет стоить ДАЖЕ дешевле
ну ахренеть теперь, вот это классная новость, дайте две
за тысячу долларов можно 4Тб топовый CCД купить

гигабайт такой памяти по цене гигабайта ДДР4?! Спасибо, не надо!

Ну это в случае сбоя электросети. А простая перезагрузка опять будет зависеть от накопителя. Да и запуск ОС за 5 секунд как бы совсем не ново для скоростных SSD.

VRoman
Верно, время при запуске уходит на всякие процедуры, а не чисто на чтение. Хотя 5 секунд бывает только с ультрафаст-бутом, который не совсем хард бут.

Но по-хорошему многие аспекты архитектуры и парадигмы ПО давно пора менять, и в их числе software-tiering памяти. Т.е. сам принцип жесткого разделения памяти на RAM и Storage. По-хорошему с современной архитектурой было бы правильнее выполнять программы и работать с данными напрямую в NVRAM, а обычную DRAM и SRAM использовать в качестве кэша, причем функции кэширования, сохранения данных и версионирования абстрагировать на уровень операционной системы.

В сегментах high-load и отчасти в big-data это давно произошло. Абстракции на разных уровнях, не только ОС, но смысл один: бизнес-коду предоставляется единый интерфейс данных, в котором на физическом уровне смешаны SRAM, DRAM, RAM-SSD, NAND, HDD от 5k до 15k, а изредка и ленточные хранилища.

Ни Оптан, ни собственно NV-DRAM ничего не изменят, но это шаг к упрощению такой реализации.

Что ты имеешь в виду под "выполнять"? Выполняются программы в регистрах процессора, а всё остальное начиная от кешей проца и так и есть по сути кеш того или иного уровня. Включая ССД и синк на какое-нибудь облако.
А если вот уже именно вычислять в памяти то это немного другое, и никакие оптаны это не приблизят, мне так кажется

slafniy
Речь ес-но о чтении программ и их данных напрямую с диска, минуя стадию копирования в память.

Точнее, не обязательно минуя, но абстрагируя это на усмотрение ОС.

Исторически в Фон Неймановской просто так сложилось, что из-за тормознутости постоянной памяти все делалось в переменной, и практика "грузить" все стала общепринятой. А сейчас, с пятью слоями переменной и еще тремя-четырьмя постоянной, она превратилась в атавизм. Случайным образом проведенную черту.

Хочешь конкретный пример неверной работы этой бородатой логики? Херомиум/электрон в память грузится, диск виртуалки почти нет - хотя первое и второе по сути ОС, только 10% которой задействовано в исполнении кода - а локации ММО совсем нет, хотя в них зашиты скрипты, которые есть код, и модели-текстуры, которым вообще место в видеопамяти.




Оптан - это NVRAM, засунутый в слот под DRAM. Если он будет поддерживать адресацию как RAM, то это позволит кодить соответствующим образом.
А дальше подтянутся. 10+ лет.

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

slafniy
Сжатие-разжатие идеально параллелизуется и по затратам ресурсов незаметно.

О бытовухе, т.е. "гонять крузис и эксель под виндоуз 7", речи нет. Хотя и сейчас не грузить весь электрон уже будет плюсом.
Речь о следующем витке развития. Уровней хранения не 2-3, а даже в быту 7-10, в энтерпрайзе еще больше. Прошло время управлять этим в бизнес-коде, втупую приравнивая друг к другу все из каждой половины.

В перспективе даже в бытовом применении это даст отсутствие таких понятий как загрузка, сохранение файла, свободная память. Т.е. компьютер не будет грузиться, он просто будет открываться там же, где закрылся. То же с приложениями. Игра не будет закрываться и загружаться, ты будешь нажимать на нее в панели задач и оказываться там же, где был. Собственно частично мобильные ОС уже имитируют такое поведение, с бесконечным пулом "открытых" приложений.

Это не значит мгновенность всего, время будет уходить и на обновление кэшей, и на перезагрузку при сбоях. Но вместо детерминированных "это грузится 30 секунд и еще 15 на уровень" будет 1 секунда на то, что только что закрылось, и полные 45, если быстрая память давно вытеснена более свежими данными. Точнее, 2->15->120 фпс через соответствующее число секунд. Вместо объемов каждого слоя памяти и полуручного управления ей - постепенное замедление по мере заполнения быстрых слоев. И в ряде областей так уже работают.

Дело не только и не столько в тормознутости постоянной памяти, а в том, что в отличие от ОЗУ она до сих пор является чисто блочным устройством, что эффективной работе АЛУ с кодом и данными отнюдь не способствует. Вполне можно сказать, что суть "загрузки" это тупо трансляция данных из блочной модели доступа в плоскую. И потому скорости нынешней массовой NVRAM тут не очень много решают, раз NAND flash SSD на уровне железа может быть только блочным устройством. Да, давно есть memory-mapped files, которые могут выполнять эту трансляцию без тупого копирования, но в конце цепочки всё равно стоит блочное железо. И если с доступом только для чтения дела обстоят неплохо, то в случае необходимости часто модифицировать данные в процессе их обработки всё становится очень печально: program/erase cycle, write amplification, garbage collection, вот это всё - и потому возвращаемся обратно к ОЗУ, только теперь в виде кэша внутри SSD. Поэтому NVDIMM на NAND это просто курам на смех, костыли для бедных. Вот 3D Xpoint уже не обязательно быть блочным устройством, собственно именно поэтому только с её появлением NVDIMM и начали хоть как-то развиваться. И потому пока NAND флэш из SSD, где сейчас костыль на костыле и костылём погоняет, не будет вытеснен той или иной NVRAM с плоской огранизацией памяти, об "отсутствии таких понятий как загрузка, сохранение файла, свободная память" можно и не мечтать.
Так что никакой случайным образом проведённой черты тут нет, и атавизма к сожалению пока тоже не наблюдается. А фон Неймановская ахритектура и вовсе ни при чём - ввод/вывод точно так же есть и в гарвардской, и проблема хранения гигазов вареза до того, как они попадут в плоскую ОЗУ, там никуда не исчезает: от того, что эта память делится на две части, она внезапно не подешевеет.

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



А зачем программисту приклада об этом думать? Вчера дорожки и сектора дисков, сегодня блоки стирания флеша, завтра еще что-нибудь. Его дело писать бизнес, а в бизнесе нет дорожек и блоков, есть объекты и датафреймы. Кэш совершенно необязательно внутри SSD, ОС и так отводит свободную память под кэш, а файловые системы чуть сложнее NTFS жестко отбирают под свои и не свободную.

Причем как раз код в ходе работы не модифицируется, если только ПО не вирус.
И код давно перестал быть ста килобайтами исполняемых символов, а превратился в пятьсот мегабайт библиотек и зависимостей, используется из которых в одном сеансе работы десять мегабайт фактического кода. Вот нафиг тащить все эти библиотеки в ОЗУ - на случай, если программист чЯтика на электроне ВНЕЗАПНО захочет запилить рекурсивно самомодифицирующийся код на место одной из библиотек, и мы боимся за write amplification на нашем ссд из-за этого?

И нет, это не только у секретарш (как раз наоборот не у них), и в энтерпрайзе не лучше. Там такие же чЯтики, только между двумя машинами через REST, и в двухгигабайтном контейнере докера со встроенной базой данных вместо полугигового электрона.



Уже давно не на две, а до десяти частей с разной скоростью. Для софта же они принципиально поделены на две по историческим причинам. По практическим же причинам обе из этих частей давно содержат в себе и RAM, и NAND, в форме виртуальной памяти ОС с одной стороны и гигабайтов кэшей разных уровней с другой.

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


Речь не о том, чтобы жестко решить, что грузим все из NVRAM, а о том, чтобы окончательно вынести кэширующую функцию памяти из-под полу-контроля ПО на уровень ОС. NVRAM с прямой адресацией просто ускорит процесс перехода к этому. Разумеется, пока ПО строится на идее о том, что данные живут на диске, или же грузятся, если нужны быстро, а код живет в памяти, и все надо сначала скопировать в правильные места, а потом уже работать, текущий порядок работы никуда не уйдет. Это просто хардварный звоночек о том, что строить на этой идее необязательно.

Ни быстрым, ни безболезненным переход не будет, т.к. на практике ОЗУ играет еще и защитную функцию помойки, где можно накосячить и потом перезапуститься и надеяться, что ОС все подчистит. Но это побочный эффект, а не целевой, и у такого обращения с памятью свои побочные эффекты.

А потому что закон Мура всё. Пока он работал и давал стабильный рост быстродействия процов (в том числе всяческих контроллеров) и объёмов памяти (и оперативной, и в накопителях), программисты не парились и оптимизировали свой говнокод только по особым праздникам, когда уже совсем всё тормозило не по-детски. Вот в результате и имеем "пятьсот мегабайт библиотек и зависимостей, используется из которых в одном сеансе работы десять мегабайт фактического кода". И все были довольны (ну кроме конечных пользователей, как обычно): менеджеры могли гнать конвеер продаж из сляпанных по-быстрому монстров, программисты - тратить свои умственные ресурсы на обсуждение животрепещущих вопросов инклюзивности, диверсити-квот и создания нетоксичного сейф-спейса на работе, а производители железа - делать дополнительные деньги на потребности в постоянном апгрейде. Однако лафа закончилась, шринков осталось всего на пару шагов, и до конца дойдут не только лишь все (вот GloFo уже спёкся). Сейчас ещё лет 5-10 попытаются продолжить этот праздник жизни через форс многоядерности, но закон Амдала на кривой козе не объедешь, и рано или поздно таки придётся программистам возвращаться к ненавистным профайлерам и долго-долго из них не вылазить. Собственно говоря, ты сейчас просто описываешь текущие надежды индустрии, что этого можно будет избежать, просто навалив где можно побольше разных кучек всякой спецпамяти, раз уж дальнейшее наваливание одной большой кучи ОЗУ себя практически исчерпало. Да ещё чтоб всё это умные индусы из Майкрософта или кого другого аккуратненько разгребли и поднесли на лопате блюдечке прикладным программистам, которые и дальше будут продолжать гнать кривой раздутый говнокод. Однако тот факт, что и там давно уже большинство системных программистов - такие же говногонщики на капусте из фреймворков, заставляет меня сильно сомневаться в успехе этого предприятия. Рано или поздно таки придётся возвращаться к кочерыжке.

С остальным согласен, да я собственно и не спорил с тобой, а просто дополнил, отметив важный момент, на который ты не обратил внимания.

Вот именно поэтому работу ПТУ-программистов (свитчеры, самоучки, бут-камперы - бут-камп и есть ПТУ по программированию) и надо отделять от низкоуровневой работы. Если они полезут оптимизировать код, то все равно получится хуже, чем если его будут оптимизировать компилятор и ОС.

500-метровые чятики появились не просто так, а в попытках решить проблему переносимости кода. И они ее действительно решили, правда высокой ценой. Но как часть этого, "исполнимый код программы" окончательно перестал быть набором инструкций, который непременно нужно держать в памяти. Теперь это пакет зависимостей до десятого колена. Такому пакету место на диске, а то и в сетевом репозитории (но инет пока не перманентен). Что из этого тащить в память, должен решать уже не ПТУшник, а специально обученный программист, пишущий компиляторы и ОС.

Уровней памяти стало больше по объективным причинам. Как минимум это RAM, VRAM, ПЗУ, интернет (сейчас совершенно полноценный уровень), чаще больше. Хорошо хоть перестали держать копию VRAM в RAM, но ущерб уже нанесен.

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



Да, здесь согласен. Физические свойства и MRAM, и Xpoint уже делают их более полноценно совместимыми с RAM. Я к тому, что это только триггер, а менять метод работы нужно в принципе по всей системе. И выигрыш будет не только на системах с дорогой спецпамятью, но везде.

Дело же не только в чятиках. Игры весят по 100 гигов уже не из-за фреймворков, а из-за огромных моделей и текстур. SSD на видеокарты, кстати, уже ставили. Эндгеймом же я вижу логику "код/репозиторий/кэши". То есть есть короткий код, которым определяется список репозиториев, из которых следует тянуть ОС, игры, в том числе моды к ним (частично к этому уже пришли) и т.д., а все остальное, от процессорного L3 и видеопамяти до GPU-SSD, Xpoint, хардов, и т.д. - управляется на системном уровне как кэши для этих и временных данных.