i386-библиотек для Debian не нашёл.

А Jack погляжу... благо, в Phonon поддерживается.

А можно инструкцию по установке Jack?

Вот у меня, например Maverick x64. И всё отлично идёт. Ведь 64-битная система поддерживает и 32-битные приложения. К примеру драйвер на WiFi у меня 32 бита. Так что 64-битная более универсальна, так как поддерживает 64 и 32 бита, а 32-битная только 32. Она ни чем не лучше, просто универсальнее.

>Сразу после загрузки 32 ~100М / 64 ~300М, что намекает

Сразу после загрузки 65Мб. На нетбуке - 40Мб. Вы точно не в диспетчере задач это смотрели?

Сразу после загрузки:
- на ubuntu x32 - 200M
- на arch x64 - 70M

Что как-бы намекаэ.

Еще один вариант есть с 64 разрядными системами. Вот буквально только что дособирал себе. Суть создаем chroot с чисто 32разядным окруженим, монтируем туда dev, proc и прочие tmp.

Особый плюс — после того как 32битная программа перестала быть нужна можно просто прибить папочку c окружением. ну или иметь несколько окружений.

А еще меньше проблем с дровами, они все 64 разрядные как и иксы. Если развить идею,то можно устроить хитрый гибрид из 64 разрядных иксов (во избежания проблем с дроавми и плюс производительности) и 32 битным частичным юзерспейсом.

Вобщем имею рабочий цхрут с 32битной гентой в 64битной. задавайте ваши вопросы.

> Суть создаем chroot с чисто 32разядным окруженим, монтируем туда dev, proc и прочие tmp.

Тоже так сделал. Ещё /home тоже туда прибиндил. Основную систему сделал no-multilib. На деле вышло, что чрутом и не пользуюсь :) Но на всякий случай держу.

>Так что 64-битная более универсальна, так как поддерживает 64 и 32 бита, а 32-битная только 32

Вообще-то это фича ядра, можешь в любом 32-битном дистре поставить 64-битный самосбор, и будет тебе счастье:)

Стоило бы больше написать про source-based дистрибутивы ведь там всё несколько меняется в плане производительности. На моей nocona, например, преимущества от long mode сводятся на нет увеличениями размера кеша (если собирать с -march=native). На intel core ix всё кардинально склоняется в другую сторону

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

а как работает опенсолярка/опениндиана кстати? у неё только ядро 64 разрядное и всё?

Зависимость от скорости доступа к ОЗУ...

Немного специфичный вопрос по производительности...

Какая будет разница в работе с памятью на 32 и 64 битных архитектурах?

Где то читал, что на 32 битах вроде как быстрее доступ, чем на 64, т.к. размер регистра меньше. Соответственно будет выйгрыш в программах которые часто обращаются к памяти. Интересно какие это могут быть программы.

P.S. Пытался гуглить на эту тему, но ничего не обнаружил, думаю что возможно этот вопрос неактуален ввиду того что собственный кэш процессора полностью компенсирует этот недостаток, т.е. большинство приложений не используют частый доступ к памяти большего размера чем кэш процессоров?

>Где то читал, что на 32 битах вроде как быстрее доступ, чем на 64, т.к. размер регистра меньше.

Прекращай нести бред, услышанный от однокласников.

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

«Не обнаружил» потому, что этот бред - это чисто ваш школьный фолклёр

+_+ |~LOL~| +_+

Где то читал, что на 32 битах вроде как быстрее доступ, чем на 64, т.к. размер регистра меньше.

Прекращай нести бред, услышанный от однокласников.

Твой бред прекратит только модератор. Или бригада медиков. Или обои :D

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

«Не обнаружил» потому, что этот бред - это чисто ваш школьный фолклёр

Как раз таки в этой теме про мой вопрос есть конкретная ссылка на вики где в общих чертах описана как раз именна эта проблема. Так что получается что «чисто ваш школьный фолклёр» - http://www.linux.org.ru/wiki/en/32_или_64_бита - это текст автора темы с количеством постов под сотню и полугодом обсуждения. Я в этом сильно сомневаюсь... Если тут есть технически грамотные люди в этом вопросе, то думаю эту статейку на вики можно дополнить.

Учи уроки и завязывай с веществами, мальчик:)

Ставлю тебе кол!

Переделать Д/з, а то оставлю на второй год. Гыыы

>Гыыы

А где же традиционный «Пыщъ»?

Тебе хватит и «Гыыы»

P.S. Ты меня явно с кем то перепутал.

>Где то читал, что на 32 битах вроде как быстрее доступ, чем на 64, т.к. размер регистра меньше. Соответственно будет выйгрыш в программах которые часто обращаются к памяти. Интересно какие это могут быть программы.

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

зато регистров больше. То есть, обращаться к памяти нужно реже.

