i386 vs amd64, debian

Мегабаксу и в лицо!

Уже года 4ре на x86_64 системах. Сейчас такой стабильнодебиан. Вот буквально с него пишу, рабочая машинка. И скайп работает и вайн и всё остальное. Еще ни разу не наткнулся на проблемы связанные с архитектурой. И знаешь что? Переход тебе не поможет, друг мой, нет. Это у дебиана проблемы с тобой, а не у тебя с ним. Отговорить? Ты что, критичный сервис, что нам волноваться за твои движения на домашнем локалхосте? Мира тебе и процветания.

Два гигабитных зеркала этому господину

Не забывай, что мы про онтопик.

Сижу на 64-битном дебиане. Скайп не нужен, вайн без проблем крутит все, что мне нужно. Единственное, что беспокоит - субъективно огнелис жрет больше, чем на x86.
В остальном разницы не замечаю.

Хорошая идея, правда он наверное проигнорирует.

Так и я ж о нём родимом

Так и я ж о нём родимом

В таком случае ты круто заблуждаешься.

i386_bigmem (pae) ничем вроде бы не хуже x86_64

Таки хуже. Хоть система и видит >4 Гб ОЗУ, однако для программы может быть выделено максимум 4 Гб (для виртуалок - критично).

К тому же на x86_64 есть дополнительные меры защиты программ.

2ТС: www.linux.org.ru/wiki/en/32_или_64_бита

Неаругментированный бред.

хороши аргументы. Других не будет?

Смотрим например статистику Steam - две трети пользователей Linux на x86_64

ну и что? тебя послушать, так линукс вообще говно, которое нужно только 0.1% маргиналов (или сколько там в steam?)

подавляющее большинство пользователей Восьмёрки тоже на x86_64? А 95% — Идиоты. Что это доказывает?

Абсолютно ничего, кроме кривых рук, не мешает пользоваться x86-софтом на x86_64-дистре. Даже в Убунте это работает из коробки года полтора как.

ага. Только надо костылей доставить дох и больше. А так — ничего. И будет PAE на x64. Клёво.

Есть ли софт который работает на 86-64 и НЕ работает на x86

В центоси kvm не работает.

Смотрим например статистику Steam - две трети пользователей Linux на x86_64

ну и что? тебя послушать, так линукс вообще говно, которое нужно только 0.1% маргиналов (или сколько там в steam?)

Я специально русским языком указал на то, что распределение x86 и x86_64 по статистике из Steam подтверждается статистикой скачивания первого же попавшегося под руку дистрибутива, а вы в наглую выборочно процитировали только про Steam и Восьмёрку. То есть вывод: реальные аргументы вас не интересуют, вас интересует доказать собственную правоту любыми методами, даже если вы отлично понимаете, что неправы (доказано вашим выборочным цитированием).

подавляющее большинство пользователей Восьмёрки тоже на x86_64?

А 95% — Идиоты. Что это доказывает?

Ну так что, не три человека? Сами уже забыли, о чём спорите, да?

хороши аргументы. Других не будет?

Начерта спрашивать, если я вам привожу аргументы, а вы их игнорируете, и более того, в ответ уже сами себе противоречите?

Только в Слаке надо костылей доставить дох и больше. А так — ничего.

Пофиксил. Остальные тут причём?

реальные аргументы вас не интересуют, вас интересует доказать собственную правоту любыми методами, даже если вы отлично понимаете, что неправы (доказано вашим выборочным цитированием).

Если вы ещё не поняли мою мысль, то поясняю: Статистика НЕ является аргументом. Если-бы хотя-бы половина респондентов делали выбор _осознано_, или хотя-бы как я, тупо проверив и то и другое, то это было-бы фактом. Ну а так - проверили, ткнули, поставили. Многие на своём горьком опыте убедились, что OS в 32 бита не видят больше трёх гигов. Качать и ставить дистр, в котором _может_ быть такая проблема - никто ессно не хочет, проще скачать сразу дистрибутив, в котором нет очередных «640К, которых хватит всем».

Начерта спрашивать, если я вам привожу аргументы, а вы их игнорируете, и более того, в ответ уже сами себе противоречите?

