[ЖЖ][Citrix]Передасты

Если цитрикс помрет - то у ксена могут быть проблемы, не? Если сразу не сдохнет, то проволочка в развитии будет наверняка, imo. Тогда KVM еще и получит ауру продукта со стабильной «судьбой» и тогда ксену постепенно хана.

Впрочем, я на стороне KVM

Вот кстати давно хотел спросить - насколько KVM медленнее, чем Xen? Или вообще не медленнее?

бывает. Думаю, что поставлю 32 как ещё одну систему, т.к. подобные ситуёвины заенадоели.

Я б померял, но сейчас довольно далеко от машинки. Вообще же KVMщики клянутся, что быстрее, приводят пример с получением и обработкой пакета. Звучало так

Случай Xen - на (микро)ядро (гипервизор) приходит прерывание о пакете, ядрышко переключается в контекст dom0, там пакет принимается(обрабатывается), передается в нужную ОС, контекст переключается

случай KVM - на ядро (гипервизор) приходит прерывание о пакете, ядро его обрабатывает, передает в нужную ОС, все довольны. В плюс идет то, что для применения всяких приемов и прочего не нужно переключатся в контексте, сам гипервизор это умеет.

Конец срача на эту тему я не застал, так что точнее и с опровержениями сказат не могу. Проверять надо. Кстати, у меня на KVM не было ни одного удачного сохранения снапшота. Надо еще попробовать

> насколько KVM медленнее, чем Xen?

Практически ровно. По данным лета 2008 года, KVM несколько быстрее в I/O, Xen несколько быстрее во всяких передачах сигналов, событий и прочего.

а нехрен жрать 64-битные кактусы. 32-битные справляются с любыми задачами на данный момент.

32-битные справляются с любыми задачами на данный момент.

Да-да. Любую программу можно написать на брейнфаке.

Tails> а нехрен жрать 64-битные кактусы. 32-битные справляются с любыми задачами на данный момент.

Возможность использовать больше оперативной памяти без костылей. Нэ?

Xen уже сдох, и он уже не развивается. И ему уже сейчас хана. Спасибо Цитриксу.

> Presentation Server только через плагин, а плагин под линукс (ну кто бы сомневался!) 32-битный.

Работает нормально и на 64-битном.

>Тем же самым отличалась Sun со своим java plugin, а чем кончила Sun все знают

У джавы уже сколько лет есть 64-битный плагин

> У джавы уже сколько лет есть 64-битный плагин
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695

и сколько ?))
как они достали меня с клиент-банком на жабе ...

Написано же, 2 года :)

К тому же ещё до этого был icedtea, хотя его было тяжело собрать

шо за истерики в сам деле?

А вот на Java не надо гнать. Sun JDK 1.6 на [amd64] имеет 64-битный плагин, который прекрасно работает в Firefox 3.6.

>Tails> а нехрен жрать 64-битные кактусы. 32-битные справляются с любыми задачами на данный момент.

Возможность использовать больше оперативной памяти без костылей. Нэ?

Больше - это скока?

До 4 гигабайт оперативки делать вообще ничего не нужно, далее - поможет включение «волшебного» PAE - http://ru.wikipedia.org/wiki/PAE

При использовании же 64 бит расход оперативки увеличивается сразу, поскольку вся адресная арифметика становится 64-битной.

Считаю не опраданным применение 64-битных систем до тех пор, пока на компьютере нет, как минимум, 8 гигабайт оперативки.

>При использовании же 64 бит расход оперативки увеличивается сразу, поскольку вся адресная арифметика становится 64-битной.

Садись, два.

>Садись, два.

А что не так-то? Все указатели в программах на Си после перекомпиляции в памяти будут занимать не 32, а 64 бита. Ну и остальные целочисленные 32-битные переменные, объявлённые типом int, тоже станут занимать 64 бита.

> Ну и остальные целочисленные 32-битные переменные, объявлённые типом int, тоже станут занимать 64 бита.

Какое гнусное, махровое 4.2! После DEC C на Альфах это 4.2.

http://www.viva64.com/content/articles/64-bit-development/?f=amd64_em64t_rus....

Серьезных недостатков в 32-битную архитектуру новая архитектура AMD x86-64 не внесла. Отметить можно разве лишь чуть большие требования программ к памяти из-за того, что увеличился размер адресов и операндов. Однако это серьезно не скажется ни на размере кода, ни на требованиях к объему доступной оперативной памяти.

Попробуй провести тесты на 64-битной системе. Запусти сначала 32-битное приложение, посмотри, сколько оно израсходует памяти. Затем запусти то-же приложение, но уже 64-битное. Существенной разницы ты не увидишь.

>Попробуй провести тесты на 64-битной системе. Запусти сначала 32-битное приложение, посмотри, сколько оно израсходует памяти. Затем запусти то-же приложение, но уже 64-битное. Существенной разницы ты не увидишь.

