Arch64

Это конечно радует. Только вот я, например, не вижу смысла использовать 64-разрядные дистрибутивы: флеш не запустишь, цедегу тоже. Не говоря уже про специфичные проприетарные приложения, разработчики которых не торопятся перекомпилировать их под x86_64.

> не вижу смысла использовать 64-разрядные дистрибутивы

так и запишем: прогресс не нужен =)

А что?
Запустить 32 приложение под 64 линуксом нельзя?

Под виндами64 можно запустить 32битную прогу.

Флеш работает в 32битной опере под x86_64

>Это конечно радует. Только вот я, например, не вижу смысла использовать 64-разрядные дистрибутивы: флеш не запустишь, цедегу тоже. Не говоря уже про специфичные проприетарные приложения, разработчики которых не торопятся перекомпилировать их под x86_64.

Вы не правы. Использую x64 (в основном SuSE) версии дистрибутивов уже два года. Никаких неудобств не замечал. Все приложения х32 (включая флэш) нармально работают, а на сегодняшний день подавляющее большинство софта уже собрано под х86_64. Под Arch 64 есть даже OpenOfiice собранный, как мне кажется под 64 бита ftp://xentac.net/amd64/extra/openoffice-base-2.0.2-1.pkg.tar.gz Сам дистрибутив поставил пару дней назад - впечатления очень положительные! А ОО не качал, т.к не пользуюсь им (LaTeXa вполне хватает), а трафик жалко на всякое г..но тратить.

а как там с набором софта и коммунити (мэйллисты в частности)? хочу тоже попробовать арч64 :)

>а как там с набором софта и коммунити (мэйллисты в частности)? хочу тоже попробовать арч64 :)

Не дебиан конечно, но в принципе есть все необходимое:ftp://xentac.net/amd64 Рассылки работают, несколько IRC каналов есть, люди активность проявляют - проект живет полноценно, и видимо набирает обороты. Что особенно радует - это вычищенные от всякое ерунды пакеты, собранные с человеческими зависимостями и занимающие на порядок меньше места, чем аналогичные в других дистрибутивах, и совершенно свежий, но стабильный софт.

Комунити там хорошее) Мейллисты есть)

Набор софта поменьше чем в 32, но нет никаких проблем со сборкой из PKGBUILD'ов для 32 бит.

И цедега работает?

> > не вижу смысла использовать 64-разрядные дистрибутивы

> так и запишем: прогресс не нужен =)

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

Фактически меняется шило на мыло. Нет бы регистров хоть пару сотен сделали.

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

Эх. Где мой старенький 8086...

>И цедега работает?

Откровенно говоря - не знаю, никогда не пробовал. Совершенно не испытываю необходимости в подобного рода софте.

Поздравляю арчеров с развитием их дистрибутива =) Блин, попробовать что-ли..

Мигрировать чтоли на лаптопе со слаки на сабж... SLAMD64 мне не понравился по многим причинам. Так что юзаю оригинальный 32-битный slackware. Был ли у кого опыт миграции со слаки на arch? Какие есть особенности?

Могу поделиться опытом миграции с сусе и с альта :)

>Прогресс в выкачивании денег с пользователей за совсем им не нужные вещи (в большинстве ситуаций 64 бита нафиг не нужны) конечно нужен. Вот только совсем не пользователям, а производителям процессоров, памяти, винтов и "супер-современных операционных систем".

Ты дебил чтоли? Какое выкачивание? Если сейчас 90% процентов выпускаемых процессоров имеют эти самые 64бита, так что при очередном апргрейде железа получишь их бесплатно.

ни цедега, ни вино не компилиццо под debian - amd64 :(

> в большинстве ситуаций 64 бита нафиг не нужны

Эта фраза свидетельствует о категорическом незнании предмета. В списке отличий x86-64 от x86 ширина регистров общего назначения стоит на последнем месте.

>Мигрировать чтоли на лаптопе со слаки на сабж... SLAMD64 мне не понравился по многим причинам. Так что юзаю оригинальный 32-битный slackware. Был ли у кого опыт миграции со слаки на arch? Какие есть особенности?

Переходил именно со слаки. Вкратце -- небо и земля ;) Проще самому попробовать (а попробовать однозначно стоит). Только вот насчет Arch64 не знаю, может пока остановиться на оригинальном Arch?

>Поздравляю арчеров с развитием их дистрибутива =) Блин, попробовать что-ли..

Попробуй чтоли. Глядишь -- снесешь свою генту, как я когда-то :)