ваша статистика аргументом не является. Потому спорить с ней сложно. Она никак НЕ доказывает, что 64х битная ос лучше, чем 32х битная, доказывает лишь то, что 95% качает именно её. Вы лишь передёргивая факты, доказывая своей статистикой то, что 64х битная якобы лучше, и потому именно её и скачивают. Ну а я вообще сомневаюсь, что все из ваших 95%, хотя-бы смогут объяснить, чем эти ОС отличаются.

Только в Слаке надо костылей доставить дох и больше. А так — ничего.

Пофиксил. Остальные тут причём?

это в каком дистрибутиве ia32libs поставлено по дефолту?

Ну так что, не три человека? Сами уже забыли, о чём спорите, да?

ага, забыл. Если вы не поняли, то 3.5 человека юзают 64х битный Linux не просто так, а потому, что он им _действительно_ нужен. И поменять его на 32х битный они его не могут по тем, или иным причинам. Остальные 100500 юзают потому, что в принципе разница не столь значительная, к костылям и глюкам линуксоидам не привыкать(особенно во всяких скайпах и вайнах). Одним больше, одним меньше.

Она никак НЕ доказывает, что 64х битная ос лучше, чем 32х битная

Здесь уже обсудили.

это в каком дистрибутиве ia32libs поставлено по дефолту?

Какая разница, когда они ставятся, если процесс происходит совершенно прозрачно для пользователя, а нужная программа в итоге просто работает?

Остальные 100500 юзают потому, что в принципе разница не столь значительная, к костылям и глюкам линуксоидам не привыкать(особенно во всяких скайпах и вайнах).

Снова неаругментированный бред.

Если-бы хотя-бы половина респондентов делали выбор _осознано_

Вот, пожалуйста, про осознанность выбора:

Go back and play with HIGHMEM.SYS on a 286, and stop blathering crap. When you’ve spent the last ten years of your life working with HIGHMEM.SYS, then you can come back and tell me that we still don’t need 64 bits.

Здесь уже обсудили.

для Ъ я позволю себе процитировать «обсуждение»:

funny funny

Какая разница, когда они ставятся, если процесс происходит совершенно прозрачно для пользователя, а нужная программа в итоге просто работает?

ага. погуглил немного, накачал Over9000 пакетов (зачем-то к ним ALSA ставится. Не знаете почему? Да и какие-то X11 фонты для сервера тоже не думаю, что так уж нужны), потанцевал с бубном - вроде как-то заработало. Если повезёт.

Остальные 100500 юзают потому, что в принципе разница не столь значительная, к костылям и глюкам линуксоидам не привыкать(особенно во всяких скайпах и вайнах).

Снова неаругментированный бред.

вы это пишете, когда ответить нечего?

Вот, пожалуйста, про осознанность выбора: Go back and play with HIGHMEM.SYS on a 286, and stop blathering crap. When you’ve spent the last ten years of your life working with HIGHMEM.SYS, then you can come back and tell me that we still don’t need 64 bits.

вообще-то это разные вещи. 16и бит адреса было мало для _всех_, приложений, а 32х бит для всех приложений _достаточно_. Потому свои воспоминания Линус может засунуть себе ...

Давайте, обоснование в студию, а то я что-то не наблюдаю процессов, которым 4Гб памяти мало.

для Ъ я позволю себе процитировать «обсуждение»

Очуметь, вы даже ссылку на мейл-лист не заметили? Понятно теперь, как вы читали - глазами пробежались и забыли.

ага. погуглил немного, накачал Over9000 пакетов (зачем-то к ним ALSA ставится. Не знаете почему? Да и какие-то X11 фонты для сервера тоже не думаю, что так уж нужны), потанцевал с бубном - вроде как-то заработало. Если повезёт.

Вы о чём сейчас вообще?

вы это пишете, когда ответить нечего?

Нет, я это пишу, когда вижу неаргументированный бред.

вообще-то это разные вещи. 16и бит адреса было мало для _всех_, приложений, а 32х бит для всех приложений _достаточно_

Ещё раз:

You literally do need more virtual memory than physical.

Repeat after me: virtual space needs to be bigger than physical space. Not “as big”. Not “smaller”. It needs to be bigger, by a factor of at least two, and that’s quite frankly pushing it, and you’re much better off having a factor of ten or more.

