Comments 164
Поставьте 8 гб и почувствуйте разницу.
это как в свое время было хорошо различимо 64 и 128 мегабайт, а вот с 128 до 256 разницы было мало. именно в тот момент когда 256 только появилось еще во время 98 окон.
PS: Я уже думал что 32 битки умерли и в живых остались единичные случае или сильно упорные или с нехваткой финансов для такого перехода. Тут глядишь уже 128 бит назревает а народ еще ломается переходить или нет на 64 -)
это как в свое время было хорошо различимо 64 и 128 мегабайт, а вот с 128 до 256 разницы было мало. именно в тот момент когда 256 только появилось еще во время 98 окон.
PS: Я уже думал что 32 битки умерли и в живых остались единичные случае или сильно упорные или с нехваткой финансов для такого перехода. Тут глядишь уже 128 бит назревает а народ еще ломается переходить или нет на 64 -)
Хорошо бы, только сервер за границей находится :-) Конфигурация фиксированная.
Если поставлю памяти 8Гб вместо 4Гб, от этого ее потребление меньше не станет.
Хочу, чтобы Apache2 кушал 20Мб вместо 50.
Если поставлю памяти 8Гб вместо 4Гб, от этого ее потребление меньше не станет.
Хочу, чтобы Apache2 кушал 20Мб вместо 50.
Переезжая с сервера с 2Гб на сервер с 4Гб потенциально хочется, чтобы во вдвоем большем объеме памяти помещалось вдвое большее количество процессов.
Смысл в 64 битах только есть есть приложение которому надо вдресовать больше 2гиг памяти. Чтобы система видела больше 4 гиг есть PAE.
P.S.
надо переходить на 64 бита это да, но нафига мне адресовать больше памяти приложениям который на 32 битах себя хорошо вели? У меня лично нет потребности чемуто адресовать большие обьямы памяти на десктопе :)
P.P.S.
у меня просто старый бук :) core duo, 2GB max :)
P.S.
надо переходить на 64 бита это да, но нафига мне адресовать больше памяти приложениям который на 32 битах себя хорошо вели? У меня лично нет потребности чемуто адресовать большие обьямы памяти на десктопе :)
P.P.S.
у меня просто старый бук :) core duo, 2GB max :)
На 64 битах можно получить клевые плюшки в виде немалого ускорения для мультимедиа-программ типа кодирования видео или аудио. К тому же, как ни говорите, но PAE — это костыль :)
ну этот как раз тот случай когда нужно сразу большие обьемы адресовать. Согласитесь не всем нужны 64 бита? :) Мне концепция: «А то получается, что увеличили в машине бензобак и объем двигателя в два раза» не устраивает если мне нужены такие обьебы бензобака и движка :)
P.S.
PAE костыль еще какой! в некоторых случаях это вообще флагшток-кун :)
P.S.
PAE костыль еще какой! в некоторых случаях это вообще флагшток-кун :)
А можна пруфлинк на сравнение где видно немалое увеличение производительности при переходе на 64 бита?
попробуйте конвертнуть DV видео на макбуке с Snow Leopard сначала в 32 бит, потом в 64
ну как минимум разница полтора часа должна о чем-то говорить
ну как минимум разница полтора часа должна о чем-то говорить
Например о хреновой оптимизации на 32 битах?
Проблемы с оптимизацией какраз могут быть на x64, но это опять же стереотип, живший в головах несколко лет назад. Сейчас уже научились писать нормальные приложения адекватно оперирующие 64 разрядами.
Просто мне внушает подозрение разница в полтора часа. Разумеется, я знаю что 64 битная архитектура может дать прирост в производительности. Но не в такой же степени?!?
Я пару лет назад сравнивал на E4600 кодирование в H.264 на 32-х и 64-х битной убунте. Разница ~ 15% в пользу 64-х битной ОСи. Результаты за давностью лет затерялись на просторах тырнета.
PAE не работает для более чем 16 GiB. Кончается LowMem и OOM killer убивает машину.
OOM killer убивает только процессы. И то не любые. И делает это, когда кончается виртуальная память.
Как это связано с PAE, 16GiB и LowMem?
Как это связано с PAE, 16GiB и LowMem?
OOM killer на 32-битной архитектуре убивает процессы, когда кончается HighMem или LowMem. В случае использования более чем 16 GiB (32 GiB) под 32-битным PAE LowMem заполняется за день-два средней нагрузки, после чего OOM killer начинает убивать процессы. Что в конце концов приводит к смерти системы.
При ограничении памяти до 16GiB LowMem не забивается и OOM не вызывается. При 32 GiB забивается за 2 дня.
При ограничении памяти до 16GiB LowMem не забивается и OOM не вызывается. При 32 GiB забивается за 2 дня.
В дополнение к предыдущему комментарию, чтобы не думали что я теорией тут занимаюсь. Данное поведение замечено на наших 8 серваках с 32 GiB памяти. Срочно меняем систему на 64-битную.
Единственное из упоминаний этого феномена нашли на www.linux-mm.org/
Проблема временно решается сбрасыванием дисковых кэшей. Но помогает ненадолго. Как-только LowMem кончается начинает свою грязную работу OOM killer. При этом HighMem даже на половину не занят.
Единственное из упоминаний этого феномена нашли на www.linux-mm.org/
Проблема временно решается сбрасыванием дисковых кэшей. Но помогает ненадолго. Как-только LowMem кончается начинает свою грязную работу OOM killer. При этом HighMem даже на половину не занят.
ptgmedia.pearsoncmg.com/images/0131453483/downloads/gorman_book.pdf
Пункт 2.7 этой книжки немного объясняет в чём дело. А какое же у вас ядро?
Пункт 2.7 этой книжки немного объясняет в чём дело. А какое же у вас ядро?
Вместо Apache для php лучше использовать nginx.
Память давно не ресурс.
Смысл в 64 очевиден — можно адресовать более 4 Гб (кому мало). А вот смысл в 128 битах какой?
можно адресовать больше чем 128 Гб
думаю смысл в более быстрых процессорных операциях, возможно, будут какие-то комбинированные операции: операции над частями строк, анализ потоковой информации обработки сигналов и тому подобное…
Прогресс от математических вычислений смещается в сторону обработки текстовой информации, к быстрому ее анализу.
разработка ОС пока не догонянет железо…
думаю смысл в более быстрых процессорных операциях, возможно, будут какие-то комбинированные операции: операции над частями строк, анализ потоковой информации обработки сигналов и тому подобное…
Прогресс от математических вычислений смещается в сторону обработки текстовой информации, к быстрому ее анализу.
разработка ОС пока не догонянет железо…
В связи с этим вопрос — можно ли безболезненно сделать даунгрейд на 32-битное ядро или же возможно только переустановить ОС?
Выигрыш в том, что вашему процессу доступно адресное пространство > 4G. Если оно вам надо, конечно. Другие знающие люди утверждают, что компиляторы для 64битных процессоров способны генерировать более оптимальный код (и уже используют это для нужд системного программирования — там, фрейм задачи, фрейм вызова, все дела), но мы то знаем.
Первая вообще не в тему, т.к. скорее про маркетинг Intel, а не про технологии. Вторая… в стиле THG — с первых же строк сказки для чайников: самые первые математические сопроцессоры 8087 имели 80-битные регистры. А тут оказывается бедные учёные без 64 бит недополучали математическую точность — сиротинушки…
Все как-то забыли о том, что в x86_64 доступно аж 16 регистров общего назначения (в противовес 8 у IA-32). Это позволяет намного меньше заниматься пересылкой данных из стека в регистры и наоборот.
Адресация данных относительно регистра RIP (instruction pointer). Позволяет компилятору генерировать более эффективный position-independent код.
Адресация данных относительно регистра RIP (instruction pointer). Позволяет компилятору генерировать более эффективный position-independent код.
Прошу не путать x86_64 и ia64. ia64 — дйствительно 64х битная архитектура, а x86_64 расширение ia32
Тем не менее x86_64 и ia64 не совместимы
Пруфлинк
software.intel.com/en-us/articles/intel-extended-memory-64-technology-faq/
И короткая цитата:
«Intel® Extended Memory 64 Technology, or Intel®64, is an enhancement to Intel's IA-32 architecture.»
software.intel.com/en-us/articles/intel-extended-memory-64-technology-faq/
И короткая цитата:
«Intel® Extended Memory 64 Technology, or Intel®64, is an enhancement to Intel's IA-32 architecture.»
64 vs 32 — в чем выигрыш?