Я и не говорил про существенную разницу, но разница будет и будет она не в пользу 64 битов. Поэтому если памяти не более 4 гигабайт, то и смысла использовать 64-битную ОС обычно нет, особенно если можно поиметь проблемы со всякими блобами, которые есть только в 32-битном варианте.

Аргумент «Возможность использовать больше оперативной памяти без костылей», как основание для использования 64-бит, не канает. Ну адресация, ну без костылей, и что? Теперь этими 64-битами обмазаться что-ли?

>но разница будет и будет она не в пользу 64 битов

Не правда. Память расходуется не только на указатели. Советую всё же проверить.

И, кстати, вкурсе, что PAE существенно замедляет работу системы?

> Sun JDK 1.6 на [amd64] имеет 64-битный плагин

А теперь вопрос на засыпку - сколько версий 64-битного JRE содержали плагина? :-)

> Практически ровно. По данным лета 2008 года, KVM несколько быстрее в I/O, Xen несколько быстрее во всяких передачах сигналов, событий и прочего.

а ты KVM какой пользуешь? С последними ядрами самосборными или редхетовский?

а где «[НЕНАВИСТЬ]» ?

>И, кстати, вкурсе, что PAE существенно замедляет работу системы?

А бенчмарки можно? А то я вот тоже в это верил...

Во-первых, даже с PAE нельзя адресовать более 4 Гб на процесс, Во-вторых (сюрприз-сюрприз), доступно из них пользователю будет 2 или 3 Гб только, в-третьих, даже с PAE адреса ввода-вывода перекроют доступ к большей части последнего из 4 Гб, что приведет к их потере.

Нет ни одной причины продолжать использовать 32-бита при объеме памяти от 3 Гб и выше. Что уже совсем не редкость.

Здесь сравнивают производительность non-PAE 32-bit, PAE 32-bit и x86_64. Сравнивают на машине с 4Gb RAM. Non-PAE kernel может адресовать 3.2Gb, и, не смотря на это показывает сходную с PAE производительность. Разница между PAE и x86_64 гораздо более существенна.

> а ты KVM какой пользуешь? С последними ядрами самосборными или редхетовский?

Раз на раз не приходится.

>Если цитрикс помрет - то у ксена могут быть проблемы, не?

ещё не все поняли что Xen реально не нужен?

>Нет ни одной причины продолжать использовать 32-бита при объеме памяти от 3 Гб и выше.

часто совсем не надо адресовать 4 Гб на процесс и больше. а проблемы от использования 64-ти битной системы были и могут быть сейчас. даже то что они теоретически могут появиться - уже плохо.

пока не прекратят вообще создание 32 битных дистрибутивов для x86 переходить на 64 бит абсолютно везде - рано. я лично за прекращение поддержки 32 бит.

>До 4 гигабайт оперативки делать вообще ничего не нужно, далее - поможет включение «волшебного» PAE - http://ru.wikipedia.org/wiki/PAE

сколько то памяти всё равно зависнет в пустоте. от биоса зависит. это может быть и 1 Гб. так что при 4-х включать PAE всё равно.

Считаю не опраданным применение 64-битных систем до тех пор, пока на компьютере нет, как минимум, 8 гигабайт оперативки

да необязательно. например в дебиане кернелы с OpenVZ и PAE - вот применение PAE. кажется там же и для Xen.

короче если жёстко не прекратить создавать 32 битные дистры - переход на 64 бита так и не состоится.

тем более память дорожает, особенно учитывая что DDR2 постепенно уйдёт и конкуренции будет меньше. особенно если учесть что Nvidia не делает чипсеты для для AMD с поддержкой DDR3. значит общая цена платформ с DDR3 так и останется высокой (чипсеты только от Intel и AMD). вот до нового года купил хорошую системную плату для AM2+ , сейчас посмотрел - такой уже нет. аналог её для Intel стоит .....нно , аналога для AM3 нет и остальное стоит дороже примерно на тысяцу и выше. это к тому что апгрейд систем и так то имеет мало смысла, а железо достаточно надёжное и цены на новые системы не радуют. так и будет сплошное 32-бит. у меня вообще ощущение что виндузятники активнее переходят на 64 бита.

Я, кстати, перешёл на 64 бита ещё 4.5 года назад, тогда у меня в домашнем десктопе был всего 1Gb Ram. За всё время возникла всего одна проблема - Flash, но она решалась с помощью установки nspluginwrapper. Сейчас этой проблемы нет вообще. В общем, я не вижу ни одной причины, чтобы оставаться на 32-бит системе.

да пытался я 4 года назад перейти. но java, opera, плагины FF и тд и тп задрали. мне проще везде поставить кернел с PAE. как наверное и большинству. неощутимый прирост производительности в некоторых программах всего этого не оправдывал. плюс был тогда шанс что что-то не скомпилируется как надо или будет работать не там - был и есть.

а вот поднятие частот памяти, просто её физическое увеличение до 4-8 ми напрмиер (тем более что линукс отлично кэширует данные использую оставшуюся память. просто сказка), многоядерные процессоры, аппаратное декодирование видео - это видно сразу.