«Reasons for why you need a bigger virtual space» прочитаете сами. Мне сюда всё копипастить, или может соизволите не игнорировать написанное по ссылке?

Очуметь, вы даже ссылку на мейл-лист не заметили? Понятно теперь, как вы читали - глазами пробежались и забыли.

там много букв не по теме.

Вы о чём сейчас вообще?

об установке 32х битных либ.

Нет, я это пишу, когда вижу неаргументированный бред.

но почему «бред», и почему «неаргументированный», никто кроме вас не знает.

Ещё раз:

You literally do need more virtual memory than physical.

Repeat after me: virtual space needs to be bigger

Repeat

да хоть обповторяйтесь! Если 10 раз сказать фигню, она не станет истинной. Аргументируйте, _почему_, с какого перепугу виртуальная память _должна_ быть больше? Линус тогда спал с тёлками помоложе? И что, я — тоже. Сейчас наши тёлки постарше. Я смирился.

там много букв не по теме.

По теме.

об установке 32х битных либ.

Ещё раз: какая разница, когда они ставятся, если процесс происходит совершенно прозрачно для пользователя, а нужная программа в итоге просто работает?

но почему «бред», и почему «неаргументированный», никто кроме вас не знает.

Вы и дальше собираетесь писать нечто в духе «Остальные 100500 юзают потому, что в принципе разница не столь значительная, к костылям и глюкам линуксоидам не привыкать(особенно во всяких скайпах и вайнах)»? Я не вижу аргументов, их здесь нет. А бред есть.

You literally do need more virtual memory than physical.

Если 10 раз сказать фигню

фигню

Доказывайте.

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

Учимся читать:

• you need to map that physical memory somehow, and no, tiny windows into the physical memory simply do not cut it! If you cannot have normal pointers to the physical space, it immediately means that you need to jump through serious hoops to get there.
• you additionally need to be able to remap things in alternate ways (ie user space) or make space for non-memory issues (virtual page tables, IO, you name it)

Всё это уже было написано по ссылке. Не прочитали, потому что букв много?

I’m not at all surprised that Windows didn’t push PAE either. It was a total braindamage. I bet they supported it in the server offerings just because they had to

Чего?

System Support for PAE PAE is supported only on the following 32-bit versions of Windows running on x86-based systems:
Windows 7 (32 bit only)
Windows Server 2008 (32-bit only)
Windows Vista (32-bit only)
Windows Server 2003 (32-bit only)
Windows XP (32-bit only)

http://msdn.microsoft.com/en-us/library/aa366796.aspx

Внимание:

didn’t push PAE

push, это если бы на ноутбуки с более, чем 2 ГБ ОЗУ ставили сборки с PAE, а не x86_64, как сейчас.

сборки с PAE

Нет сборок с/без pae. Оно включается через bcdedit. Но я тебя понял, если так, то да, все сходится.

Нет сборок с/без pae. Оно включается через bcdedit.

Имеется ввиду что у вендоров есть образы для раскатки на продаваемое оборудование, они же лежат в recovery-разделах. Так сказать, сборки с готовыми наборами драйверов и софта.

skype 4

http://wiki.debian.org/skype

Вы и дальше собираетесь писать нечто в духе «Остальные 100500 юзают потому, что в принципе разница не столь значительная, к костылям и глюкам линуксоидам не привыкать(особенно во всяких скайпах и вайнах)»? Я не вижу аргументов, их здесь нет.

нет. В статистике нет аргументов, потому я не могу выдвинуть контраргументы.

А бред есть.

доказывайте.

Учимся читать: you need to map that physical memory somehow, and no, tiny windows into the physical memory simply do not cut it! If you cannot have normal pointers to the physical space, it immediately means that you need to jump through serious hoops to get there.

извините, можно своими словами? А то рассказки про «крошечные окошки в 1024Мб памяти» мне не очень понятны. Если для Линуса они «крошечные», то для меня ещё нет. К тому-же, в другом месте своего опуса он сам рассказывал, что тут дело не в «крошечности». Просто почему-то память должна быть больше вдвое, того, чего есть. А лучше в 10. Почему?

you additionally need to be able to remap things in alternate ways (ie user space) or make space for non-memory issues (virtual page tables, IO, you name it)

о да! Для io maps конечно 10 байт найти будет проблема! Вы там что с Линусом курили?

