1. Возможность строить программы занимающие больше чем 4 гига памяти.
2. Более быстрая арифметика. (хотя в данном случае я бы сказал гипотетически. Арифметика задействующая более 32 бит но менее 64 достаточно редка ).
Здравствуйте, GlebZ, Вы писали:
GZ> Арифметика задействующая более 32 бит но менее 64 достаточно редка ).
Да, действительно. Обычно 32 хватает, а для тех задач для которых не хватает, для них и 64 тоже мало.
Вот памяти расходоваться больше будет — это точно (указатели и все целые числа будут 64 разрядными). Я думаю, что повсеместный переход на 64-разрядную платформу произойдет не раньше чем память подешевеет на столько, что в самые дешевые компьютеры в минимальной конфигурации ее будут вставлять по 4 гигабайта. Сейчас вставляют по 256 мегабайтов, значит память сперва должна подешеветь как минимум в 16 раз.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, GlebZ, Вы писали:
GZ>> Арифметика задействующая более 32 бит но менее 64 достаточно редка ).
СГ>Да, действительно. Обычно 32 хватает, а для тех задач для которых не хватает, для них и 64 тоже мало.
СГ>Вот памяти расходоваться больше будет — это точно (указатели и все целые числа будут 64 разрядными).
+1 СГ>Я думаю, что повсеместный переход на 64-разрядную платформу произойдет не раньше чем память подешевеет на столько, что в самые дешевые компьютеры в минимальной конфигурации ее будут вставлять по 4 гигабайта. Сейчас вставляют по 256 мегабайтов, значит память сперва должна подешеветь как минимум в 16 раз.
Для серверов проблема уже актуальна.
В действительности я немного ошибся. Быстродействие должно несколько убыстрится за счет копирования памяти. А это достаточно частая операция, особенно для OS.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, GlebZ, Вы писали:
GZ>> Арифметика задействующая более 32 бит но менее 64 достаточно редка ).
СГ>Да, действительно. Обычно 32 хватает, а для тех задач для которых не хватает, для них и 64 тоже мало.
Вот тут я с вами попробую не согласиться. Тот-же 3DNOW! умеет складывать "вертикально" тоесть в регистр грузится
два 16бит числа и складываются. Это нужно для выполнения большего кол-ва операций за такт. А теперь можно грузить
два 32бит числа и соотвественно ускорение будет не только для 64бит математики, а и для обычной 32-х битной.
Здравствуйте, ussr, Вы писали:
U>Здравствуйте, GlebZ, Вы писали:
GZ>>1. Возможность строить программы занимающие больше чем 4 гига памяти.
U>а разве сейчас нельзя
Нельзя, ограничения на юзер память 3 гига(насколько я помню) для ветки NT и 2 гига для 95 ветки. Начиная с 2000 возможны пляски с AWE. Но это уже другая история.
Здравствуйте, Kluge, Вы писали:
K>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Здравствуйте, GlebZ, Вы писали:
GZ>>> Арифметика задействующая более 32 бит но менее 64 достаточно редка ).
СГ>>Да, действительно. Обычно 32 хватает, а для тех задач для которых не хватает, для них и 64 тоже мало. K>Вот тут я с вами попробую не согласиться. Тот-же 3DNOW! умеет складывать "вертикально" тоесть в регистр грузится K>два 16бит числа и складываются. Это нужно для выполнения большего кол-ва операций за такт. А теперь можно грузить K>два 32бит числа и соотвественно ускорение будет не только для 64бит математики, а и для обычной 32-х битной.
Есть такая шняга. Но сложение чисел из 2 разных адресов памяти для обычных приложений на несколько порядков более частая операция.
Здравствуйте, GlebZ, Вы писали:
GZ>Есть такая шняга. Но сложение чисел из 2 разных адресов памяти для обычных приложений на несколько порядков более частая операция.
А разьве такое сложение проходит совсем мимо регистров?
Здравствуйте, Kluge, Вы писали:
K>Здравствуйте, GlebZ, Вы писали:
GZ>>Есть такая шняга. Но сложение чисел из 2 разных адресов памяти для обычных приложений на несколько порядков более частая операция. K>А разьве такое сложение проходит совсем мимо регистров? Нет конечно, но если ты мне объяснишь смысл загонять два числа в один регистр (полученные из двух адресов или одно из чисел уже находится в каком-то из регистров), то может и соглашусь?
Здравствуйте, GlebZ, Вы писали:
K>>А разьве такое сложение проходит совсем мимо регистров? GZ> Нет конечно, но если ты мне объяснишь смысл загонять два числа в один регистр (полученные из двух адресов или одно из чисел уже находится в каком-то из регистров), то может и соглашусь?
Смысл в том, что для сложения 100 пар 32бит чисел мы потратим в два раза меньше тактов. Если загружать одно число в регистр то за такт можно сложиьт N(число регистров)/2 пар чисел, а при 64битных регистрах можно сложить N пар чисел.
И наверное общее количество используемых регистров в пересчете на 32 битные регистры увеличится, а значит и логика распределения по регистам будет другая ????
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Kluge, Вы писали:
S> И наверное общее количество используемых регистров в пересчете на 32 битные регистры увеличится, а значит и логика распределения по регистам будет другая ????
вы забыли как ax расширили до eax? старшая часть отдельно не адресуется, так что 'увеличить кол-во регистров' не получится
Здравствуйте, ussr, Вы писали:
U>вы забыли как ax расширили до eax? старшая часть отдельно не адресуется, так что 'увеличить кол-во регистров' не получится
Регистры это просто способ организации самой быстрой памяти. Изменилось кол-во регистров или нет не так уж важно, ведь мы можем оперировать с частями регистров.
U>вы забыли как ax расширили до eax? старшая часть отдельно не адресуется, так что 'увеличить кол-во регистров' не получится
Kluge утверждает другое Re[3]: Что дает 64-битность Windows?
Здравствуйте, Kluge, Вы писали:
K>Здравствуйте, GlebZ, Вы писали:
K>>>А разьве такое сложение проходит совсем мимо регистров? GZ>> Нет конечно, но если ты мне объяснишь смысл загонять два числа в один регистр (полученные из двух адресов или одно из чисел уже находится в каком-то из регистров), то может и соглашусь? K>Смысл в том, что для сложения 100 пар 32бит чисел мы потратим в два раза меньше тактов. Если загружать одно число в регистр то за такт можно сложиьт N(число регистров)/2 пар чисел, а при 64битных регистрах можно сложить N пар чисел.
А теперь давай посмотрим когда мы можем получить эти 100 пар. Только в мультимедиа в котором алгоритм адаптирован именно к этой команде. Мы обязаны хранить эти 100 пар именно в таком виде. А для того, чтобы сделать их такими, сколько тебе потребуется тактов?
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, ussr, Вы писали:
U>>вы забыли как ax расширили до eax? старшая часть отдельно не адресуется, так что 'увеличить кол-во регистров' не получится S> Kluge утверждает другое S> Re[3]: Что дает 64-битность Windows?
GZ>А теперь давай посмотрим когда мы можем получить эти 100 пар. Только в мультимедиа в котором алгоритм адаптирован именно к этой команде. Мы обязаны хранить эти 100 пар именно в таком виде. А для того, чтобы сделать их такими, сколько тебе потребуется тактов?
А если по другому рассуждать. Большая проблема для компиляторов распределить локальные переменные по регистрам. Если правильно то, что утверждает Kluge, то можно переменные распределять в большем количестве. Да и компиляторы под них уже года 2 совершенствуются.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Нет конечно, но если ты мне объяснишь смысл загонять два числа в один регистр (полученные из двух адресов или одно из чисел уже находится в каком-то из регистров), то может и соглашусь?