За всё время возникла всего одна проблема - Flash, но она решалась с помощью установки nspluginwrapper. Сейчас этой проблемы нет вообще. В общем, я не вижу ни одной причины, чтобы оставаться на 32-бит системе.

+1

Про проблемы с оперой и плагинами для Firefox слышу впервые. А про тд и тп можно по-подробнее?

И где же там существенная разница в производительности? Или ты имел в виду разницу между PAE32 и 64?

Именно. И я даже написал об этом в сообщении. Читай внимательно. Ещё я написал, что у системы без PAE с 3.2Gb RAM производительность такая же, как у системы с PAE и с 4Gb RAM.

>Про проблемы с оперой и плагинами для Firefox слышу впервые. А про тд и тп можно по-подробнее?

я не помню уже. было давно

>Во-первых, даже с PAE нельзя адресовать более 4 Гб на процесс,

А больше, в настоящее время, и не нужно в большинстве случаев. Или бедные программы с утечками памяти упираются в предел адресации?

Во-вторых (сюрприз-сюрприз), доступно из них пользователю будет 2 или 3 Гб только,

Это ты не с виндой перепутал?

в-третьих, даже с PAE адреса ввода-вывода перекроют доступ к большей части последнего из 4 Гб, что приведет к их потере.

Мне кажется, или у тебя в голове каша? Каким образом виртуальные адреса связаны с физическими? Тот диапазон адресов, что используется для ввода-вывода, будет потерян в любом случае, 64 бита никаким волшебным образом не спасут этот диапазон адресов.

Нет ни одной причины продолжать использовать 32-бита при объеме памяти от 3 Гб и выше. Что уже совсем не редкость.

При объёме оперативки 3 гигабайта и более нет ни одной причины резко вдруг перелезать на 64 бита. То есть нет причины ни на то ни на другое решение. Пока оперативки не более 4 гигабайт, напрягаться вообще мало смысла, если вдруг её стало немного больше 4 гигабайт - можно просто включить PAE. И уже только потом можно будет задумываться о том, чтобы перейти на 64 бита.

Тот диапазон адресов, что используется для ввода-вывода, будет потерян в любом случае, 64 бита никаким волшебным образом не спасут этот диапазон адресов.

$ free
             total       used       free     shared    buffers     cached
Mem:       4057100    3475276     581824          0     768548    1266260
-/+ buffers/cache:    1440468    2616632
Swap:      4194296     113136    4081160

$ uname -a
Linux workstation 2.6.32-tuxonice-r5 #1 SMP PREEMPT Sun Feb 14 20:43:12 MSK 2010 x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux

>При объёме оперативки 3 гигабайта и более нет ни одной причины резко вдруг перелезать на 64 бита. То есть нет причины ни на то ни на другое решение. Пока оперативки не более 4 гигабайт, напрягаться вообще мало смысла, если вдруг её стало немного больше 4 гигабайт - можно просто включить PAE. И уже только потом можно будет задумываться о том, чтобы перейти на 64 бита.

Я приводил ссылку на тест, потрудись по ней сходить.

$ free
             total       used       free     shared    buffers     cached
Mem:       1036032    1018100      17932          0       6316     720300
-/+ buffers/cache:     291484     744548
Swap:       987956        848     987108

$ uname -a
Linux debian 2.6.26-2-686 #1 SMP Wed Feb 10 08:59:21 UTC 2010 i686 GNU/Linux

И что это доказывает?

Или мне нужно бежать за планками памяти, чтобы её было 4 гигабайта?

>Я приводил ссылку на тест, потрудись по ней сходить.

Тесты на Phoronix авторитетными источниками не признаю.

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

Единственные золотые горы, повышенная производительность Apache и повышенная производительность диска, никак не объяснены - возможно дело тут далеко не в 64 битах.

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

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

>На amd64, кроме увеличения разрядности, есть ещё как минимум одно важное преимущество - в два раза больше регистров общего назначения, а это полезно для всех программ.

А для апача и диска особенно полезно?

Ладно, всё, вы меня уже убедили. Но аргумент «использовать больше оперативки без костылей» я всё равно считаю мало осмысленным.

А для апача и диска особенно полезно?

Это полезно для _любого_ кода. Не важно чем он занимается - обрабатывает сетевые подключения или передаёт данные контроллеру диска.

Регистров не хватает почти всегда, так что компилятор добавляет инструкции сохранения переменных из регистров в стек (или другие области памяти) и вытаскивания их обратно. А это даёт пару лишних инструкций во многих местах в коде.

>Это полезно для _любого_ кода.

Я этот вопрос задал не потому что я этого не понимаю, а потому что у тестировщиков на Phoronix апач и дисковая подсистема на 64 битах ускорились на два порядка и порядок соответственно. Почему? Потому что они не умеют тестировать или потому что действительно так 64-битность повлияла?