64 битный линух

1 - практически ни на сколько.
2 - да, но не все собирается (например большинчтво GL), нет, заработают нинасколько.
3 - для десктопа - сейчас говорят, что никогда, для сервера - скоро.

LT очень рекомендуется почитать Розенталя.

тогда какое преимущество даёт 64 линух???

IA64 kod ne pojdet pod atlonom. x86_64 - da.

Адресация очень большой памяти. Это надо не всем, тебе, скорее всего, нет.

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

1)раза в два
2)не под ia64 а под amd64
>т. е. можно просто собрать прогу в линузе

да можно просто пересобрать, но некоторые программы пишут
криворукие программисты, и они будут некоректно работать.

>3. Когда Микрософт выпустит ХП 64 бит эдишн, все проги должны быть >куплены заново (под новую архитектуру)?

а самому башкой подумать слабо?

64-битный nbench показал лучшие результаты, чем 32
athlon64 2800+: slack 10.0 2.6.10 vs ubuntu 4.10 2.6.8

>1)раза в два

У меня это чудо под столом. Никакого "раза 2" там нет. 10% при хорошей погоде.

>У меня это чудо под столом. Никакого "раза 2" там нет. 10% при хорошей погоде.

и что вы сравнивали на "машине под столом" собранный специально под эту архитектуру дистрибутив и собранный под 32 ?

и какие дистрибутивы?
какие тесты?
какие цифры?

а если вы не проводили тесты, то не мелите попусту языком

Блин да, что вы паритесь! Реального увеличения быстродействия не будет, если приложение специально не спроектировано, чтобы использовать всё преимущество этой самой 64-битности.
Для демонстрации напишем простую программку
-----------
$ cat test.c
#include <stdlib.h>
main()
{
int i;
int c,d,e,a,b;
for (i=0; i<10000000; i++)
{
a=random();
b=random();
c=a&b;
d=a+b;
e=a*b;
}
}
$ gcc test.c
$ time ./a.out

real 0m1.336s
user 0m1.026s
sys 0m0.001s
$ time ./a.out

real 0m1.312s
user 0m1.016s
sys 0m0.015s
$ time ./a.out

real 0m1.313s
user 0m1.034s
sys 0m0.001s
-----------

Теперь заменим в программе
int c,d,e,a,b;
на
char c,d,e,a,b;
-----------
$ gcc test.c
$ time ./a.out

real 0m1.520s
user 0m1.178s
sys 0m0.001s
$ time ./a.out

real 0m1.497s
user 0m1.161s
sys 0m0.014s
$ time ./a.out

real 0m1.530s
user 0m1.165s
sys 0m0.003s
-----------
Т.е. вроде бы арифметика происходит уже не с 4-байтными (у меня 32-битный процессор, поэтому sizeof(int)=4), а 1-байтными, а время расчёта только увеличилось.
Почему увеличилось? Скорее всего из-за перевода int->char.
Почему не уменьшилось? Потому что 32-хбитному процессору абсолютно по барабану что считать 8-битные,, что 16-битные, что 32-хбитные числа.
Точно так же и 64-битному процессору по барабану что считать 64-битные, что 32-битные, что 16 или даже 8-битные числа.
Поэтому если, например, мы хотим реализовать какой-нибудь битовый массив (например для реализации множества), который будет побитово складываться/умножаться (AND, OR, XOR) с другими такими же массивами, то будет лучше для быстродействия объявить этот массив как int[], а не char[].
Если приложения не были написаны с учётом этого, то ускорения не будет ни какого, а таких приложений я думаю большинство, и не только потому, что люди не знают этой особенности, но и потому что во многих алгоритмах физически не возможно применить это - ну не часто нужна арифметика с 32-битными, а тем более 64-битными числами и так красиво "сложить" несколько 8-битных чисел в одно 32-битное или 64-битное слово как при побитовых операциях AND, OR, XOR можно не часто..

Программку с форматированием ещё раз напишу:
-----------
$ cat test.c
#include <stdlib.h>
main()
{
    int i;
    int c,d,e,a,b;
    for (i=0; i<10000000; i++)
    {
        a=random();
        b=random();
        c=a&b;
        d=a+b;
        e=a*b;
    }
-----------

А вот ещё программка, но она считает каждый раз не 10 млн. чисел, а 80 млн. бит.
Что является как раз демонстрацией приложения которое будет работать в два раза 
быстрее на 64-битном процессоре
-----------
$ cat test.c
#include <stdlib.h>
#include <stdio.h>
main()
{
    int i;
    int c,d,e,a,b;
    fprintf (stdout,"sizeof(a)=%d\n",sizeof(a));
    for (i=0; i<10000000/sizeof(c); i++)
    {
        a=random();
        b=random();
        c=a&b;
        d=a|b;
        e=a>>5;
    }
}
-----------
Уменьшение скорости в 4 раза (и даже более) при замене
int c,d,e,a,b;
на
char c,d,e,a,b;
предлагается проверить самостоятельно

> 10000000/sizeof(c)
Замечу всё же что на самом деле так в реальной программе писать нельзя - на 1024-хбитном :-) процессоре она уже будет не 80 млн.бит считать а меньше

Так то оно так. В обычных приложениях в принципе плевать на производительность. Интересует вот что: можно ли (теоретически) получить производительность в два раза выше? Ведь в приложениях, требующих ресурсов процессора (например, мультимедиа) происходит работа как раз с длинными словами, и чем больше разрядность, тем лучше. Снижение времени визуализации кадра в два раза, при прочих равных условиях, было бы очень полезно;)

> Интересует вот что: можно ли (теоретически) получить производительность в два раза выше?
Я уже сказал - только если приложение специально спроектировано для этого

> Ведь в приложениях, требующих ресурсов процессора (например, мультимедиа) происходит работа как раз с длинными словами
Насколько длинными? 64 бита? Если 32 - то не будет быстрее.. А если 64, то будет, да ещё и может быть более, чем в два раза.

>Я уже сказал - только если приложение специально спроектировано для этого Такие приложения существуют сейчас?

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

Если просто сделать все инты 64-битными то производительность УПАДЕТ. Потому что возрастет нагрузка на память. afaiu поэтому инты обычно на 64-битных компиляторах делаются 32-битными. А тот выигрыш которого может достичь хороший компилятор на 64-битной архитектуре, можно достичь и с помощью SSE. ИМХО.

> Если просто сделать все инты 64-битными то производительность УПАДЕТ.
Ну нельзя же так однозначно говорить. Я уже сказал "смотря какое приложение"!