а чего лучше с линуксцентра заказать :
http://www.linuxcenter.ru/?good=1389
http://www.linuxcenter.ru/?good=1148
http://www.linuxcenter.ru/?good=1332
чтобы последнее и минимум трафика
на последующую доводку до ума ?

>Только вот насчет Arch64 не знаю, может пока остановиться на оригинальном Arch?

А чем плох 64? Софт написанный для х32 вы на нем запустите, и будет он работать не хуже, а вот попробуйте на х32 запустить софт х64 :-)

Ну а зачем ее сносить?У меня например они прекрасно дополняют друг друга.Под архом работа под жентой ковыряние и досуг.

>флеш не запустишь, цедегу тоже.

Под Gentoo/amd64 и то и другое работает без нареканий. Flash 7, под цедегой гонял LineageII-C3. При чём все из портежа, ручками ничего не мучал.

Единственное на сегодня замечание - в 32-х битной Опере не работают Qt-шные стили.

>Единственное на сегодня замечание - в 32-х битной Опере не работают Qt-шные стили.

В смысле Qt-шные стили?

> а чего лучше с линуксцентра заказать

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

Срезы 0.7.1 и Spring 2006 собирал я, последний -- совсем недавно: срез пакетов сделан 11 апреля. За подробностями прошу сюды: http://linuxforum.ru/index.php?showtopic=19355

> А чем плох 64? Софт написанный для х32 вы на нем запустите, и будет он работать не хуже, а вот попробуйте на х32 запустить софт х64 :-)

Ну арх я знаю достаточно хорошо, а вот его 64-разрядную версию пока в глаза не видел. Про 32х битный софт буду знать, хотя странно: одни говорят, что запускается, другие -- что нет, третьи -- что только из chroot с 32х-разрядной системой :).

>Прогресс в выкачивании денег с пользователей за совсем им не нужные вещи (в большинстве ситуаций 64 бита нафиг не нужны) конечно нужен. Вот только совсем не пользователям, а производителям процессоров, памяти, винтов и "супер-современных операционных систем".

>Фактически меняется шило на мыло. Нет бы регистров хоть пару сотен сделали.

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

>Эх. Где мой старенький 8086...

Какие нафиг новые регистры? Если выкинуть весь этот доисторический мусор со времен 8086, то процессор раза в 2 так точно будет быстрее работать. Давно уже пора начать ломать обратную совместимость и понемногу выносить всесь этот хлам на помойку.

узко мыслишь.

линукс, всё-таки, в основном на серверах используется. а там и постгрес и мускуль и какой-нить апач очень хороши в x86_64

>>Единственное на сегодня замечание - в 32-х битной Опере не работают Qt-шные стили.

>В смысле Qt-шные стили?

В смысле, что те, которые используют программы с Qt-интерфейсом :D Под x86 Опера и сама корректно автодетектит текущий KDE-стиль, даже если работаешь в Gnome, и указывать самостоятельно можно. Но amd64 - только дефолтовые серые менюшки...

> Был ли у кого опыт миграции со слаки на arch? Опыт исключительно положительный :) После перехода на Arch Все проблемы с установкой и обновлением софта исчезли. Основные преимущества перед слакой - _нормальный_ менеджер пакетов и система портов. Я бы сказал, что Arch - это удобная слака ;)

> узко мыслишь. линукс, всё-таки, в основном на серверах используется. а там и постгрес и мускуль и какой-нить апач очень хороши в x86_64

Ортогонально, где он в основном используется. У меня он используется исключительно в роли десктопа + платформы для девелопинга. С этой колокольни я и смотрю.

>В смысле, что те, которые используют программы с Qt-интерфейсом :D Под x86 Опера и сама корректно автодетектит текущий KDE-стиль, даже если работаешь в Gnome, и указывать самостоятельно можно. Но amd64 - только дефолтовые серые менюшки...

Может это просто static-сборка? :)

> >Прогресс в выкачивании денег с пользователей за совсем им не нужные вещи (в большинстве ситуаций 64 бита нафиг не нужны) конечно нужен. Вот только совсем не пользователям, а производителям процессоров, памяти, винтов и "супер-современных операционных систем".

> Если сейчас 90% процентов выпускаемых процессоров имеют эти самые 64бита, так что при очередном апргрейде железа получишь их бесплатно.

Про память, винты и гемор с несовместимостью мысль ниасилил? Кто после этого больший дебил?

AK

> > в большинстве ситуаций 64 бита нафиг не нужны

> Эта фраза свидетельствует о категорическом незнании предмета.

