LINUX.ORG.RU

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


0

0

слышал про сабж. интересуют некоторые подробности. Интересны детали: 1. На сколько быстрее рабоает сама ос, если стоит АМД 64 3000 против 32 битной на этом же процессоре. 2. Как я слышал, программа должна быть откомпилирована в IA64, т. е. можно просто собрать прогу в линузе? Будет ли в сабже повышение производительности старых 32 битных программ, устанавливаемых через бинарники? или они вообще не заработают? и насколько может быть выше быстродействие (например, в программах визуализации или архивации) по сравнению с 32 битным линухом. 3. Когда Микрософт выпустит ХП 64 бит эдишн, все проги должны быть куплены заново (под новую архитектуру)?


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

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

Shaman007 ★★★★★
()

IA64 kod ne pojdet pod atlonom. x86_64 - da.

anonymous
()
Ответ на: комментарий от Shaman007

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

LT
() автор топика

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

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

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

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

anonymous
()
Ответ на: комментарий от LT

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

kao ★★
()
Ответ на: комментарий от Shaman007

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

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

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

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

anonymous
()

Блин да, что вы паритесь! Реального увеличения быстродействия не будет, если приложение специально не спроектировано, чтобы использовать всё преимущество этой самой 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 можно не часто..

unDEFER ★★★★★
()
Ответ на: комментарий от unDEFER

Программку с форматированием ещё раз напишу:
-----------
$ 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;
    }
-----------

unDEFER ★★★★★
()
Ответ на: комментарий от unDEFER

А вот ещё программка, но она считает каждый раз не 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;
предлагается проверить самостоятельно

unDEFER ★★★★★
()
Ответ на: комментарий от unDEFER

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

unDEFER ★★★★★
()
Ответ на: комментарий от unDEFER

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

LT
() автор топика
Ответ на: комментарий от LT

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

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

unDEFER ★★★★★
()
Ответ на: комментарий от unDEFER

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

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

LT
() автор топика

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

dilmah ★★★★★
()
Ответ на: комментарий от dilmah

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

unDEFER ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.