Здравствуйте, B0FEE664, Вы писали:
BDA>>На самом деле, мне и другие материалы попадались, где это более подробно расписывалось, смысл именно такой, что будет много дешевой, энергонезависимой, быстрой памяти, а РАМу с дисочками отменят.
BFE>Вопрос тут только в цене, а не в каких-то принципиальных моментах. Эта MRAM ничем принципиально не отличается от памяти на магнитных сердечниках, которая применялась (и, наверное, применяется) в военных компьютерах времён СССР. В таких специализированных компьютерах даже операционная система не нужна: в памяти ровно одна программа, которая получает данные от сенсоров или с пульта, производит расчёт и выдаёт координаты цели. Программа всегда "запущенна" и никаких тебе файлов, менеджеров задач и прочего операционно-системного софта. Но это в спец. компьютерах. BFE>А в компьютерах общего назначения я принципиальных улучшений не вижу: сбой программы требует перезапуска, а значит данные должны быть отделены от исполняемого кода, значит появляются файлы и базы данных. Сбой в одной программе не должен затронуть исполнения остальных — значит необходим системный менеджер памяти. Более того, какой-нибудь UB баг действительно сможет потереть всю память компьютера.
Долго перечитывал, но не связи с написанным мной не увидел.
Здравствуйте, vsb, Вы писали:
vsb>Открываем пару сотен вкладок с флешами и жаваскриптами, через пару недель вся реальная и виртуальная память сожрана, надо перезапускать программу.
Не знаю за флеш но жабаскрипт имеет GC.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>На самом деле, мне и другие материалы попадались, где это более подробно расписывалось, смысл именно такой, что будет много дешевой, энергонезависимой, быстрой памяти, а РАМу с дисочками отменят. Это предпосылка А. Мотив за механизмом виртуальной памяти — выдать память второго класса за память первого ценой падения перфоманса.
Это неверно. Своп — это скорее грязный хак, который виртуальная память делает возможным. А основная причина для виртуальной памяти — это защита приложений друг от друга, чтобы одна маленькая бага в приложении не роняла сразу всю систему.
Здравствуйте, Философ, Вы писали:
Ф>Может быть ты не знаешь, но один из самых распространённых подходо к разработке без GC — reference counting (RC) или, как вариант, Auto Reference Counting (ARC), и я сильно сомневаюсь, что (A)RC быстрее чем GC.
Тоже терпеть не могу
Ф>Я профилировал софт и использующий GC и не использующий его. И в моих случаях проблема ВСЕГДА была не в GC и не в (A)RC. Ф>Почему ты считаешь, что GC сколь-нибудь серьёзно влияет на производительность?
Если на чтото тратятся ресурсы, то згначит это чтото влияет на производительность
Здравствуйте, Sheridan, Вы писали:
S>Потому что пытаешься оправдать наличие гц, хотя принципиально гц существует сейчас именно из за низкой квалификации погроммистов и их лени.
Здравствуйте, Cyberax, Вы писали:
BDA>>На самом деле, мне и другие материалы попадались, где это более подробно расписывалось, смысл именно такой, что будет много дешевой, энергонезависимой, быстрой памяти, а РАМу с дисочками отменят. Это предпосылка А. Мотив за механизмом виртуальной памяти — выдать память второго класса за память первого ценой падения перфоманса. C>Это неверно. Своп — это скорее грязный хак, который виртуальная память делает возможным. А основная причина для виртуальной памяти — это защита приложений друг от друга, чтобы одна маленькая бага в приложении не роняла сразу всю систему.
Защита реализуется через виртуальное адресное пространство, а не виртуальную память. Больше в эту ветку не заглядываю.
Здравствуйте, Farsight, Вы писали:
S>>Если на чтото тратятся ресурсы, то згначит это чтото влияет на производительность F>Это феерично. Разбил нос рукалицом.
То есть по твоему ГЦ абсолютно бесплатен?
Здравствуйте, Sheridan, Вы писали:
S>>>Мерием результат работы погроммистов исключительно количеством написанного кода? Про качество уже позабыли, да?
P>>Ты всерьез меряешь производительность программиста по количеству написанных строк? S>Это мой вопрос вообще то.
Мы разве не выяснили, что погроммисты — это такие админы, после вмешательства которых в работу системы последняя в лучшем случае просто останавливается, а в худшем... Это ты и сам знаешь.
А сформулируй-ка для определенности, что ты понимаешь под качеством кода. И, кстати, какой код ты имеешь в виду: исходный, исполняемый, что-то, чего я не знаю?
P>>Существует весьма широкий класс задач, где автоматическое управление памятью снимает с разработчика кучу проблем, причем качество кода не страдает. S>Конечно снимает, не вижу причин обратного. Какой ценой?
С учетом существенного снижения вероятности появления некоторых ошибок времени выполнения, соответственно сокращения времени на их анализ, цена не такая высокая. Ну и мозг разработчика занят, как я писал раньше, решением целевой задачи. Когда в проекте 50 МБ исходников (и это далеко не самый тяжелый случай), следить за временем жизни каждого объекта — нехилые затраты. Так что плючов от автоматики больше, чем минусов.
Разумеется, бывает, что автоматическое управление памятью мешает. Но мы же сейчас не об этом, верно?
Здравствуйте, Sheridan, Вы писали:
S>То есть по твоему ГЦ абсолютно бесплатен?
Нет.
Но Шеридан....
Был вопрос: Ф>Почему ты считаешь, что GC сколь-нибудь серьёзно влияет на производительность?
Твой ответ: S>Если на чтото тратятся ресурсы, то згначит это чтото влияет на производительность
Все просто: на конкретный вопрос у тебя нет ответа, поэтому ты для себя его трансформируешь в более удобную форму и отвечаешь общей фразой. Это талант, фигле. Я это уже почти 10 лет наблюдаю, посиживая тут периодически.
PS: Один мой препод по плюсам сказал, что программист должен быть ленивым. Подумай об этом.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Защита реализуется через виртуальное адресное пространство, а не виртуальную память. Больше в эту ветку не заглядываю.
А в чём разница?
Здравствуйте, 0BD11A0D, Вы писали:
TK>>Похоже на рассуждения в 640Кб хватит всем — ограничение в 256Tb на x64 тоже не от хорошей жизни.
BDA>Я лично не знаю, от какой жизни. Мне всегда казалось, это какое-то конъюнктурно-экономически-искусственное ограничение, типа 10К хендлов на винду. Просто потому, что никаких других естественных ограничителей кроме размера secondary memory быть не может.
Вылезает, что кроме secondary memory еще есть кеши процессора и непопадание в этот кеш дорогого стоит.
TK>>Не надо думать, что новый тип памяти принципиально что-то изменит — это как HDD vs SSD. Да, станет быстрее, но в целом все останется как и было.
BDA>Может, вы не прочитали? Новый там не тип памяти. Новый там отказ от разделения на RAM/HDD(SSD). На самом деле, конечно, тип памяти, позволивший отказаться от разделения, тоже новый, но не это главное.
А а чем смысл разделения? Принципа "пол работы дураку не показывают" никто не отменял — результата работы алгоритма интересны именно в виде результатов работы. А в виде промежуточного состояния они мало кому интересны. В чем смысл смешать все в кучу?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Farsight, Вы писали:
S>>То есть по твоему ГЦ абсолютно бесплатен? F>Нет.
F>Но Шеридан....
F>Был вопрос: Ф>>Почему ты считаешь, что GC сколь-нибудь серьёзно влияет на производительность?
F>Твой ответ: S>>Если на чтото тратятся ресурсы, то згначит это чтото влияет на производительность
А теперь подумай — там гц, тут гц, здесь гц, еще тут гц и вот тут гц. А при сегодняшнем подходе гц будет вообще везде. и?
Здравствуйте, mike_rs, Вы писали:
_>>>мемристоры — круто, что мешает запускать расово правильные операционки на машинах с такой памятью ? BE>>Другая архитектура мешает. Подробного описания еще нет. Выпустят — посмотрим _>непоянтно. Берем обычный PC и заменяем HDD на мемристоры — профит!
нельзя. бессмысленно. HDD сделаны от безысходности. нужно было оперативно обрабатывать большие объемы данных, а оперативной памяти RAM было мало. ленточки, из за последовательного доступа и катастрофически низкой скорости, в общем то совсем не подходили для этих целей. вот компромиссно и появился HDD как расширитель оперативной памяти.
потом уже сделали дешевую как песок динамическую оперативную память _D_RAM. объемы доступной (по карману) памяти увеличились в разы. стало доступно и 256к и 512к и фантастические 640к. Тут уже на HDD взвалили еще одну задачу — быстрый кэш для ленточки. и на этом функционал HDD прекратил развиваться. Всё.
Не смотря на все технологически скачки в области HDD, замену алюминиевых блинов на стеклянные, магнитных головок на резистивные, блинов вообще на твердотельное хранение... HDD выполняет только эти две задачи — дешевое расширение оперативной памяти и временное хранение данных ленточки.
С мемристорами первая задача HDD отпадает. остается кеширование данных ленточки. Ну а в силу того, что ленточки нежные и в руки кого попало их давать жалко — HDD еще долго будут жить в широких областях.
_>далее чуть подкручиваем контроддер памяти и заменяем DRAM на них-же — профит x2!
Здравствуйте, Sheridan, Вы писали:
Ф>>>Почему ты считаешь, что GC сколь-нибудь серьёзно влияет на производительность? S>А теперь подумай — там гц, тут гц, здесь гц, еще тут гц и вот тут гц. А при сегодняшнем подходе гц будет вообще везде. и?
[Кэп]
Там аллокатор, тут смартпойнтер ... вообще везде рефкаунт. И?
[/Кэп]
Ну вот прям щас я смотрю на сервис под типовой нагрузкой. ~20% cpu, из них gc time 0.09% (90й перцентиль), 1.2% (95й перцентиль). Это при условии, что с перфомансом и оптимизацией под gc никто не заморачивался. Ради красивых циферок можно уменьшить обе цифры где-то на треть-половину, но мы вместо этого лучше ещё плюшек клиентам подкинем.
Здравствуйте, Sheridan, Вы писали:
S>А теперь подумай — там гц, тут гц, здесь гц, еще тут гц и вот тут гц. А при сегодняшнем подходе гц будет вообще везде. и?
И ничего. Возьмем твой, без сомнения, реалистичный сценарий и повторим вопрос: Ф>Почему ты считаешь, что GC сколь-нибудь серьёзно влияет на производительность?
Могу даже немного обновить, чтоб ты не парился:
Почему ты считаешь, что там гц, тут гц, здесь гц, еще тут гц и вот тут гц серьёзно влияет на производительность?
Здравствуйте, Stanislaw K, Вы писали:
_>>далее чуть подкручиваем контроддер памяти и заменяем DRAM на них-же — профит x2! SK>Вот это правильный путь.
Если только их быстродействие не будет уступать транзисторной памяти.
Прямо на сегодня, на сколько я понял, эта технология хороша как замена флеш-памяти. Но почему-то не вижу характеристик ни времени хранения, ни циклов перезаписи.
Здравствуйте, Cyberax, Вы писали:
BDA>>Защита реализуется через виртуальное адресное пространство, а не виртуальную память. Больше в эту ветку не заглядываю. C>А в чём разница?
В том же, в чем разница м/у ячейкой памяти и её адресом. Но парень все-равно гонит, виртуальная память реализована именно через виртуальное адресное пространство и никуда эта виртуальная память из защищенных систем не денется, ес-но, бо весь ввод-вывод, порты и прочее DMA исключительно на виртуальной памяти сидят.
V>Прямо на сегодня, на сколько я понял, эта технология хороша как замена флеш-памяти. Но почему-то не вижу характеристик ни времени хранения, ни циклов перезаписи.
Потому что это только концепция. Красивые картинки для инвесторов.
Там прямо и сказано: "мы хотим разработать" == скоро будет == еще не существует == дайте бабла == очень кушать хочется == не из чего дивиденды акционерам платить.