Всё это уже было написано по ссылке. Не прочитали, потому что букв много?

это я прочитал, но не понял. Разъясните. Уже какой пост прошу. Или вы сами не понимаете? Или знание настолько сакрально, что доступно только двум на Земле - вам и Линусу?

нет. В статистике нет аргументов, потому я не могу выдвинуть контраргументы.

Вы только что понимали, зачем были приведена статистика, и тут же опять забыли об этом? Да что же такое-то, а?

доказывайте.

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

Просто почему-то память должна быть больше вдвое, того, чего есть. А лучше в 10. Почему?

это я прочитал, но не понял. Разъясните. Уже какой пост прошу.

извините, можно своими словами?

Нельзя. Читайте.

о да! Для io maps конечно 10 байт найти будет проблема! Вы там что с Линусом курили?

Снова бред.

Вы только что понимали, зачем были приведена статистика,

я как раз НЕ понимал, причём тут статистика:

ага, забыл. Если вы не поняли, то 3.5 человека юзают 64х битный Linux не просто так, а потому, что он им _действительно_ нужен. И поменять его на 32х битный они его не могут по тем, или иным причинам. Остальные 100500 юзают потому, что в принципе разница не столь значительная, к костылям и глюкам линуксоидам не привыкать(особенно во всяких скайпах и вайнах). Одним больше, одним меньше.

Бремя подтверждения ваших тезисов лежит на вас

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

о да! Для io maps конечно 10 байт найти будет проблема! Вы там что с Линусом курили?

Снова бред

бред в цитате. Его и обосновывайте. Или вы только цитировать чужой бред умеете?

я как раз НЕ понимал, причём тут статистика

Уже ответил.

но почему «бред», и почему «неаргументированный», никто кроме вас не знает.

Вы и дальше собираетесь писать нечто в духе «Остальные 100500 юзают потому, что в принципе разница не столь значительная, к костылям и глюкам линуксоидам не привыкать(особенно во всяких скайпах и вайнах)»? Я не вижу аргументов, их здесь нет. А бред есть.

доказывайте.

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

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

Куда это вы там увиливаете от своего бреда?

Его и обосновывайте. Или вы только цитировать чужой бред умеете?

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

Это плохие варианты.

Это отличные варианты, покуда в ядре не работает RLIMIT_RSS.

Ссылку не читай @ в тред отвечай.

Куда это вы там увиливаете от своего бреда?

давайте сначала с вашим разберёмся, вы первый начали:

Repeat after me: virtual space needs to be bigger than physical space. Not “as big”. Not “smaller”. It needs to be bigger, by a factor of at least two, and that’s quite frankly pushing it, and you’re much better off having a factor of ten or more.

вот вам ссылка на ваш бред: i386 vs amd64, debian (комментарий)

Ещё раз, для прозорливых лиц, считающих, что они разбираются в управлении памятью ОС лучше Линуса Торвальдса

вы аргументируете, или опять сольёте с «бред»?

Вы осилите объяснение, или нет?

Вы осилите объяснение, или нет?

это всё слова и предположения. Факты в том, что на практике сплош и рядом используются _связанные_ структуры в памяти. Связаны они через указатели. В этих структурах как минимум один(односвязанный список), а часто два и более(двусвязаный список и деревья) указателя на один эл-т. Нравится вам или нет, но один указатель в x64 вдвое больше. А следовательно вдвое больше занимает, и вдвое медленнее обрабатывается. Это факты. Смысла в 64х битных указателей естественно никакого нет, если памяти(РЕАЛЬНОЙ!) менее 4Гб на процесс.

Если есть - аргументацию в студию. А не слова.

Впрочем - вы как всегда сольёте со словами «бред» и «не осилил».

ну и наконец, не стоит вам с Линусом забывать, что виртуальная память — тоже костыль. Это факты, а не фантазии. Когда-то давно (когда память была дорогая и её сильно не хватало) это костыль был необходим. Сейчас приложения могут работать прямо в физической памяти. У нас её уже не 32Мб. Многим приложениям её тупо ХВАТАЕТ. Разве это сложно понять? Если приложению нужен гиг - оно просто берёт, и выделяет _бескостыльный_ гиг. Он сейчас ЕСТЬ. Надо жить сейчас, а не вчера (во времена 32х метров), и не завтра (во времена 128и гб на большинстве систем).