Да, есть немного.

> В списке отличий x86-64 от x86 ширина регистров общего назначения стоит на последнем месте.

Хорошо. Не будем говорить про красоту архитектуры. На каких реальных задачах для рабочих станций x86_64 даёт заметный выигрыш? Перевешивает ли это те ситуации, когда x86_32 быстрее (за счёт более короткого кода, помещающегося в кеш, например)?

Не хочу сказать, что x86_64 отстой по определению, но поводов для радости от перехода на эту архитектуру не вижу. Если их кто-то перечислит, буду благодарен за информацию.

AK

Какой код и в какой кеш не помещается в амд_64 и за счет чего он в 32-х 
битном варианте будет короче? Или если раньще mov dx,al занимал к 
примеру 32 бита (??), то на 64 битной платформе - 64 бита??

cat t.c
#include <stdio.h>

int
main(void)
{
        int i;

        for (i = 0; i < 10; i++)
                printf("%d\n", i);
}


gcc -m32 -o t32 t.c
gcc -o t t.c

ls -lh t*
10K 2006-04-16 13:22 t*
95 2006-04-16 13:22 t.c
11K 2006-04-16 13:22 t32*

Конечно пример элементарный, но не могу понять, почему должно быть как
то по-другому ?

AMD Athlon 64 3000+

По всем заверениям, 32 битные программы работают не медленне, чем на
аналогичном 32 битном проце

cat t.c
int
main(void)
{
        int i;

        for (i = 0; i < 1000000000; i++);
}

gcc -m32 -o t32 t.c
gcc -o t t.c

time ./t

real    0m3.869s
user    0m3.856s
sys     0m0.002s


time ./t32

real    0m4.156s
user    0m4.140s
sys     0m0.006s


gcc -O3 -o t t.c
gcc -O3 -m32 -o t32 t.c

time ./t

real    0m1.050s
user    0m1.037s
sys     0m0.004s


time ./t32

real    0m1.051s
user    0m1.037s
sys     0m0.002s

> Какой код и в какой кеш не помещается в амд_64 и за счет чего он в 32-х битном варианте будет короче? Или если раньще mov dx,al занимал к примеру 32 бита (??), то на 64 битной платформе - 64 бита??

Вроде того. Обязательно в программе найдётся такой цикл, что в 32b варианте уместиться в строку кеша, а в 64b нет.

С printf пример не показателен.

---------------------------------------

> main(void) > { > int i; > > for (i = 0; i < 1000000000; i++); > }

gcc, думаю, научился оптимизировать пустые циклы.

А что если так:

int a[1000000];

main(void) { int i, j; long s;

for (j = 0; j < 1000000; j++) a[j]=j;

for (i = 0; i < 10240; i++) for (j = 0; j < 1000000; j++) s+=a[j]; printf("%ld\n",s);

}

Писал наспех. Но вроде "должно сработать".

AK

скажите а в 64-битной сборке, памяти правда отъедает в два раза больше?

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

сравнение openssl из 64-битной и 32-битной сборок FC3:

~> ./usr/bin/openssl speed rsa
Doing 512 bit private rsa's for 10s: 11110 512 bit private RSA's in 10.00s
Doing 512 bit public rsa's for 10s: 128886 512 bit public RSA's in 9.97s
Doing 1024 bit private rsa's for 10s: 2175 1024 bit private RSA's in 9.99s
Doing 1024 bit public rsa's for 10s: 44331 1024 bit public RSA's in 10.01s
Doing 2048 bit private rsa's for 10s: 363 2048 bit private RSA's in 9.99s
Doing 2048 bit public rsa's for 10s: 13332 2048 bit public RSA's in 9.96s
Doing 4096 bit private rsa's for 10s: 56 4096 bit private RSA's in 10.06s
Doing 4096 bit public rsa's for 10s: 3787 4096 bit public RSA's in 10.00s
OpenSSL 0.9.7a Feb 19 2003
built on: Tue Oct 11 17:36:11 EDT 2005
options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx)
compiler: gcc -fPIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DOPENSSL_NO_IDEA -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_EC -I/usr/kerberos/include -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -m32 -march=i686 -mtune=pentium4 -Wa,--noexecstack -DSHA1_ASM -DMD5_ASM -DRMD160_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
                  sign    verify    sign/s verify/s
