Здравствуйте, Dzirt2005, Вы писали:

D>>>>>Я повторю вопрос — как это связано с осмысленностью установки x64 системы на явно для нее нее недостаточный объем физической памяти?

D>>> — 1 гигабайт (ГБ) (для 32-разрядной системы) или 2 ГБ (для 64-разрядной системы) оперативной памяти (ОЗУ);

BZ>>ага, ксв. ты даже не заметил, как сам себя опроверг
D>Можно показать, где это я себя опроверг и самое главное — в чем? Ты не находишь, что уже давно занимаешься пустым трепом совершенно без каких бы то ни было аргументов?

у тебя ещё и память девичья — мначала ты сообщил нам что 2 гб — "явно недостаточный объём", а затем — что минимальный

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

Здравствуйте, BulatZiganshin, Вы писали:

BZ>у тебя ещё и память девичья — мначала ты сообщил нам что 2 гб — "явно недостаточный объём", а затем — что минимальный
Я для тебя еще раз повторю — 2Gb для x64 системы это минимальный рекомендуемый производителем объем памяти для системы. Что следует понимать как "система запустится, будет выполнять свои базовые функции, но ни о какой комфортной работе речь идти не может". Ты как-то по другому понимаешь минимальные требования к системе? Или я не понимаю в чем ты видишь противоречие???

Здравствуйте, Dzirt2005, Вы писали:

BZ>>у тебя ещё и память девичья — мначала ты сообщил нам что 2 гб — "явно недостаточный объём", а затем — что минимальный
D>Я для тебя еще раз повторю — 2Gb для x64 системы это минимальный рекомендуемый производителем объем памяти для системы. Что следует понимать как "система запустится, будет выполнять свои базовые функции, но ни о какой комфортной работе речь идти не может". Ты как-то по другому понимаешь минимальные требования к системе? Или я не понимаю в чем ты видишь противоречие???

теперь пошла манипуляция понятиями..

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, Dzirt2005, Вы писали:

BZ>>>у тебя ещё и память девичья — мначала ты сообщил нам что 2 гб — "явно недостаточный объём", а затем — что минимальный
D>>Я для тебя еще раз повторю — 2Gb для x64 системы это минимальный рекомендуемый производителем объем памяти для системы. Что следует понимать как "система запустится, будет выполнять свои базовые функции, но ни о какой комфортной работе речь идти не может". Ты как-то по другому понимаешь минимальные требования к системе? Или я не понимаю в чем ты видишь противоречие???

BZ>теперь пошла манипуляция понятиями..
Ясно... Аргументов как не было так и нет. Слил, значит. Ну и ладно.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>>>надо не упоминания искать, а обдумывать прочитанное. кому-то достаточно слова "фрагментация", чтобы понять в чём дело
CC>>Честно говоря "фрагментация адресного пространства" это такой жупел, которым принято пугать детей. Им уже все напуганы но мало кто в жизни с ним на самом деле сталкивался. А те кто сталкивался решали проблему не увеличением адресного пространства (сколько ни дай — всё засрёт, физичка то постранично выделяется и совсем не резиновая) а выпрямлением рук и правильной стратегией аллокации.

BZ>т.е. это пользователи 7-zip должны делать?
нет, автор.

Здравствуйте, netch80, Вы писали:

N>А вот это — да, очень существенно добавляет. И код разбухает на ровном месте.
Там где на W2003 x86 занято 450 метров из 2х гигов на 2008R2 x64 занято 1.5Гб из 4х. Так что даже не 2х а 3х выходит почему то.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, netch80, Вы писали:

N>>А вот это — да, очень существенно добавляет. И код разбухает на ровном месте.
CC>Там где на W2003 x86 занято 450 метров из 2х гигов на 2008R2 x64 занято 1.5Гб из 4х. Так что даже не 2х а 3х выходит почему то.
Тыб еще вин95 х86 сравнил с вин7 х64 ... тогдаб и в 10-20 раз набрал раздницу

Здравствуйте, CreatorCray, Вы писали:

BZ>>>>надо не упоминания искать, а обдумывать прочитанное. кому-то достаточно слова "фрагментация", чтобы понять в чём дело
BZ>>т.е. это пользователи 7-zip должны делать?
CC>нет, автор.

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

Здравствуйте, BulatZiganshin, Вы писали:

BZ>>>>>надо не упоминания искать, а обдумывать прочитанное. кому-то достаточно слова "фрагментация", чтобы понять в чём дело
BZ>>>т.е. это пользователи 7-zip должны делать?
CC>>нет, автор.

BZ>затраты времени плюс уменьшение скорости.
С чего бы вдруг?

BZ> если не удастся рещить проблему иначе как введением дополнительного слоя трансляции адресов — программа может замедлиться в несколько раз.
Это очень примитивное и неверное решение.
Почему бы ему например не сделать в самом начале VirtualAlloc с RESERVE, чтоб зарезервировать непрерывный кусман АП, раз ему надо будет потом сразу и много, и потом с помощью COMMIT выделить там столько памяти сколько ему надо?
Поставил простой эксперимент: в консольной проге со старта без проблем резервируется аж 2'007'105'536 байт непрерывным куском.
Вон только что ради интересу запихал такой код в regression test для одной либы. Выделил 1.5 гига, т.к. самому тесту надо хотяб 400 метров для работы. Отлично отпахал.

BZ> и всё это ради остолопов, которые не хотят использовать 64-битную винду
Ради какого то архиватора менять ОС и иметь все проблемы с этим связанные?
Скажи мне, а чем он в архиваторе так засирает память? Большой блок понятно зачем ему нужен, но что он делает мегатоннами мелких до выделения крупного так, что у него адресное пространство всё оказывается засрано?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>затраты времени плюс уменьшение скорости. если не удастся рещить проблему иначе как введением дополнительного слоя трансляции адресов — программа может замедлиться в несколько раз. и всё это ради остолопов, которые не хотят использовать 64-битную винду
Возьми vmmap и посмотри какая каша творится в памяти у того же 7zfm. У меня например там АП изрядно покоцано динамически загруженными DLL.

Здравствуйте, CreatorCray, Вы писали:

BZ>> если не удастся рещить проблему иначе как введением дополнительного слоя трансляции адресов — программа может замедлиться в несколько раз.
CC>Это очень примитивное и неверное решение.
CC>Почему бы ему например не сделать в самом начале VirtualAlloc с RESERVE, чтоб зарезервировать непрерывный кусман АП, раз ему надо будет потом сразу и много, и потом с помощью COMMIT выделить там столько памяти сколько ему надо?

потому что память нужна для разных нужд. ты предлагаешь ещё и перемещающий сборщик памяти для С написать?

CC>Поставил простой эксперимент: в консольной проге со старта без проблем резервируется аж 2'007'105'536 байт непрерывным куском.
CC>Вон только что ради интересу запихал такой код в regression test для одной либы. Выделил 1.5 гига, т.к. самому тесту надо хотяб 400 метров для работы. Отлично отпахал.

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

BZ>> и всё это ради остолопов, которые не хотят использовать 64-битную винду
CC>Ради какого то архиватора менять ОС и иметь все проблемы с этим связанные?

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

CC>Скажи мне, а чем он в архиваторе так засирает память? Большой блок понятно зачем ему нужен, но что он делает мегатоннами мелких до выделения крупного так, что у него адресное пространство всё оказывается засрано?

ты никогда на С не программировал?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>>> если не удастся рещить проблему иначе как введением дополнительного слоя трансляции адресов — программа может замедлиться в несколько раз.
CC>>Это очень примитивное и неверное решение.
CC>>Почему бы ему например не сделать в самом начале VirtualAlloc с RESERVE, чтоб зарезервировать непрерывный кусман АП, раз ему надо будет потом сразу и много, и потом с помощью COMMIT выделить там столько памяти сколько ему надо?
BZ>потому что память нужна для разных нужд. ты предлагаешь ещё и перемещающий сборщик памяти для С написать?
Ты вообще понял о чём я говорил?
В случае с тем же 7zFM.exe АП фрагментируется не сколько аллокатором хипа сколько загрузкой сторонних DLL, маппингом файлов и аллокацией памяти под стеки потокам и прочими подкапотными прелестями.
Заранее зарезервировав непрерывный кусок АП ты сможешь гарантировать, что посреди АП никакая скотина не намусорит и у тебя будет целый блок нужного размера. Вся остальная шелуха утрамбуется в оставшейся части АП.