Ну наконец-то, с третьей попытки...

Нравится вам или нет, но один указатель в x64 вдвое больше. А следовательно вдвое больше занимает, и вдвое медленнее обрабатывается.

Докажите, что это отнимает боле ресурсов, чем you keep some kind of indirect pointer, and every time before you use it, you have to map it into the virtual address space, access it, and then unmap it again. По мнению Линуса в результате So performance plummets, and the code actually gets really nasty too.

Смысла в 64х битных указателей естественно никакого нет, если памяти(РЕАЛЬНОЙ!) менее 4Гб на процесс.

Читаем (обращаю внимание - речь даже не про количество памяти на процесс, а об ОЗУ)

So, in practical terms, is there benefit from using 64-bit OS on a machine with, lets say, 2-3 GB RAM ?

Absolutely. No question what-so-ever.

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

в win7 prof тоже /lol
хотя там с x86_64 не такие большие проблемы

2оп: ставь i386, если не осилил мультиарч

Человеки. Не ссортесь. Всё нужное я уже почерпнул (я тс). Понял что есть люди которые очень-очень за x86-64, и ,примерно, столько же людей против этой архитектуры.

Вернулся на обычную x86, и всё встало на свои места. Ничего не глючит и работает как надо. Но, это не повод соскакивать с x86-64! (и этого страного multiarch). Пробуйте, и всё сами поймёте. Тазик отлично высказался в первом комментарии, спасибо тебе, я сделал всё что хотел.

Нравится вам или нет, но один указатель в x64 вдвое больше. А следовательно вдвое больше занимает, и вдвое медленнее обрабатывается.

Докажите, что это отнимает боле ресурсов, чем you keep some kind of indirect pointer, and every time before you use it, you have to map it into the virtual address space, access it, and then unmap it again.

проблема в том, что этот «косвенный указатель» никак НЕ отключается, и НЕ регулируется (во всяком случае в существующих ОС). Т.е. обращение к памяти через 64х битный указатель _ничем_ НЕ отличается от обращения через 32х битный. Никакого «сброса старших бит» не происходит. Вообще это всё тоже слова, и ВАМ их аргументировать - вы с Линусом думаете так, я - эдак, как там думают в Intel и AMD - доподлинно неизвестно, проверьте, я, если честно не знаю, но судя по всему, если разница и есть, то незначительная. Факт в том, что _виртуальная_ память остаётся _виртуальной_ и в режиме 64х бит. Надеюсь тут вы спорить не будете? Т.е. костыль виртуальная → физическая всё равно _работает_. С чего вы взяли, что это какой-то другой костыль, и что этот «новый» костыль значительно быстрее? Я к этому не вижу никаких предпосылок. Я вообще думаю, что там одна и та же схема преобразует TLB. Буду очень удивлён, если вы мне _докажите_ наличие какой-то особой 64х битной TLB, которая к тому же заметно быстрее.

Что касается скорости и размера - с этим глупо спорить. Любой идиот вам скажет, что 64 бита ровна вдвое больше 32х, и что 64х битное ALU может обработать два 32х битных слова одновременно (а в x86 именно такое и установлено, оно умеет не только одно 64х битное, но и два 32х битных одновременно)

По мнению Линуса в результате So performance plummets, and the code actually gets really nasty too.

что касается nasty code ему конечно виднее, но вот никаких предпосылок к performance plummets лично я не наблюдаю. Код для 64х битного CPU работает быстрее, но это исключительно из-за того (ИМХО), что его не оптимизируют под i80486. Например в 64х битном коде _вся_ арифметика работает на SSE2, ибо нет 64х битных CPU без SSE2. А вот 32х битный код тот же компилятор транслирует в более старые и более медленные регистровые операции. Однако, при чём тут 32 бита? Если у тебя есть SSE2, кто мешает тебе собирать под SSE2? Просто скажи компилятору: «хочу 32х битный код, но у меня НЕ i80486», и все дела. При интенсивной адресной арифметике будет значительно быстрее (ибо SSE2 умеет обрабатывать 4 указателя32 одновременно. Или 2 указателя в 64 бита. Причём код для 32х битного 486го CPU обрабатывает только _один_ указатель за раз, что и приводит к замедлению, если включить «32х битный режим»). Если ваш код не использует активно адресную арифметику, вы тоже почувствуете замедление для 32х бит, ибо 128и битное SSE2 использоваться тоже НЕ будет.