Число записей в TLB-страницах в 64-х битном режиме как бы тоже меньше, т.е. вероятность получить провал в производительности при доступе к произвольной области памяти ровно в 2 раза выше - одно компенсируется другим вроде как, но опять повторюсь: уровней TLB в 64-х битном режиме больше, т.е. произвольный доступ к памяти по определению медленнее, и число доступных регистров тут уже совершенно побоку

А для настольного/игрового компа в инете есть ещё какие нибудь плюсы минусы от 32/64 Ос ?

Потому что у меня Ос Windows и на вики как бы получается не то написано для меня Прирост производительности колеблется от 0.6% до 45% (Сравнение производительности 32-битной и 64-битной версий дистрибутивов Fedora 9, OpenSUSE 11.0, Ubuntu 8.04.1). Возникает благодаря: увеличенному количеству процессорных регистров amd64 по сравнению с IA-32 (уменьшается так называемый «register pressure», компилятор порождает меньше операций spill/fill); использованию SSE2 взамен инструкций fp-сопроцессора x87 (The resulting code should be considerably faster in the majority of cases and avoid the numerical instability problems of 387 code ... This is the default choice for the x86-64 compiler.); улучшенному ABI (выравнивание fp-переменных, «red zone»).

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

4+Gb + больше регистров + больше разрядность как правило и дают те самые %% где на это рассчитывают (операции с большими числами/мультимедиа), в целом переход на любом более-менее современном железе на 64-битную ОС оправдан

:D

Вообще последние новшества в сфере IT напоминают мне эволюцию динозавров - тупиковый путь просто увеличивать объёмы и для этого мощности. Щас есть условия для нормальной работы любых приложений (для обычных пользователей) без увеличения оперативки или физической памяти на hdd. Однако складывается такое ощущение что всем охота поскорее забить как можно больше памяти и смотреть как это всё подтормаживает.

Да и вообще мировая информационная наука в тупике. С времён изобретения транзистора ничего принципиально нового нет. Только размеры элементов уменьшаются.

Нарыл тест, где перевес в производительности 64 над 32 колоссальный. Даже как то слабо верится. http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1

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

сервер - 64, без вопросов

десктоп - 32, дабы не заморачиваться с подбором или компиляцией дистров

>использованию SSE2 взамен инструкций fp-сопроцессора x87
хто на 32 мешает этому? о_О

>хто на 32 мешает этому? о_О
Здравый смысл. Использование mfpmath=sse на x86 не бесплатно и может привести к падению производительности если у тебя не числодробилка (хотя с числодробилкой всё это часто пофиг, поскольку там идут другие оптимизации).
А ещё mfpmath=sse требует изменения ABI для нормальной работы. На x86-64 проблем с этим, естественно, нет.
Да-да, я знаю, что у тебя всё работает.

скорее вопрос совместимости с древними процессорами без sse2, у 64 битных у всех есть sse2, поэтому и используется

32 битные есть с sse (не совсем еще разложившиеся amd),
с недо-sse (без регистров) GeodeLX, и вообще без sse

для нормальной математики нужен sse2, хотя лучше sse3

-mstackrealign теперь включен по умолчанию с gcc 4.5, да и раньше оно к проблемам производительности особенно не приводило, с стабильноcтью - да, бывало.

с avx можно будет использовать только половинки от половины YMM регистров, так что x86 понемножку закапывают

>может привести к падению производительности
пример давай - а то как ни крутил, только профит
да - корка если чо

Лучше скажи, почему в -march=native -O2 (а это почти все safe cflags) оно не включается.

а меня то чо спрашиваешь?

потому что никто этого не предложил разработчикам GCC, вероятно

>эволюцию динозавров - тупиковый путь

Динозавры^W x86-64 - не тупиковая ветвь, просто прилетел метеорит^W Itanium и убил их всех

Linux Debian x64

Тред читал не полностью. Раньше был Debian 32. Но как только установил FreeBSD x64 - сборка ядра показала 1,5 раза прирост скорости.
Незадумываясь, поставил Debian amd64 - При запуске и работе с обычным офисом[OpenOffice] - уже визуально заметил более быструю работу.
После этого - только 64-битные версии дистрибутивов устанавливал.

Ты сравниваешь сборку ядра дебиан и ядра фри?

Ну и ботва же. Плацебо такое плацебо.

Там по-русски написано :)

Без пояснений - ботва Ваше сообщение :)

А пояснения тут и не нужны.

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

Формулировка

Ну, если не сформулировали правильно - то действительно Ваш пост был лишний :)
Я объясняю знающим и понимающим людям - остальным в ясли :)

Знающие и понимающие люди ржут над твоим «от 64 битов всё летает».

Пояснение

Ну не поняли, что тут поделаешь! - такие вещи глупо ЛОРовцам объяснять :)

Комп

Железо у всех разное - правильно, программы используемые тоже разные - не всегда, но тоже правильно.
Я не говорил, что летает.
Поработаете год с одним(32) и год с другим(64) - будете понимать о чём я говорю. Потом над собой посмеётесь :)

Поработал, поэтому и смеюсь. Над тобой.