Re[9]: HP. The Machine. Взлетит?
От: 0BD11A0D  
Дата: 13.12.14 23:56
Оценка:
Здравствуйте, dimgel, Вы писали:

D>хоть всю физическую память на свете


16 терабайт дисковой памяти на 32-битной винде, если верить Липперту. На 64-битной — 256 терабайт.
Re[10]: HP. The Machine. Взлетит?
От: TK Лес кывт.рф
Дата: 14.12.14 00:33
Оценка:
Здравствуйте, 0BD11A0D, Вы писали:

BDA>16 терабайт дисковой памяти на 32-битной винде, если верить Липперту. На 64-битной — 256 терабайт.

Липперт вам пишет про винду и 16 терабайт на процесс это личные заморочки винды.

PS
Кстати, вы точно физическую память с виртуальной не путаете? на x86 максимум можно получить 36бит на адрес (максимум 64Gb физической памяти)
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Отредактировано 14.12.2014 2:29 TK . Предыдущая версия .
Re[6]: HP. The Machine. Взлетит?
От: мыщъх США http://nezumi-lab.org
Дата: 14.12.14 01:07
Оценка:
Здравствуйте, TK, Вы писали:

TK>Здравствуйте, 0BD11A0D, Вы писали:


BDA>>Если вы понимаете, что такое ВП, то должны понимать, что в средах с быстрой, однородной, энергонезависимой памятью она не нужна.


TK>ОС без ВП уже были — MS DOS одна из них.

была в дос виртуальная память. не в первой версии, но была. при желании было можно даже BIOS выкинуть из адресного пространства, отдав нижнюю память тем, кому она нужна.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[11]: HP. The Machine. Взлетит?
От: 0BD11A0D  
Дата: 14.12.14 02:04
Оценка:
Здравствуйте, TK, Вы писали:

BDA>>16 терабайт дисковой памяти на 32-битной винде, если верить Липперту. На 64-битной — 256 терабайт.

TK>Липперт вам пишет про винду

Виртуальную память не в Микрософте придумали. Если посмотреть историю внедрения, прямо с 1956 года, мотив всегда был один: есть primary memory, она дорогая, быстрая и ее мало, и есть secondary memory, она дешевле, медленнее и ее больше. Ручное управление этими двумя видами неудобно, но можно притвориться, что у нас много primary memory, а за кулисами сбрасывать ее в secondary. Именно поэтому память и называется виртуальной, то есть неотличимой от настоящей. В том компьютере, который делает HP, если верить ее пиарам, вся память одинаково быстрая, недорогая, и ее много. Притворяться больше не надо. Возможно, придется притворяться, что адрес указывает на реальную память, в то время, как потребуется какое-то преобразование, но это называется виртуальный адрес, а не виртуальная память.

> и 16 терабайт на процесс это личные заморочки винды.


Да, и что?
Re[12]: HP. The Machine. Взлетит?
От: TK Лес кывт.рф
Дата: 14.12.14 02:51
Оценка:
Здравствуйте, 0BD11A0D, Вы писали:

BDA>Виртуальную память не в Микрософте придумали. Если посмотреть историю внедрения, прямо с 1956 года, мотив всегда был один: есть primary memory, она дорогая, быстрая и ее мало, и есть secondary memory, она дешевле, медленнее и ее больше. Ручное управление этими двумя видами неудобно, но можно притвориться, что у нас много primary memory, а за кулисами сбрасывать ее в secondary. Именно поэтому память и называется виртуальной, то есть неотличимой от настоящей. В том компьютере, который делает HP, если верить ее пиарам, вся память одинаково быстрая, недорогая, и ее много. Притворяться больше не надо. Возможно, придется притворяться, что адрес указывает на реальную память, в то время, как потребуется какое-то преобразование, но это называется виртуальный адрес, а не виртуальная память.


Похоже на рассуждения в 640Кб хватит всем — ограничение в 256Tb на x64 тоже не от хорошей жизни.
Не надо думать, что новый тип памяти принципиально что-то изменит — это как HDD vs SSD. Да, станет быстрее, но в целом все останется как и было.

>> и 16 терабайт на процесс это личные заморочки винды.


BDA>Да, и что?


Просто интересно откуда это взялось
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[2]: Забодали уже!
От: Sheridan Россия  
Дата: 14.12.14 08:45
Оценка: +1 -4 :)))
Здравствуйте, vsb, Вы писали:

vsb> Глобальный GC.


Да заколебали вы уже своей ленью и невнимательностью! Суёте свой расово-православный gc везде. Что, тааааак сложно следить за жизнью объекта?
Matrix has you...
Re[3]: Забодали уже!
От: vsb Казахстан  
Дата: 14.12.14 08:56
Оценка:
Здравствуйте, Sheridan, Вы писали:

vsb>> Глобальный GC.


S>Да заколебали вы уже своей ленью и невнимательностью! Суёте свой расово-православный gc везде. Что, тааааак сложно следить за жизнью объекта?