Не, я-то Линуса понимаю - ему надо 64х битность развивать, всех уже достало это нагромождение костылей из прошлого века (хорошо хоть i80386 отказались поддерживать, но 486 тоже не самый свежий - 1989й год).

Читаем (обращаю внимание - речь даже не про количество памяти на процесс, а об ОЗУ)

в том, что вы процитировали, НЕТ аргументации. Просто ничем не подкреплённые слова.

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

Во первых, никакого _обоснования_ я лично не вижу. Ни от вас, ни от Линуса.

Безусловно, 64х битная архитектура полезна и прогрессивна, безусловно, на неё НУЖНО переходить. Безусловно, 32х битные архитектуры не нужны, и подлежат закапыванию. Но совсем не потому, что они медленные. Нет, сейчас они в принципе быстрее и экономнее. Но это вопрос времени - система с 128ю Гб памяти(32х битная) будет убога и уродлива, как система с 128ю Мб на 16и битах. Тут Линус прав. Но пока, лично у меня, таких систем нет. Надеюсь, что скоро будут…

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

вы всё неправильно поняли, если считаете, что я «против», я-то как раз исключительно ЗА!!11, руками и ногами. Против - только неграмотные эникейщики, наколовшиеся на «трёхгигабайтные ноуты», в которые сколько памяти не ставь, больше 3х «не видят» (во многих IRL на самом деле 4Гб, а не 3). Обидно конечно, но с этой проблемой надо на винфак, а не суда.