rsa  512 bits 0.000900s 0.000077s   1111.0  12927.4
rsa 1024 bits 0.004593s 0.000226s    217.7   4428.7
rsa 2048 bits 0.027521s 0.000747s     36.3   1338.6
rsa 4096 bits 0.179643s 0.002641s      5.6    378.7
~> /usr/bin/openssl speed rsa
Doing 512 bit private rsa's for 10s: 25752 512 bit private RSA's in 9.96s
Doing 512 bit public rsa's for 10s: 320364 512 bit public RSA's in 9.99s
Doing 1024 bit private rsa's for 10s: 6081 1024 bit private RSA's in 9.94s
Doing 1024 bit public rsa's for 10s: 112048 1024 bit public RSA's in 9.87s
Doing 2048 bit private rsa's for 10s: 1000 2048 bit private RSA's in 9.77s
Doing 2048 bit public rsa's for 10s: 37724 2048 bit public RSA's in 10.00s
Doing 4096 bit private rsa's for 10s: 162 4096 bit private RSA's in 10.02s
Doing 4096 bit public rsa's for 10s: 10007 4096 bit public RSA's in 10.00s
OpenSSL 0.9.7a Feb 19 2003
built on: Tue Oct 11 17:43:23 EDT 2005
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
compiler: gcc -fPIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DOPENSSL_NO_IDEA -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_EC -I/usr/kerberos/include -DL_ENDIAN -DTERMIO -Wall -DMD32_REG_T=int -O2 -g -pipe -m64 -Wa,--noexecstack
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
                  sign    verify    sign/s verify/s
rsa  512 bits 0.000387s 0.000031s   2585.5  32068.5
rsa 1024 bits 0.001635s 0.000088s    611.8  11352.4
rsa 2048 bits 0.009770s 0.000265s    102.4   3772.4
rsa 4096 bits 0.061852s 0.000999s     16.2   1000.7

не угадал

еще 256 прерываний на устройства вместо 16...

Почитал я описание Arch -- возникает вопрос, а чем он лучше/хуже того же debian? Система пакетов примерно похожая по функциональности, детали в настройках тоже незначительно отличаются. Что, там лучше политика добавления новых версий в дистр?

> Все приложения х32 (включая флэш) нармально работают ...

[nik@nvid install_flash_player_7_linux]$ ll
total 2180
-r-xr-xr-x 1 nik nik   23614 Dec  9 03:44 flashplayer-installer
-r--r--r-- 1 nik nik     856 Dec  9 03:44 flashplayer.xpt
-rwxr-xr-x 1 nik nik 2154768 Dec  9 03:44 libflashplayer.so
-rw-rw-r-- 1 nik nik   12265 Dec  9 03:45 Readme.htm
-rw-rw-r-- 1 nik nik    5684 Dec  9 03:45 Readme.txt
[nik@nvid install_flash_player_7_linux]$ ./flashplayer-installer

ERROR: Your architecture, \'x86_64\', is not supported by the
       Macromedia Flash Player installer.

> скажите а в 64-битной сборке, памяти правда отъедает в два раза больше?

Нет, неправда.

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

Конкретно у x86-64 ещё плюсы: вдвое большее количество регистров, передача параметров функциям через регистры (до 8 параметров, вроде бы) и наличие расширений SSE и SSE2 по определению.

А 48-битное адресное пространство бывает нужно не только тогда, когда в системнике живёт > 4 GB памяти.

> ERROR: Your architecture, \'x86_64\', is not supported by the > Macromedia Flash Player installer.

И что? Интсаллятор не работает, а сам плагин успешно работает. Сам пробовал. Но, естественно, только с 32-битным браузером.

>Может это просто static-сборка? :)

Нет, именно shared :) static он и на x86 так себя ведёт.

Вообще, пытаясь "раскрасить" Оперу под amd64 чего только не перепробовал... Потом забил :)

Политика и система сборки из исходников есть.

+ AUR. Ничего аналогичного я в других дистрах пока не видел...

rc скрипты удобнее дебиана.

Сетевые профили поддерживаются сразу. не надо самому для этого скрипты писать.

>Не хочу сказать, что x86_64 отстой по определению, но поводов для радости от перехода на эту архитектуру не вижу. Если их кто-то перечислит, буду благодарен за информацию.

Адресация памяти. 3+1Гб даже для десктопа уже вот-вот будет мало.

>скажите а в 64-битной сборке, памяти правда отъедает в два раза больше?

В два, не в два, но памяти жрётся намного больше. Что есть, то есть...

А самое большое преимущество (имхо) - легкость установки левых программ средствами пакетного менеджера.

Т.е. нет тенденции к разведению помойки в /opt, /usr/local/...