Здравствуйте, Sheridan, Вы писали:
S>Производительность продукта. Совсем уже забыли что такое понтие есть? Мерием результат работы погроммистов исключительно количеством написанного кода? Про качество уже позабыли, да?
Ты всерьез меряешь производительность программиста по количеству написанных строк?
Существует весьма широкий класс задач, где автоматическое управление памятью снимает с разработчика кучу проблем, причем качество кода не страдает.
offtopic: погроммисты — это криворукие админы. Что-нибудь проапдейтят или восстановят, а мне потом разбираться, почему половина софта не работает.
Здравствуйте, dimgel, Вы писали:
TK>>>Не надо думать, что новый тип памяти принципиально что-то изменит — это как HDD vs SSD. Да, станет быстрее, но в целом все останется как и было. BDA>>Новый там отказ от разделения на RAM/HDD(SSD). D>Ну так и что изменится?
Может, все дело в русском языке? По-русски «виртуальный» обычно значит «воображаемый». Ну, у многих людей так. По-английски — 'very close to being something without actually being it'. В полном соответствии со своим названием и его английским смыслом этот механизм придумали, чтобы вы НЕ ЗАМЕТИЛИ ЕГО ПОЯВЛЕНИЯ, а вы спрашиваете, что изменится с его исчезновением! Для вас термин исчезнет и знать надо будет меньше, вот и все. Но операционную систему надо будет переписывать, по крайней мере, в этом аспекте. А поскольку это не единственное новшество, их сумма тянет на принципиальную новизну. Это и есть ответ на вопрос mike_rs.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Для вас термин исчезнет и знать надо будет меньше, вот и все.
ОК, это хорошо уже само по себе.
BDA>Но операционную систему надо будет переписывать, по крайней мере, в этом аспекте.
А вот необходимости переписывания я тоже не вижу. Например, файловые системы останутся в неизменном виде, зуб даю. Во-первых, они никуда не денутся просто потому что никуда не денутся файлы. А во-вторых, с переходом с HDD на в разы более быстрый SSD файловые системы никуда не делись — и продолжают своим ходом усложняться с увеличением ёмкости накопителей. Вот и вопрос у меня, раз вы в теме, по конкретике: что именно придётся в современных ОС переписать и зачем?
Здравствуйте, dimgel, Вы писали:
D>А вот необходимости переписывания я тоже не вижу. Например, файловые системы останутся в неизменном виде, зуб даю. Во-первых, они никуда не денутся просто потому что никуда не денутся файлы. А во-вторых, с переходом с HDD на в разы более быстрый SSD файловые системы никуда не делись — и продолжают своим ходом усложняться с увеличением ёмкости накопителей. Вот и вопрос у меня, раз вы в теме, по конкретике: что именно придётся в современных ОС переписать и зачем?
Что значит «в теме»? Я знаю столько же, сколько и вы. Это обычный силлогизм. По ссылке из заглавного сообщения:
The Machine will fuse memory and storage
На самом деле, мне и другие материалы попадались, где это более подробно расписывалось, смысл именно такой, что будет много дешевой, энергонезависимой, быстрой памяти, а РАМу с дисочками отменят. Это предпосылка А. Мотив за механизмом виртуальной памяти — выдать память второго класса за память первого ценой падения перфоманса. Это предпосылка Бэ. Какой вывод? В The Machine виртуальной памяти быть не должно. Раз не должно, значит традиционные ОС с их менеджером памяти будут делать лишнюю работу. То есть, их можно адаптировать, но лучше переписать. Затем начался традиционный срач непонимания ВП, ВАП, и прочих слов на букву Вэ.
Причем тут SSD, я не понимаю. Они если и сократили разрыв между RAM/HDD, то ненамного. Иное дело сокращение разрыва до нуля. Принципиально иное.
Денутся ли куда файловые системы, я не знаю. Знаю только, что это предвещает тектонические изменения в энтерпрайзе. Допустим, как на нынешней платформе делать клаудный стриминг бизнес-апов? Запускать по принципу RDC? А если сервер придется перегрузить? Как обеспечить сохранность данных? Городим базу. Традиционный SQL или NoSQL, но это усложняет разработку, а производительность падает ужасающе. С TM можно переносить готовые приложения в облака, отрезая интерфейс, после весьма небольшой адаптации. Вот где будет новый большой бум, как мне кажется. Руки чешутся наложить их на эту архитектуру.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Денутся ли куда файловые системы, я не знаю. Знаю только, что это предвещает тектонические изменения в энтерпрайзе. Допустим, как на нынешней платформе делать клаудный стриминг бизнес-апов? Запускать по принципу RDC? А если сервер придется перегрузить? Как обеспечить сохранность данных? Городим базу. Традиционный SQL или NoSQL, но это усложняет разработку, а производительность падает ужасающе. С TM можно переносить готовые приложения в облака, отрезая интерфейс, после весьма небольшой адаптации. Вот где будет новый большой бум, как мне кажется. Руки чешутся наложить их на эту архитектуру.
Хм. Здравое зерно в этих рассуждениях есть. Но базы нужны не только как персистентные хранилища, но и как способ структурирования информации для удобства составления разнообразных запросов. Пойнт тот же, что и в моих рассуждениях выше про файлы: как-то структурировать информацию всё равно надо просто для того, чтобы с ней работать. Поэтому далеко не факт, что даже SQL базы исчезнут — несмотря на возможность в новой архитектуре держать в вечной памяти сети объектов, никуда их не сериализуя. Внутренний формат хранилищ у SQL-баз может поменяться радикально, как и алогоритмы оптимизации запросов, но сами эти запросы, как и транзакционность — как были нужны, так и останутся; мемристоры тут ортогональны — это уже прикладная логика. Такое вот на вскидку моё ИМХО. Тот же NoSQL (по крайней мере Монго ЕМНИП) вполне себе официально заточен под in-memory storage, и кому он нафиг нужен.
Здравствуйте, dimgel, Вы писали:
D>Поэтому далеко не факт, что даже SQL базы исчезнут — несмотря на возможность в новой архитектуре держать в вечной памяти сети объектов, никуда их не сериализуя. Внутренний формат хранилищ у SQL-баз может поменяться радикально, как и алогоритмы оптимизации запросов, но сами эти запросы, как и транзакционность — как были нужны, так и останутся; мемристоры тут ортогональны — это уже прикладная логика.
А вообще, тут как раз вполне могут пригодиться и вырваться вперёд объектно-ориентированные базы. Какой-то язык запросов там тоже был. А если ещё как-нибудь покрасивше обыграть конкурентность через частичную иммутабельность, или я не знаю... Так что вполне возможно, SQL и исчезнет.
Здравствуйте, Sheridan, Вы писали:
S>Да заколебали вы уже своей ленью и невнимательностью! Суёте свой расово-православный gc везде. Что, тааааак сложно следить за жизнью объекта?
Здравствуйте, Farsight, Вы писали:
S>>Да заколебали вы уже своей ленью и невнимательностью! Суёте свой расово-православный gc везде. Что, тааааак сложно следить за жизнью объекта? F>Это не мы суем, это вендоры платформ. Негодяи!!!
То есть им руки отбивать? А все тут и готовы бы на ц++ писать, без гц и прочего мыла, так вендоры-негодяи не дают? айяйяй
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Sheridan, Вы писали:
S>>Производительность продукта. Совсем уже забыли что такое понтие есть? Мерием результат работы погроммистов исключительно количеством написанного кода? Про качество уже позабыли, да?
P>Ты всерьез меряешь производительность программиста по количеству написанных строк?
Это мой вопрос вообще то.
P>Существует весьма широкий класс задач, где автоматическое управление памятью снимает с разработчика кучу проблем, причем качество кода не страдает.
Конечно снимает, не вижу причин обратного. Какой ценой?
P>offtopic: погроммисты — это криворукие админы. Что-нибудь проапдейтят или восстановят, а мне потом разбираться, почему половина софта не работает.
Ты меня понял правильно.
Здравствуйте, Muxa, Вы писали:
D>>>Сам-то небось на ассемблере пишешь, раз такие предъявы кидаешь, м? S>>с++. Ассемблер сильно платформозависим, если выходить за амки х86 M>1. одно дело писать простенькие консольные тулзы, где память алоцируется один-два раза в паре мест, и совсем другое писать большие приложения с сотнями тысяч строк кода в тысячах файлов.
Верно.
M>2. лишь часть программистов имеют достаточную квалификацию, чтобы не допускать багов с утечкой памяти.
Поэтому набираем по объявлению, а потом хелловорды запускаем минимум на кластере, ибо остальное не тянет?
M>3. почему я пишу такие банальности?
Потому что пытаешься оправдать наличие гц, хотя принципиально гц существует сейчас именно из за низкой квалификации погроммистов и их лени.
Здравствуйте, Sheridan, Вы писали:
S>То есть им руки отбивать? А все тут и готовы бы на ц++ писать, без гц и прочего мыла, так вендоры-негодяи не дают? айяйяй
Конечно, друг! Хлебом не корми, дай за жизнью объекта последить!
Здравствуйте, Sheridan, Вы писали:
S>Производительность продукта. Совсем уже забыли что такое понтие есть? Мерием результат работы погроммистов исключительно количеством написанного кода? Про качество уже позабыли, да?
Это ещё доказать нужно, что производительность софтины от GC страдает.
Может быть ты не знаешь, но один из самых распространённых подходо к разработке без GC — reference counting (RC) или, как вариант, Auto Reference Counting (ARC), и я сильно сомневаюсь, что (A)RC быстрее чем GC.
Я профилировал софт и использующий GC и не использующий его. И в моих случаях проблема ВСЕГДА была не в GC и не в (A)RC.
Почему ты считаешь, что GC сколь-нибудь серьёзно влияет на производительность?
Всё сказанное выше — личное мнение, если не указано обратное.
_>>мемристоры — круто, что мешает запускать расово правильные операционки на машинах с такой памятью ?
BE>Другая архитектура мешает. Подробного описания еще нет. Выпустят — посмотрим
непоянтно. Берем обычный PC и заменяем HDD на мемристоры — профит!
далее чуть подкручиваем контроддер памяти и заменяем DRAM на них-же — профит x2!
Здравствуйте, vsb, Вы писали:
vsb>Что же багов-то так много на этой почве? То удалят два раза. То не удалят и память течёт. То по адресу удалённому идут и пишут что-нибудь и всё рушится после дождичка в четверг.
Последний такой баг видел 4 года назад у вчерашних студентов. А вы давно утечку памяти видели?
Здравствуйте, B0FEE664, Вы писали:
vsb>>Что же багов-то так много на этой почве? То удалят два раза. То не удалят и память течёт. То по адресу удалённому идут и пишут что-нибудь и всё рушится после дождичка в четверг.
BFE>Последний такой баг видел 4 года назад у вчерашних студентов. А вы давно утечку памяти видели?
Да полно. Любой браузер течёт. Открываем пару сотен вкладок с флешами и жаваскриптами, через пару недель вся реальная и виртуальная память сожрана, надо перезапускать программу. Я уверен, что в любой достаточно сложной программе на С/С++ утечек памяти, как собак нерезанных. Просто всем пофиг, напишут в инструкции — перезапускайте раз в месяц и всё.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>На самом деле, мне и другие материалы попадались, где это более подробно расписывалось, смысл именно такой, что будет много дешевой, энергонезависимой, быстрой памяти, а РАМу с дисочками отменят.
Вопрос тут только в цене, а не в каких-то принципиальных моментах. Эта MRAM ничем принципиально не отличается от памяти на магнитных сердечниках, которая применялась (и, наверное, применяется) в военных компьютерах времён СССР. В таких специализированных компьютерах даже операционная система не нужна: в памяти ровно одна программа, которая получает данные от сенсоров или с пульта, производит расчёт и выдаёт координаты цели. Программа всегда "запущенна" и никаких тебе файлов, менеджеров задач и прочего операционно-системного софта. Но это в спец. компьютерах.
А в компьютерах общего назначения я принципиальных улучшений не вижу: сбой программы требует перезапуска, а значит данные должны быть отделены от исполняемого кода, значит появляются файлы и базы данных. Сбой в одной программе не должен затронуть исполнения остальных — значит необходим системный менеджер памяти. Более того, какой-нибудь UB баг действительно сможет потереть всю память компьютера.
Здравствуйте, vsb, Вы писали:
vsb>>>Что же багов-то так много на этой почве? То удалят два раза. То не удалят и память течёт. То по адресу удалённому идут и пишут что-нибудь и всё рушится после дождичка в четверг. BFE>>Последний такой баг видел 4 года назад у вчерашних студентов. А вы давно утечку памяти видели? vsb>Да полно. Любой браузер течёт. Открываем пару сотен вкладок с флешами и жаваскриптами, через пару недель вся реальная и виртуальная память сожрана, надо перезапускать программу.
Сдаётся мне, что это как раз результат работы GC всяких жабаскриптов, которые память выделяют и держут по цепочке никогда не отпуская, а C/C++ тут не при делах.
vsb>Я уверен, что в любой достаточно сложной программе на С/С++ утечек памяти, как собак нерезанных. Просто всем пофиг, напишут в инструкции — перезапускайте раз в месяц и всё.
Это не вопрос веры.