CC>>Поставил простой эксперимент: в консольной проге со старта без проблем резервируется аж 2'007'105'536 байт непрерывным куском.
CC>>Вон только что ради интересу запихал такой код в regression test для одной либы. Выделил 1.5 гига, т.к. самому тесту надо хотяб 400 метров для работы. Отлично отпахал.
BZ>а потом ты пишешь gui-приложение и оказывается, что эти библиотеки ещё до тебя поделили всю память
DelayLoad?

BZ>антивирусы цепляют свои dll в адресное пространство любых процессов. и не только они
При желании даже такую напасть можно обойти. По крайней мере воспроизвести не могу, у меня нет ничего что бы внедряло DLL во все процессы до того как я получаю управление.

BZ>>> и всё это ради остолопов, которые не хотят использовать 64-битную винду
CC>>Ради какого то архиватора менять ОС и иметь все проблемы с этим связанные?
BZ>ОС поменять всё равно придётся. если конечно твои задачи выходят за пределы диггера.
Единственная причина для меня сменить ОС в данный момент это то, что во всех виндах кроме самых последних в принципе не работает hibernate если памяти 4гига и выше.
В перспективе — отсутствие жизненно необходимого софта под х86. Но это произойдёт видимо довольно нескоро.

BZ>и у разработчика тут есть выбор — либо ещё пару лет потворствовать ретроградам и потом выкинуть написанное или допиливать те фичи, которые нужны всем.
Т.е. сказать юзеру "на ваших ОС я работать не буду потому как я ленивый не хочу потворствовать ретроградам"? Боюсь что юзер не оценит шутку, выкинет прогу и запишет разработчка в чёрный список раньше, чем х64 ОС станут доминирующими.

BZ> поддержка устаревающего железа — очень глупое занятие. как раз к тому времени как её окончательно доделаешь — она окончательно и устареет
А какое отношение х86 ОС имеет к железу. Вон у меня на х64 проце стоит х86 ОС. Куплю новый — поставлю ту же ОС. Ибо стабильное рабочее окружение куда ценнее чем мифическая выгода от х64. Офисный комп у меня как раз под х64 виндой, ибо проект изначально был под х64. Правда "суровые реалии" жизни таковы что портировали недавно часть проекта на Win2003 x86/64.
Так вот, имея возможность сравнить работу под Win2003 x86 и под 2008R2 x64 (на бОльшем объёме памяти и почти 1.4 раза более быстром проце) могу сказать: 2008R2 x64 тормозит, а бонусов от неё никаких, кроме работающего hibernate при большом объёме памяти.

CC>>Скажи мне, а чем он в архиваторе так засирает память? Большой блок понятно зачем ему нужен, но что он делает мегатоннами мелких до выделения крупного так, что у него адресное пространство всё оказывается засрано?
BZ>ты никогда на С не программировал?
Именно на С++ и пишу. Вот только таких проблем даже во время работы в геймдеве не имел, хотя память мы тогда занимали вообще всю как на хосте так и на видюхе.

Здравствуйте, Ytz, Вы писали:

Ytz>Особенно убивает выключение по пять минут, что она там делает?

Сохраняет на диск образ памяти.

Ytz> И изредка фризы — система полностью перестает откликаться на пару минут, при этом мигает светодиод харда (проверено на нескольких машинах).

100% проблемы с железом или драйверами.

Здравствуйте, CreatorCray, Вы писали:

CC>Это если у тебя есть долгоживущий и сильносрущий в память процесс.

VS это как раз оно и есть.