Следить не сложно. Но затратно по мозговым ресурсам. И при этом неизбежны ошибки. А ошибки управления памятью особенно неприятны. Поэтому GC во все поля.
Re[4]: Забодали уже!
От: Sheridan Россия  
Дата: 14.12.14 09:01
Оценка: -2
Здравствуйте, vsb, Вы писали:

S>>Да заколебали вы уже своей ленью и невнимательностью! Суёте свой расово-православный gc везде. Что, тааааак сложно следить за жизнью объекта?

vsb>Следить не сложно. Но затратно по мозговым ресурсам. И при этом неизбежны ошибки. А ошибки управления памятью особенно неприятны. Поэтому GC во все поля.

Что? Нужно думать о том как и где удалить? Нифига себе, с каких пор тривиальную задачу надо думать? Время жизни объекта известно не просто с его создания, а еще с его проектирования в голове.
Matrix has you...
Re[5]: Забодали уже!
От: vsb Казахстан  
Дата: 14.12.14 10:52
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>>>Да заколебали вы уже своей ленью и невнимательностью! Суёте свой расово-православный gc везде. Что, тааааак сложно следить за жизнью объекта?

vsb>>Следить не сложно. Но затратно по мозговым ресурсам. И при этом неизбежны ошибки. А ошибки управления памятью особенно неприятны. Поэтому GC во все поля.

S>Что? Нужно думать о том как и где удалить? Нифига себе, с каких пор тривиальную задачу надо думать? Время жизни объекта известно не просто с его создания, а еще с его проектирования в голове.


Что же багов-то так много на этой почве? То удалят два раза. То не удалят и память течёт. То по адресу удалённому идут и пишут что-нибудь и всё рушится после дождичка в четверг.
Re[6]: Забодали уже!
От: Sheridan Россия  
Дата: 14.12.14 10:54
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>Что же багов-то так много на этой почве? То удалят два раза. То не удалят и память течёт. То по адресу удалённому идут и пишут что-нибудь и всё рушится после дождичка в четверг.


Предполагаю лень. Как вариант — слабоумие и отвага.
Matrix has you...
Re[7]: Забодали уже!
От: dimgel Россия https://github.com/dimgel
Дата: 14.12.14 10:59
Оценка: +2 -1 :)
Здравствуйте, Sheridan, Вы писали:

vsb>>Что же багов-то так много на этой почве? То удалят два раза. То не удалят и память течёт. То по адресу удалённому идут и пишут что-нибудь и всё рушится после дождичка в четверг.


S>Предполагаю лень.


Лень — это то, что заставляет использовать языки с GC. И она, как известно, — двигатель прогресса. Ты сейчас — ретроград с топором, презрительно плюющий на парней с бензопилами, которым лень топором махать и вообще они дохляки рядом с мускулистым тобой.
Re[8]: Забодали уже!
От: dimgel Россия https://github.com/dimgel
Дата: 14.12.14 11:07
Оценка:
Здравствуйте, dimgel, мы писали:

D>Лень — это то, что заставляет использовать языки с GC. И она, как известно, — двигатель прогресса. Ты сейчас — ретроград с топором, презрительно плюющий на парней с бензопилами, которым лень топором махать и вообще они дохляки рядом с мускулистым тобой.


А багов с ручным управлением памяти много не из-за лени, а просто потому что человек — не машина, и ему свойственно ошибаться. GC автоматически и полностью устраняет широкий класс ошибок, так же как статическая типизация — другой широкий класс ошибок.
Re[13]: HP. The Machine. Взлетит?
От: 0BD11A0D  
Дата: 14.12.14 11:16
Оценка: :)
Здравствуйте, TK, Вы писали:

BDA>>Виртуальную память не в Микрософте придумали. Если посмотреть историю внедрения, прямо с 1956 года, мотив всегда был один: есть primary memory, она дорогая, быстрая и ее мало, и есть secondary memory, она дешевле, медленнее и ее больше. Ручное управление этими двумя видами неудобно, но можно притвориться, что у нас много primary memory, а за кулисами сбрасывать ее в secondary. Именно поэтому память и называется виртуальной, то есть неотличимой от настоящей. В том компьютере, который делает HP, если верить ее пиарам, вся память одинаково быстрая, недорогая, и ее много. Притворяться больше не надо. Возможно, придется притворяться, что адрес указывает на реальную память, в то время, как потребуется какое-то преобразование, но это называется виртуальный адрес, а не виртуальная память.


TK>Похоже на рассуждения в 640Кб хватит всем — ограничение в 256Tb на x64 тоже не от хорошей жизни.


Я лично не знаю, от какой жизни. Мне всегда казалось, это какое-то конъюнктурно-экономически-искусственное ограничение, типа 10К хендлов на винду. Просто потому, что никаких других естественных ограничителей кроме размера secondary memory быть не может.