С другой стороны, многие нормальные люди не понимают, на кой хрен лично ИМ эти ваши 64 битные _указатели_? Лишняя память, лишнее время, лишние проблемы. Не, вопрос решаем: можно юзать 64х битный порт(http://wiki.winehq.org/Wine64), можно 32х битную вручную(http://wiki.winehq.org/WineOn64bit) поставить. Но зачем его _решать_?

Нравится вам или нет, но один указатель в x64 вдвое больше. А следовательно вдвое больше занимает, и вдвое медленнее обрабатывается.

Докажите, что это отнимает боле ресурсов, чем you keep some kind of indirect pointer, and every time before you use it, you have to map it into the virtual address space, access it, and then unmap it again.

проблема в том, что этот «косвенный указатель» никак НЕ отключается, и НЕ регулируется (во всяком случае в существующих ОС). Т.е. обращение к памяти через 64х битный указатель _ничем_ НЕ отличается от обращения через 32х битный. Никакого «сброса старших бит» не происходит. Вообще это всё тоже слова, и ВАМ их аргументировать - вы с Линусом думаете так, я - эдак, как там думают в Intel и AMD - доподлинно неизвестно, проверьте, я, если честно не знаю, но судя по всему, если разница и есть, то незначительная. Факт в том, что _виртуальная_ память остаётся _виртуальной_ и в режиме 64х бит. Надеюсь тут вы спорить не будете? Т.е. костыль виртуальная → физическая всё равно _работает_. С чего вы взяли, что это какой-то другой костыль, и что этот «новый» костыль значительно быстрее? Я к этому не вижу никаких предпосылок. Я вообще думаю, что там одна и та же схема преобразует TLB. Буду очень удивлён, если вы мне _докажите_ наличие какой-то особой 64х битной TLB, которая к тому же заметно быстрее.

То есть вы уже доказываете не то, что 64-битные указатели вдвое дольше обрабатываются, а то что «обращение к памяти через 64х битный указатель _ничем_ НЕ отличается от обращения через 32х битный». Это прогресс! Но признать то, что Линус прав, вам не позволяет гордость, уже вон Intel с AMD приплетаете.

в том, что вы процитировали, НЕТ аргументации. Просто ничем не подкреплённые слова.

Топаете в мейл-лист и читаете аргументацию.

Что касается скорости и размера - с этим глупо спорить.

Однако, именно этим вы и занимаетесь:

но вот никаких предпосылок к performance plummets лично я не наблюдаю

А он наблюдает. Кто же из вас двоих с большей вероятностью прав...

Не, вопрос решаем: можно юзать 64х битный порт(http://wiki.winehq.org/Wine64), можно 32х битную вручную(http://wiki.winehq.org/WineOn64bit) поставить. Но зачем его _решать_?

Meanwhile in Ubuntu: оба этих вайна ставятся всего одной командой: apt-get install wine. Со всеми-всеми нужными для корректной работы зависимостями.

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

как с вами сложно-то? Давайте проще: у вас есть фура, которая возит 40т груза. Разве не очевидно, что 20и тонные грузы на такой фуре возить вдвое быстрее? Просто погрузите 2 груза по 20т каждый, и все дела. Смысл грузить один груз в 18 тонн в такую фуру? Сколько можно мне тут за К.О. говорить?

а то что «обращение к памяти через 64х битный указатель _ничем_ НЕ отличается от обращения через 32х битный». Это прогресс! Но признать то, что Линус прав, вам не позволяет гордость, уже вон Intel с AMD приплетаете.

а тут ни я, ни Линус не причём. Это как в примере фуры - её грузоподъёмность зависит исключительно от производителя и от модели. Если производитель рассчитывал на 40т, то и возить она должна 40т. Или 2×20т. У нас грузы почти всегда влазят в 20и тонные контейнеры, потому придётся нам возить по 2 контейнера сразу. Ибо возить один контейнер на 40т, который заполнен менее, чем на ½, просто глупо. Потому покупаем 2 контейнера по 20т, и работаем. Зачем нам один на 40т?

Топаете в мейл-лист и читаете аргументацию.

что же _вы_ не её цитируете, а только не аргументированные слова?

Что касается скорости и размера - с этим глупо спорить.

Однако, именно этим вы и занимаетесь:

вы меня пытаетесь неправильно понять. Хорошо, повторю ещё раз: два указателя в 32 бита обрабатывать вдвое быстрее, чем один, размером 64 бита. Это очевидный факт. Сейчас в этих 64х битных указателях более половины информации - неиспользуемый воздух. Какой в этом смысл - никому не понятно. Ну кроме Линуса, но с ним-то как раз понятно.

Meanwhile in Ubuntu: оба этих вайна ставятся всего одной командой: apt-get install wine. Со всеми-всеми нужными для корректной работы зависимостями.

кто врёт? вы, или вот этот сайт: http://wiki.winehq.org/WineOn64bit#head-77def7ca75193f24e358dba3dd6bcf674bd61b37 ?

как с вами сложно-то?

Ну конечно же сложно, ведь вам по десять раз объясняют одно и то же, что ваши упрощенные аналогии в духе 2+2 в данном случае не катят - потому что случай не тот. Но вы упорно к ним возвращаетесь, потому что подтвердить свою правоту иначе чем оторванными от реальной работы с памятью примерами, вы не можете.

что же _вы_ не её цитируете, а только не аргументированные слова?

Что же вы так боитесь туда сходить? Уже целую страницу. Приплетаете Intel, AMD, фуры, но в мейл-лист - ни ногой.

Хорошо, повторю ещё раз: два указателя в 32 бита обрабатывать вдвое быстрее, чем один, размером 64 бита. Это очевидный факт.

И ещё раз.

кто врёт? вы, или вот этот сайт

Врёт сайт - информация там устарела года на полтора-два.

Ну конечно же сложно, ведь вам по десять раз объясняют одно и то же, что ваши упрощенные аналогии в духе 2+2 в данном случае не катят - потому что случай не тот.

чем «не тот»? А по моему - очень даже тот. И вы мне ничего не объясняли, а лишь утверждали и ссылались на другие бездоказательные утверждения.

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

могу. Но вы ведь не осилите, и скажете «бред». А когда вам на пальцах объясняешь, вы мне говорите «пальцы не те».

И ещё раз.

попробуйте осмыслить ответ. Вы его хоть прочитать смогли? Может какие-то слова непонятны?

Врёт сайт - информация там устарела года на полтора-два.

вообще-то это не просто сайт, а сайт разрабов wine. И если оно «устарело», то значит ваша wine никому в x86_64 не нужна. О чём я и говорил.

А по моему

Во-во.

ссылались на другие бездоказательные утверждения

До сих пор боитесь сходить в мейл-лист?

попробуйте осмыслить ответ. Вы его хоть прочитать смогли? Может какие-то слова непонятны?

Как же до вас всё ещё не дойдёт, что вы выставляете ваши предположения против фактов? Причёми излагаемых человеком, который гарантированно разбирается в обсуждаемом вопросе уж точно получше нас с вами.

И если оно «устарело», то значит ваша wine никому в x86_64 не нужна.

Либо раскрывайте логическую цепочку, либо признайте уже наконец, что все ваши рассуждения построены на подобных соритах.

http://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae

2007-й год

ага. погуглил немного, накачал Over9000 пакетов (зачем-то к ним ALSA ставится. Не знаете почему? Да и какие-то X11 фонты для сервера тоже не думаю, что так уж нужны), потанцевал с бубном - вроде как-то заработало. Если повезёт.

Что ты несешь?! О_о

вы это пишете, когда ответить нечего?

ИМХО он это пишет потому, что ты на самом деле бред несешь.

Во-во.

и что в моей аналогии не так? не нравится?

До сих пор боитесь сходить в мейл-лист?

был я там. Тоже самое, что и здесь.

Как же до вас всё ещё не дойдёт, что вы выставляете ваши предположения против фактов?

понимаете, факт это то, что 32 байта занимают вдвое меньше места, и обрабатываются вдвое быстрее. Вот это - ФАКТ. Всё остальное - домыслы, или какие-то особые, специальные случаи. Чем наш случай «особый» - вы так и не сказали. В моём примере с фурами возможен-бы был вариант, когда вам нужно возить крупногабаритные грузы, которые тупо не влезают в 20и тонный контейнер, или у вас денег на 40ку не хватило, и корячитесь с двадцаткой, или…

Но у вас - только слова Линуса «я _хочу_ много виртуальной памяти, а кто против - тот дебил». Вот и все «аргументы».

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

я вам уже сколько раз намекаю на тот факт, что это мы с вами имеем роскошь высказывать _своё_ мнение, оперируя фактами и своим пониманием. Линус это публичный человек, и такой роскоши у него нет. За всё нужно платить - это как жена Президента, которая не может в любой момент взять, и убежать с полюбившимся ей клоуном. Спать с клоуном она может и может, но только так, что-бы об этом никто не знал. Так и Линус - нет у него своего мнения. Во всяком случае, оно не обязано совпадать с его публичными высказываниями.

И если оно «устарело», то значит ваша wine никому в x86_64 не нужна.

Либо раскрывайте логическую цепочку, либо признайте уже наконец, что все ваши рассуждения построены на подобных соритах.

проблемы со многими приложениями в 64х битных ОС есть, это факты, и вы с ними ничего не сделаете. Это данность. Не надо быть вангой, что-бы это предвидеть. При переходе на 32 бита тоже проблемы были. Будем на 128 бит переходить - тоже не всё гладко пойдёт. Ясное дело, что эти проблемы нужно решать, а для этого разработчики их должны РЕШАТЬ, а сл-но использовать 64х битные платформы. Это очевидно. Вот Линус и призывает _разработчиков_ юзать эти 64 бита.

Но. А при чём тут пользователь? Ему-то зачем 64 бита? Вы можете мне это внятно объяснить?

http://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae

2007-й год

зачем? Ты его ник прочитал?

ага. погуглил немного, накачал Over9000 пакетов (зачем-то к ним ALSA ставится. Не знаете почему? Да и какие-то X11 фонты для сервера тоже не думаю, что так уж нужны), потанцевал с бубном - вроде как-то заработало. Если повезёт.

Что ты несешь?! О_о

на, ознакомься: http://packages.debian.org/ru/squeeze/ia32-libs

asound видишь? Или к окулисту? А что-то там с фонтами вытянуто по косвенным зависимостям. Я понимаю, что админу локалхоста с установленной ALSA это не важно. Но не у всех один только локалхост.

А что кому-то важно что вытянулось пару ВОЗМОЖНО ненужных либ? Ну вытянулось и вытянулось. Можно подумать на 32-x ничего левого не тянется. Ты тут за пользователей пёкся, которому просто поставить и юзать. Ну так, я просто ставлю и юзаю, никаких бубнов, никаких «заработало если повезет».