Здравствуйте, CreatorCray, Вы писали:

BZ>>надо не упоминания искать, а обдумывать прочитанное. кому-то достаточно слова "фрагментация", чтобы понять в чём дело
CC>Честно говоря "фрагментация адресного пространства" это такой жупел, которым принято пугать детей.

Для кого жупел, а для кого постоянный геморой.

CC>А те кто сталкивался решали проблему не увеличением адресного пространства (сколько ни дай — всё засрёт, физичка то постранично выделяется и совсем не резиновая) а выпрямлением рук и правильной стратегией аллокации.

Не всегда стратегию аллокации можно поменять для всего процесса. Например когда ты пишешь плагин к чему нибудь.
А в случае управляемых сред добавляется еше и дополнительая специфика типа LOB в дотнете.

Здравствуйте, system.console, Вы писали:

A_V>>Просто интересно — там в свойствах компьютера есть пункт "индекс производительности Windows" — какое там значение? У меня для Win7х64HomeExt 5,9 — ничего не тормозит.
SC>4,6

Наверное имеет смысл поотрубать автозапуск ненужных служб через msconfig — 4,6 не очень много по шкале от 1 до 8. Плюс, потестить как будет работать при оключенном антивирусе — мож он тормозит сильно.

Здравствуйте, Alexey_VL, Вы писали:
A_V>>>Просто интересно — там в свойствах компьютера есть пункт "индекс производительности Windows" — какое там значение? У меня для Win7х64HomeExt 5,9 — ничего не тормозит.
SC>>4,6
A_V>Наверное имеет смысл поотрубать автозапуск ненужных служб через msconfig — 4,6 не очень много по шкале от 1 до 8. Плюс, потестить как будет работать при оключенном антивирусе — мож он тормозит сильно.

Уменя индекс вообще 2.3. Но работает вполне шустренько, не тормозит

Здравствуйте, Nik_1, Вы писали:

N_>Уменя индекс вообще 2.3. Но работает вполне шустренько, не тормозит

Забавно%) А в расширенной сводке — по всем параметрам так мало, или может это только по графической карте?

Здравствуйте, Alexey_VL, Вы писали:

A_V>Здравствуйте, Nik_1, Вы писали:

N_>>Уменя индекс вообще 2.3. Но работает вполне шустренько, не тормозит

A_V>Забавно%) А в расширенной сводке — по всем параметрам так мало, или может это только по графической карте?
Это нетбук на атоме. В остальных параметрах чуть лучше, но тож низкие значения.

Здравствуйте, system.console, Вы писали:

SC>Здравствуйте, 4UBAKA, Вы писали:

UBA>>Здравствуйте, system.console, Вы писали:

SC>>>А еще меня убивает открывание менюшек по десятку-полтора секунд и выбор писем в Live Mail по стольку же, если не дольше.

UBA>>Что за система то, включая хард?
SC>AMD Athlon 64 X2 Dual Core 5200+ 2,59 GHz
SC>ОЗУ 2Gb
SC>Hdd: WDC WD15EARS-00Z5B1 (1397 Gb), WDC WD1600AAJS-75PSAO (149Gb)
SC>тормоз установлен на первый винт

Скорее всего проблема не в винде, а в винте. Убедись, что твой винт не имеет Advanced Format и нестандертный размер сектора в 64к. Также убедись что в биосе включен EHCI и винда подключила правильные драйвера.

У меня недавно была подобная пробелма (винт WD AARS (Advanced Format, 64k сектор)), при большом объеме оперативы (8Гб) система периодически подвисала, и медленно компиляля/чекаутила из репозитория. Анализ показал, что была очень большая очередь дисковых операций (10-15 в Resource monitor). Проблема была при работе с большим количеством мелких файлов, если копировать один большой файл — то все ок. В инете нашел, что такие винты надо алигнить спец тулзой WD Align tool. Но у меня проблема при этом не решилась. Зато решилась заменой винта на обычный с 512b сектор.

Чекаут репозитория при этом уменьшился с 2-х часов до 15 минут.