TK>Не надо думать, что новый тип памяти принципиально что-то изменит — это как HDD vs SSD. Да, станет быстрее, но в целом все останется как и было.


Может, вы не прочитали? Новый там не тип памяти. Новый там отказ от разделения на RAM/HDD(SSD). На самом деле, конечно, тип памяти, позволивший отказаться от разделения, тоже новый, но не это главное.
Re[14]: HP. The Machine. Взлетит?
От: dimgel Россия https://github.com/dimgel
Дата: 14.12.14 11:31
Оценка:
Здравствуйте, 0BD11A0D, Вы писали:

TK>>Не надо думать, что новый тип памяти принципиально что-то изменит — это как HDD vs SSD. Да, станет быстрее, но в целом все останется как и было.


BDA>Новый там отказ от разделения на RAM/HDD(SSD).


Ну так и что изменится?
1. Например, я машину никогда не выключаю, а увожу в suspend. На мемристорах это поведение станет дефолтным, но для меня ничего не изменится.
2. Будет ли упразднена концепция файла? Сильно сомневаюсь: она ключевая и логическая, а не физическая. Компиляторы точно также будут брать файлы исходников, компилировать в объектники и линковать. Ну, может линковка упразднится... хотя по чуть дольшему размышлению непонятно, за счёт чего: адресные пространства останутся наверняка даже в своём нынешнем виде (они ж уже сейчас удобные плоские-линейные), динамическая линковка останется.

А кстати, у мемристоров есть лимит на количество циклов перезаписи, как у SSD?
Re[9]: Забодали уже!
От: Sheridan Россия  
Дата: 14.12.14 11:54
Оценка:
Здравствуйте, dimgel, Вы писали:

D>А багов с ручным управлением памяти много не из-за лени, а просто потому что человек — не машина, и ему свойственно ошибаться. GC автоматически и полностью устраняет широкий класс ошибок, так же как статическая типизация — другой широкий класс ошибок.

Угу. Жертвуем производительностью в угоду собственной лени\некомпетентности\нежелания разбираться? Типа "а, нахер, и так сойдет, уборщик мусора ж есть, поди сам разберется", да?
Matrix has you...
Re[10]: Забодали уже!
От: dimgel Россия https://github.com/dimgel
Дата: 14.12.14 12:07
Оценка: +2
Здравствуйте, Sheridan, Вы писали:

S>Угу. Жертвуем производительностью в угоду собственной лени\некомпетентности\нежелания разбираться? Типа "а, нахер, и так сойдет, уборщик мусора ж есть, поди сам разберется", да?


Сам-то небось на ассемблере пишешь, раз такие предъявы кидаешь, м?
Re[10]: Забодали уже!
От: Privalov  
Дата: 14.12.14 12:37
Оценка: :)
Здравствуйте, Sheridan, Вы писали:

S>Угу. Жертвуем производительностью в угоду собственной лени\некомпетентности\нежелания разбираться? Типа "а, нахер, и так сойдет, уборщик мусора ж есть, поди сам разберется", да?


Программист сосредотачивается на решении задачи, не отвлекаясь на раздражающие частности. Следовательно, производительность программиста возрастает. В чем жертва?
Отредактировано 14.12.2014 12:38 Privalov . Предыдущая версия .
Re[11]: Забодали уже!
От: Sheridan Россия  
Дата: 14.12.14 13:35
Оценка:
Здравствуйте, Privalov, Вы писали:

S>>Угу. Жертвуем производительностью в угоду собственной лени\некомпетентности\нежелания разбираться? Типа "а, нахер, и так сойдет, уборщик мусора ж есть, поди сам разберется", да?

P>Программист сосредотачивается на решении задачи, не отвлекаясь на раздражающие частности. Следовательно, производительность программиста возрастает. В чем жертва?
Производительность продукта. Совсем уже забыли что такое понтие есть? Мерием результат работы погроммистов исключительно количеством написанного кода? Про качество уже позабыли, да?
Matrix has you...
Re[11]: Забодали уже!
От: Sheridan Россия  
Дата: 14.12.14 13:36
Оценка:
Здравствуйте, dimgel, Вы писали:

D>Сам-то небось на ассемблере пишешь, раз такие предъявы кидаешь, м?

с++. Ассемблер сильно платформозависим, если выходить за амки х86
Matrix has you...
Re[12]: Забодали уже!
От: Muxa  
Дата: 14.12.14 13:51
Оценка: :))
D>>Сам-то небось на ассемблере пишешь, раз такие предъявы кидаешь, м?
S>с++. Ассемблер сильно платформозависим, если выходить за амки х86
1. одно дело писать простенькие консольные тулзы, где память алоцируется один-два раза в паре мест, и совсем другое писать большие приложения с сотнями тысяч строк кода в тысячах файлов.
2. лишь часть программистов имеют достаточную квалификацию, чтобы не допускать багов с утечкой памяти.
3. почему я пишу такие банальности?
Отредактировано 14.12.2014 13:52 Muxa . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.