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>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Kluge, Вы писали:
K>Здравствуйте, ussr, Вы писали:
U>>вы забыли как ax расширили до eax? старшая часть отдельно не адресуется, так что 'увеличить кол-во регистров' не получится K>Регистры это просто способ организации самой быстрой памяти. Изменилось кол-во регистров или нет не так уж важно, ведь мы можем оперировать с частями регистров.
ну и как оперировать старшей частью решистра?
ussr пишет:
> K>Здравствуйте, ussr, Вы писали: > U>>вы забыли как ax расширили до eax? старшая часть отдельно не > адресуется, так что 'увеличить кол-во регистров' не получится > K>Регистры это просто способ организации самой быстрой памяти. > Изменилось кол-во регистров или нет не так уж важно, ведь мы можем > оперировать с частями регистров. > ну и как оперировать старшей частью решистра?\
Здравствуйте, ussr, Вы писали:
U>ну и как оперировать старшей частью решистра? здесь
В принципе за пару недель можно вырыть всё самое необходимо благо там рядом есть документы по оптимизации относительно конкретных задач.
Здравствуйте, Kluge, Вы писали:
K>Здравствуйте, ussr, Вы писали:
U>>ну и как оперировать старшей частью решистра? K>здесь K>В принципе за пару недель можно вырыть всё самое необходимо благо там рядом есть документы по оптимизации относительно конкретных задач.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Здравствуйте, Kluge, Вы писали:
K>>Здравствуйте, ussr, Вы писали:
U>>>ну и как оперировать старшей частью решистра? K>>здесь K>>В принципе за пару недель можно вырыть всё самое необходимо благо там рядом есть документы по оптимизации относительно конкретных задач.
RRM>Рекомендую заглянуть сюда RRM>(надмножество приведенной ссылки)
RRM>Особенно обращаю внимание на AMD64 Architecture Programmers' Manuals (пять томов)
У интела не меньше.здесь
Здравствуйте, RailRoadMan, Вы писали:
RRM>Рекомендую заглянуть сюда RRM>(надмножество приведенной ссылки)
RRM>Особенно обращаю внимание на AMD64 Architecture Programmers' Manuals (пять томов)
[offtopic]
А хорошо блин написано! Начал читать сначала и забыл над чем сегодня работал. Хочу заниматься оптимизацией под новые процы, а не писать очередную ERP.
[/offtopic]
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>А теперь давай посмотрим когда мы можем получить эти 100 пар. Только в мультимедиа в котором алгоритм адаптирован именно к этой команде. Мы обязаны хранить эти 100 пар именно в таком виде. А для того, чтобы сделать их такими, сколько тебе потребуется тактов?
S> А если по другому рассуждать. Большая проблема для компиляторов распределить локальные переменные по регистрам. Если правильно то, что утверждает Kluge, то можно переменные распределять в большем количестве. Да и компиляторы под них уже года 2 совершенствуются.
Безусловно количество регистов это плюс. С другой стороны, не все операции можно сделать с тем, или иным регистром.
Что касается доступа к high слову, то еще при переходе на 32 разрадную систему была такая позиция. Регистр — это как правильно заметил Kluge — всего лишь наиболее быстрая область памяти. Формирование доступа к hi слову довольно сложная операция (кол-во транзюков никогда не хватает) а смысла в ней практически ноль. Возможно что доступ к AH был ошибкой, которая сильно усложнила процессор, но имела мало смысла.
В первую очередь 64-разрядность дает не много памяти (и 64 разрядные регистры — это все фигня). Она дает много адресного пространства. Что дает возможность принципиально более легкого программирования алгоритмов, требующих операций с очень большими объемами данных.
Например, можно спокойно отмапить в память многогигабайтную базу данных, вместо того чтобы ручками подгружать нужные куски. Пусть этим занимается ОС. Главное, что адресного пространста хватит на все.
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
X>В первую очередь 64-разрядность дает не много памяти (и 64 разрядные регистры — это все фигня). Она дает много адресного пространства.
Согласен, об этом уже писал. Но и регистры тоже не фигня (например для memcpy).
X>Что дает возможность принципиально более легкого программирования алгоритмов, требующих операций с очень большими объемами данных. X>Например, можно спокойно отмапить в память многогигабайтную базу данных, вместо того чтобы ручками подгружать нужные куски. Пусть этим занимается ОС. Главное, что адресного пространста хватит на все.
Вот так просто? Корпорации такие бабки тратят чтобы организовать эффективный доступ к этим многим гигабайтам. Маппинг такой информации — это последнее о чем бы я подумал.
Здравствуйте, xvost, Вы писали:
X>В первую очередь 64-разрядность дает не много памяти (и 64 разрядные регистры — это все фигня). Она дает много адресного пространства. Что дает возможность принципиально более легкого программирования алгоритмов, требующих операций с очень большими объемами данных.
X>Например, можно спокойно отмапить в память многогигабайтную базу данных, вместо того чтобы ручками подгружать нужные куски. Пусть этим занимается ОС. Главное, что адресного пространста хватит на все.
Если отвлечься от Windows, то 64-адресное пространство дает вообще новые подхода к построению систем
Существует подход называемый SASOS (single address space operating system)
In a Single Address Space OperatingSystem (SASOS) all processes run within a single global virtual address space; protection (if provided by the OS) is provided not through conventional address space boundaries, but through ProtectionDomain?s that dictate which pages of the global address space a process can reference. This operating system organization is facilitated by microprocessor architectures that support 64 bits of virtual address space and promotes efficient data sharing and cooperation, both between complex applications and between parts of the operating system itself.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Если отвлечься от Windows, то 64-адресное пространство дает вообще новые подхода к построению систем RRM>Существует подход называемый SASOS (single address space operating system)
RRM>Например
RRM>In a Single Address Space OperatingSystem (SASOS) all processes run within a single global virtual address space; protection (if provided by the OS) is provided not through conventional address space boundaries, but through ProtectionDomain?s that dictate which pages of the global address space a process can reference. This operating system organization is facilitated by microprocessor architectures that support 64 bits of virtual address space and promotes efficient data sharing and cooperation, both between complex applications and between parts of the operating system itself.
Только непонятно, какие плюсы мы получим в рамках x386? Система многих LDT поддерживается процом.
Здравствуйте, GlebZ, Вы писали:
RRM>>In a Single Address Space OperatingSystem (SASOS) all processes run within a single global virtual address space; protection (if provided by the OS) is provided not through conventional address space boundaries, but through ProtectionDomain?s that dictate which pages of the global address space a process can reference. This operating system organization is facilitated by microprocessor architectures that support 64 bits of virtual address space and promotes efficient data sharing and cooperation, both between complex applications and between parts of the operating system itself.
GZ>Только непонятно, какие плюсы мы получим в рамках x386? Система многих LDT поддерживается процом.
А это никакого отношения к х386 не имеет, если мы говорим про AMD64 то это другая архитектур.
С двумя оговорками:
— Проц может работать полностью в 32 разрядном режиме, вот тут полный х386, но никаких 64 разрядных адресов. этот случай нас не интересует
— В 64-разрядном режиме он может выполнять (не прибегая к эмуляции) старые 32 разрядные приложения, но только приложения, т.е. юзер моде. Весь системный код должен быть 64 бит, там нет никаких LDT. Например все драйвера должны быть собраны под этот процессор, старые драйвера не работают.
Здравствуйте, GlebZ, Вы писали:
X>>Что дает возможность принципиально более легкого программирования алгоритмов, требующих операций с очень большими объемами данных. X>>Например, можно спокойно отмапить в память многогигабайтную базу данных, вместо того чтобы ручками подгружать нужные куски. Пусть этим занимается ОС. Главное, что адресного пространста хватит на все. GZ>Вот так просто? Корпорации такие бабки тратят чтобы организовать эффективный доступ к этим многим гигабайтам. Маппинг такой информации — это последнее о чем бы я подумал.
Видимо, Вы не писали программ, которым памяти требуется очень много
Живой пример — софт для тестеров памяти, которым требуется работать с отображением всего тестируемого DIMM'а, размер которого уже переваливает за 32бита.
Здравствуйте, qxWork, Вы писали:
W>Здравствуйте, GlebZ, Вы писали:
X>>>Что дает возможность принципиально более легкого программирования алгоритмов, требующих операций с очень большими объемами данных. X>>>Например, можно спокойно отмапить в память многогигабайтную базу данных, вместо того чтобы ручками подгружать нужные куски. Пусть этим занимается ОС. Главное, что адресного пространста хватит на все. GZ>>Вот так просто? Корпорации такие бабки тратят чтобы организовать эффективный доступ к этим многим гигабайтам. Маппинг такой информации — это последнее о чем бы я подумал. W>Видимо, Вы не писали программ, которым памяти требуется очень много W>Живой пример — софт для тестеров памяти, которым требуется работать с отображением всего тестируемого DIMM'а, размер которого уже переваливает за 32бита.
Согласен, есть такие программы
С уважением, Gleb.
[offtop]
Самое смешное, писал 64 менеджер памяти для виндов для одного продукта. С хешами для доступа пришлось повозиться.
[offtop]
СГ>Я думаю, что повсеместный переход на 64-разрядную платформу произойдет не раньше чем память подешевеет на столько, что в самые дешевые компьютеры в минимальной конфигурации ее будут вставлять по 4 гигабайта.
Здравствуйте, GlebZ, Вы писали:
GZ>2. Более быстрая арифметика. (хотя в данном случае я бы сказал гипотетически. Арифметика задействующая более 32 бит но менее 64 достаточно редка ).
Почему гипотетически? Например, для СУБД — это просто рывок в скорости, так как они и так вынуждены оперировать данными большими нежели может позволить адресовать int32.
Правда, для этого СУБД нужно перепроектировать, чтобы та просто исполььзовала int64, а не занималась сигментированием (как это делают многие СУБД).
Да и для 32-х быитных алгоритмов выигрышь можно получить. Например, для сравнения двух 32-х битных чисел можно или воспользоваться простым вычитанием:
int Cmp(int x, int y)
{
return x - y;
}
но при этом ожно нарваться на переполнение. Чтобы этого избежать нужно писать:
int Cmp(int x, int y)
{
return x > y ? 1 : x == y ? 0 : 1;
}
что естественно мдленнее. Если же регистры 64-битные, то можно ничего не бояться.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, ussr, Вы писали:
U>>Здравствуйте, GlebZ, Вы писали:
GZ>>>1. Возможность строить программы занимающие больше чем 4 гига памяти.
U>>а разве сейчас нельзя GZ>Нельзя, ограничения на юзер память 3 гига(насколько я помню) для ветки NT и 2 гига для 95 ветки. Начиная с 2000 возможны пляски с AWE. Но это уже другая история.
GZ>С уважением, Gleb.
Здравствуйте, VladD2, Вы писали:
VD>Да и для 32-х быитных алгоритмов выигрышь можно получить. Например, для сравнения двух 32-х битных чисел можно или воспользоваться простым вычитанием: VD>
VD>int Cmp(int x, int y)
VD>{
VD> return x - y;
VD>}
VD>
VD>но при этом ожно нарваться на переполнение. VD> ...Если же регистры 64-битные, то можно ничего не бояться.
И что же, по-твоему, должна возвращать эта функция на 64-битных процессорах?
Здравствуйте, Воронков Василий, Вы писали:
U>>>а разве сейчас нельзя GZ>>Нельзя, ограничения на юзер память 3 гига(насколько я помню) для ветки NT и 2 гига для 95 ветки. Начиная с 2000 возможны пляски с AWE. Но это уже другая история.
GZ>>С уважением, Gleb.
ВВ>98 вообще больше 512 не переваривает
А 95, если не ошибась еще меньше. Там глюк был и память просто не использовалась, или вообще ОСь вылетала.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>И что же, по-твоему, должна возвращать эта функция на 64-битных процессорах? VD>Что и всегда int. Только он 64-бытный и переполнения идут лесом. А так как приложение работает в 32-битных понятиях, то и проблемы не возникнет.
btw далеко не факт что ваш компилятор реализует вычитание двух обычных signed int через 64-битную арифметику... например некоторые компитяоры реализуют char a, char b (a-b) через al, ah. И при том чего боятся переполнения в данном случае, если язык C++/C никак их не обрабатывает, а на результат они не повлияют, если сравнение это bool (). так что при чём тут переполнение я не понял.
Здравствуйте, nixite, Вы писали:
N>Здравствуйте, VladD2, Вы писали:
A>>>И что же, по-твоему, должна возвращать эта функция на 64-битных процессорах? VD>>Что и всегда int. Только он 64-бытный и переполнения идут лесом. А так как приложение работает в 32-битных понятиях, то и проблемы не возникнет.
N>btw далеко не факт что ваш компилятор реализует вычитание двух обычных signed int через 64-битную арифметику... например некоторые компитяоры реализуют char a, char b (a-b) через al, ah. И при том чего боятся переполнения в данном случае, если язык C++/C никак их не обрабатывает, а на результат они не повлияют, если сравнение это bool (). так что при чём тут переполнение я не понял.
Если C++ компилятор под 64bits, то int будет именно 64bits, но ведь и для других операций тоже этот же int будет использоваться. Т.е. если проблема есть в логике программы, то этим она просто загоняется глубже до лучших времен
Здравствуйте, RailRoadMan, Вы писали:
RRM>Здравствуйте, xvost, Вы писали:
X>>В первую очередь 64-разрядность дает не много памяти (и 64 разрядные регистры — это все фигня). Она дает много адресного пространства. Что дает возможность принципиально более легкого программирования алгоритмов, требующих операций с очень большими объемами данных.
X>>Например, можно спокойно отмапить в память многогигабайтную базу данных, вместо того чтобы ручками подгружать нужные куски. Пусть этим занимается ОС. Главное, что адресного пространста хватит на все.
RRM>Если отвлечься от Windows, то 64-адресное пространство дает вообще новые подхода к построению систем RRM>Существует подход называемый SASOS (single address space operating system)
RRM>Например
RRM>In a Single Address Space OperatingSystem (SASOS) all processes run within a single global virtual address space; protection (if provided by the OS) is provided not through conventional address space boundaries, but through ProtectionDomain?s that dictate which pages of the global address space a process can reference. This operating system organization is facilitated by microprocessor architectures that support 64 bits of virtual address space and promotes efficient data sharing and cooperation, both between complex applications and between parts of the operating system itself.
Интересно, а можно будет вообще заменить локальными обращениями к памяти дисковые (file mapping?) и сетевые операции? Что сейчас умеют менеджеры памяти в таких системах?
Хотя IMHO это не очень актуально для языков со скрытым управлением памятью, например Java или C#, а вот в C++ было бы очень удобно.
henson пишет:
> N>btw далеко не факт что ваш компилятор реализует вычитание двух > обычных signed int через 64-битную арифметику... например некоторые > компитяоры реализуют char a, char b (a-b) через al, ah. И при том чего > боятся переполнения в данном случае, если язык C++/C никак их не > обрабатывает, а на результат они не повлияют, если сравнение это bool > (). так что при чём тут переполнение я не понял. > Если C++ компилятор под 64bits, то int будет именно 64bits
Ошибаетесь. На большинстве 64-битных систем тип int остается 32-битным,
а вот указатели становятся 64-битными.
Здравствуйте, Cyberax, Вы писали:
C>henson пишет:
C>Ошибаетесь. На большинстве 64-битных систем тип int остается 32-битным, C>а вот указатели становятся 64-битными.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, Cyberax, Вы писали:
C>henson пишет:
>> N>btw далеко не факт что ваш компилятор реализует вычитание двух >> обычных signed int через 64-битную арифметику... например некоторые >> компитяоры реализуют char a, char b (a-b) через al, ah. И при том чего >> боятся переполнения в данном случае, если язык C++/C никак их не >> обрабатывает, а на результат они не повлияют, если сравнение это bool >> (). так что при чём тут переполнение я не понял. >> Если C++ компилятор под 64bits, то int будет именно 64bits
C>Ошибаетесь. На большинстве 64-битных систем тип int остается 32-битным, C>а вот указатели становятся 64-битными.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Хотя зря IMHO ради совместимости забили на стандарт
The 'int' data type is defined as "...the natural size of the architecture" (C++-98: 3.9.1.2).
Здравствуйте, Cyberax, Вы писали:
C>henson пишет:
>> N>btw далеко не факт что ваш компилятор реализует вычитание двух >> обычных signed int через 64-битную арифметику... например некоторые >> компитяоры реализуют char a, char b (a-b) через al, ah. И при том чего >> боятся переполнения в данном случае, если язык C++/C никак их не >> обрабатывает, а на результат они не повлияют, если сравнение это bool >> (). так что при чём тут переполнение я не понял. >> Если C++ компилятор под 64bits, то int будет именно 64bits
C>Ошибаетесь. На большинстве 64-битных систем тип int остается 32-битным, C>а вот указатели становятся 64-битными.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
-M ilp_model
This option defines the address model that IAS uses. Values for
ilp_model are:
ilp64 | lp64 | p64 – Default. Sets the address size to 64 bits.
Integer and long sizes have no effect.
ilp32 – Sets the address size to 32 bits, relevant for COFF32 file
Default for Windows NT: ilp64
Example: ias my_file.s -M ilp64
Что меня удивило, так это то, что Default для WinNT все-таки ILP64
Здравствуйте, Cyberax, Вы писали:
C>ussr пишет:
C>shl, shr, масочки там всякие...
я говорил не об этом. я говорил о том, что самый переход с 32 на 64 бита не даст прироста количества регистров, а лишь увеличит их длину. логика осталась таже.
ussr пишет:
> C>shl, shr, масочки там всякие... > я говорил не об этом. я говорил о том, что самый переход с 32 на 64 > бита не даст прироста количества регистров, а лишь увеличит их длину. > логика осталась таже.
Здравствуйте, Cyberax, Вы писали:
C>ussr пишет:
>> C>shl, shr, масочки там всякие... >> я говорил не об этом. я говорил о том, что самый переход с 32 на 64 >> бита не даст прироста количества регистров, а лишь увеличит их длину. >> логика осталась таже.
C>Регистров тоже стало физически больше.
я говорил не об этом. я говорил о том, что САМЫЙ ПЕРЕХОД С 32 НА 64
бита не даст прироста количества регистров, а лишь увеличит их длину.
это лишь особонности платформы. есть и 32-битные платформы с большим количеством регистров
X>В первую очередь 64-разрядность дает не много памяти (и 64 разрядные регистры — это все фигня). Она дает много адресного пространства. Что дает возможность принципиально более легкого программирования алгоритмов, требующих операций с очень большими объемами данных.
Именно!
X>Например, можно спокойно отмапить в память многогигабайтную базу данных, вместо того чтобы ручками подгружать нужные куски. Пусть этим занимается ОС. Главное, что адресного пространста хватит на все.
И не только база данных. Если посмотреть на объёмы картинок, обрабатываемых при вёрстке — то там частенько бывает более 4GB.
Здравствуйте, ussr, Вы писали:
U>Здравствуйте, GlebZ, Вы писали:
GZ>>1. Возможность строить программы занимающие больше чем 4 гига памяти.
U>а разве сейчас нельзя
Можно, но приходится извращаться — AWE. Т.е. одновременно нельзя, но можно смещать окно.
В дополнение ко всему, что тут уже сказано — защиту кода от копирования, т.е. атрибут PAGE_EXECUTE != PAGE_READONLY. Впрочем, это фича не столько Win64 (формально это есть и в Win32), сколько x86-64.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я что то пропустил? С каких это пор SIMD инструкции стали работать с регистрами ALU?
Не готов вам ответить То о чём я говорю прочитано в популистской статье по 3DNOW!, возможно я что-то перепутал.
А что действительно описанный мной сценарий нереален?
Здравствуйте, henson, Вы писали:
H>Здравствуйте, Cyberax, Вы писали:
C>>Ошибаетесь. На большинстве 64-битных систем тип int остается 32-битным, C>>а вот указатели становятся 64-битными.
C>>-- C>>С уважением, C>> Alex Besogonov (alexy@izh.com)
H>Хотя зря IMHO ради совместимости забили на стандарт H>The 'int' data type is defined as "...the natural size of the architecture" (C++-98: 3.9.1.2).
Забили они скорее всего не просто так, а для совместимости со старым кодом.
int как был 32 разрядый так и остался, мало ли какая логика на это завязана (понятно, что это не есть хорошо, но тем не менее), перекомпилировал и должно работать, а вот если хочешь 64 бита, используй новые типы.
Здравствуйте, AndreyFedotov, Вы писали:
AF> И не только база данных. Если посмотреть на объёмы картинок, обрабатываемых при вёрстке — то там частенько бывает более 4GB.
Картинка в 4 гига, дай ссылку на сайт — хочу посмотреть.
Хотелось бы сказать, что не все так хорошо. Пускай адресация и 64 разрядная, а сколько на компе установлено памяти, столько и будет работать (несмотря на кол-во бит в поинтере).
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, AndreyFedotov, Вы писали:
AF>> И не только база данных. Если посмотреть на объёмы картинок, обрабатываемых при вёрстке — то там частенько бывает более 4GB. GZ>Картинка в 4 гига, дай ссылку на сайт — хочу посмотреть.
Дать Вам ссылку на 4GB файл? Как качать будете?
GZ>Хотелось бы сказать, что не все так хорошо. Пускай адресация и 64 разрядная, а сколько на компе установлено памяти, столько и будет работать (несмотря на кол-во бит в поинтере).
Обычно активно используется не все адресное пространство, а его небольшая часть. Она то и присутствует в оперативной памяти, а остальное загружается/выгружается по необходимости. Это слегка замедляется процесс, но намного лучше способов выделения памяти выше 640kB использовавшихся в DOS.
GZ>С уважением, Gleb.
Здравствуйте, henson, Вы писали:
AF>>> И не только база данных. Если посмотреть на объёмы картинок, обрабатываемых при вёрстке — то там частенько бывает более 4GB. GZ>>Картинка в 4 гига, дай ссылку на сайт — хочу посмотреть.
H>Дать Вам ссылку на 4GB файл? Как качать будете?
Ну раз шутка была воспринята всерьез, давай посчитаем. У нас есть картинка — 4 гига, допустим с 32 разряда на цвет. Получается что эта картинка: 200000x20000. Возьмем что у нас DPI — 1200. Тогда картинка ~166x16 дюймов. 166 дюймов или больше 3 метров — хорошая книжечка получается. Или мои сведенья устарели (давно этим занимался)?
Что касается больших файлов, то обычно в их формате реализуется теги доступа для того чтобы можно было напрямую найти тот или иной блок данных.
GZ>>Хотелось бы сказать, что не все так хорошо. Пускай адресация и 64 разрядная, а сколько на компе установлено памяти, столько и будет работать (несмотря на кол-во бит в поинтере).
H>Обычно активно используется не все адресное пространство, а его небольшая часть. Она то и присутствует в оперативной памяти, а остальное загружается/выгружается по необходимости.
Именно об этом я и говорил. Хочется или не хочется нельзя элементарно выполнить алгоритм с доступом ко всем частям сразу. Неэффективно. Обрабатывать частями значительно эффективнее. 64-разрядные адресация — хорошая помощь помогающая легко организовать доступ к различным областям памяти более 3-х гиг. Реализация такого маппинга — значительно проще чем AWE окна(точнее даже писать ничего не надо). Но повышает ли она на данный момент эффективность программ, на мой взгляд нет.
На fcenter.ru совсем недавно проскакивала обзорная статься Windows XP Professional x64 Edition RC1. Там есть сравнение результатов производительности некоторых программ на Windows XP Professional и Windows XP Professional x64 на одних и тех же процессорах.
картинка в фотошопе может состоять из множества слоев ?
что б получить некое разрешение картинки на печати — разрешение на экране должно быть в несколько раз больше ?
Это вопросы по теме которой я занимался в середине 90-х?
S__>картинка в фотошопе может состоять из множества слоев ?
Yes. Но я сомневаюсь что кому то нужно более 255 градаций на слой. Если суммировать слои, то получится те же 32 бита или 24 в зависимости от моды в которой действует художник (RGB, ARGB, CMYK). То есть, тот же самый объем памяти. S__>что б получить некое разрешение картинки на печати — разрешение на экране должно быть в несколько раз больше ?
Что значит больше? Вы решили на экране монитора, при печати требуемой для принтера (допустим 1200 DPI) просмотреть один дюйм картинки?
Или я ничего не понимаю , или одно из двух. К чему эти вопросы и как они относятся к теме?
GlebZ пишет:
> Что значит больше? Вы решили на экране монитора, при печати требуемой > для принтера (допустим 1200 DPI) просмотреть один дюйм картинки?
Есть принтеры, работающие и с 3000dpi и с 5000dpi (имею несчастье делать
для них печать научной графики).
Здравствуйте, Cyberax, Вы писали:
C>Есть принтеры, работающие и с 3000dpi и с 5000dpi (имею несчастье делать C>для них печать научной графики).
Круто! Значит все таки я устарел. И большие были по объему растровые файлы? Какова размерность цвета?
Вообще у меня крутится цифра, что максимум человеческий глаз может распознать 3000dpi. Но вот откуда цифра, и правда ли это, не знаю. Источник позабыл.
GlebZ пишет:
> C>Есть принтеры, работающие и с 3000dpi и с 5000dpi (имею несчастье > делать > C>для них печать научной графики). > Круто! Значит все таки я устарел. И большие были по объему растровые > файлы? Какова размерность цвета?
Передавать растрово даже не пытаемся — стараемся использовать векторные
команды. Разрешение цветов: 32 бита.
Здравствуйте, GlebZ, Вы писали:
AF>>>> И не только база данных. Если посмотреть на объёмы картинок, обрабатываемых при вёрстке — то там частенько бывает более 4GB. GZ>>>Картинка в 4 гига, дай ссылку на сайт — хочу посмотреть.
H>>Дать Вам ссылку на 4GB файл? Как качать будете?
Недавно проскакивала ссылка на спутниковую картинку размером около терабайта... Ну да это крайний случай, обычно картинки всё-таки меньше.
GZ>Ну раз шутка была воспринята всерьез, давай посчитаем. У нас есть картинка — 4 гига, допустим с 32 разряда на цвет. Получается что эта картинка: 200000x20000. Возьмем что у нас DPI — 1200. Тогда картинка ~166x16 дюймов. 166 дюймов или больше 3 метров — хорошая книжечка получается. Или мои сведенья устарели (давно этим занимался)?
32 разряда на цвет — это уже 4 байта. Итого — 4GB ~= 31600 * 31600 x 32 бита, при разрешении 1200 dpi (а для качественной полиграфии, бывает используется и больше), получаем 67 x 67 см — постеры бывают и больше — 2 на 2 метра. То есть выкрутиться с 32 битами можно, но уже проблематично.
Если речь идёт о спутниковой картинке — то там бывают размеры гораздо больше чем 31600 на 31600 — до 100000 на 100000 и больше.
GZ>Что касается больших файлов, то обычно в их формате реализуется теги доступа для того чтобы можно было напрямую найти тот или иной блок данных.
GZ>>>Хотелось бы сказать, что не все так хорошо. Пускай адресация и 64 разрядная, а сколько на компе установлено памяти, столько и будет работать (несмотря на кол-во бит в поинтере). H>>Обычно активно используется не все адресное пространство, а его небольшая часть. Она то и присутствует в оперативной памяти, а остальное загружается/выгружается по необходимости. GZ>Именно об этом я и говорил. Хочется или не хочется нельзя элементарно выполнить алгоритм с доступом ко всем частям сразу. Неэффективно. Обрабатывать частями значительно эффективнее. 64-разрядные адресация — хорошая помощь помогающая легко организовать доступ к различным областям памяти более 3-х гиг. Реализация такого маппинга — значительно проще чем AWE окна(точнее даже писать ничего не надо). Но повышает ли она на данный момент эффективность программ, на мой взгляд нет.
Обычно много памяти и не нужно. Дисплей то не 31Kx31K — а всего 2Kx2K — т.е. 16 мегабайт. Большое адресное пространство нужно не для того, что бы увеличить объём памяти — её может быть столько же — а для того, что бы упростить алгоритмы.
Производительность программ повышается. Хотя бы потому, что не требуется тратить время на разнообразные конверсии и вспомогательные алгоритмы.
Здравствуйте, Cyberax, Вы писали:
C>tiberius пишет:
>> Коротко и ясно
C>Можно ссылку на методику проведения теста? Что-то слишком странные C>результаты, у меня получалось что-то около 10%-15% разницы.
А как там с драйверами?
Хочу поставить но не знаю полетит ли мой любимый MSFS2004
Здравствуйте, ussr, Вы писали:
U>я говорил не об этом. я говорил о том, что САМЫЙ ПЕРЕХОД С 32 НА 64 U>бита не даст прироста количества регистров, а лишь увеличит их длину.
он видимо думает, что AL AH AX EAX EEAX(?) это 5 разных регистров.
... <<silent RSDN@Home 1.1.4 beta 4 [303] Windows XP 5.1.2600.0 >>
Здравствуйте, GlebZ, Вы писали:
U>>а разве сейчас нельзя GZ>Нельзя, ограничения на юзер память 3 гига(насколько я помню) для ветки NT и 2 гига для 95 ветки. Начиная с 2000 возможны пляски с AWE. Но это уже другая история.
мне казалось что процессоры начиная с пентиум про, поддерживают до 64GB памяти.
... <<silent RSDN@Home 1.1.4 beta 4 [303] Windows XP 5.1.2600.0 >>
Здравствуйте, DEMON HOOD, Вы писали:
DH>Здравствуйте, GlebZ, Вы писали:
U>>>а разве сейчас нельзя GZ>>Нельзя, ограничения на юзер память 3 гига(насколько я помню) для ветки NT и 2 гига для 95 ветки. Начиная с 2000 возможны пляски с AWE. Но это уже другая история. DH>мне казалось что процессоры начиная с пентиум про, поддерживают до 64GB памяти.
Адресуемая память — да. То есть он может адресовать до 64 гиг оперативки.
Фактически на программном уровне, OS при правильной поддержке GDT+LDT может адресовать 64 терабайта. Но в рамках виртуальной машины прямые указатели работающие через LDT ограничены 2^32 поинтерами.
Что касается например 64-разрядного AMD, то у него 40-битная адресация(1 терабайт оперативки) и 48-битный виртуальный адрес.
Здравствуйте, Cyberax, Вы писали:
>> Что значит больше? Вы решили на экране монитора, при печати требуемой >> для принтера (допустим 1200 DPI) просмотреть один дюйм картинки?
C>Есть принтеры, работающие и с 3000dpi и с 5000dpi (имею несчастье делать C>для них печать научной графики).
Разрешение требуемой картинки рассчитывается не по dpi, а про lpi.
Здравствуйте, AndreyFedotov, Вы писали:
AF> 32 разряда на цвет — это уже 4 байта. Итого — 4GB ~= 31600 * 31600 x 32 бита, при разрешении 1200 dpi (а для качественной полиграфии, бывает используется и больше), получаем 67 x 67 см — постеры бывают и больше — 2 на 2 метра. То есть выкрутиться с 32 битами можно, но уже проблематично.
Постеры в 1200 dpi не печатают...
AF> Если речь идёт о спутниковой картинке — то там бывают размеры гораздо больше чем 31600 на 31600 — до 100000 на 100000 и больше.
А вот спутниковая картинка такого размера вполне может быть, вот только вряд ли она существует в виде единого файла — пользоваться-то неудобно будет...
GZ>>Именно об этом я и говорил. Хочется или не хочется нельзя элементарно выполнить алгоритм с доступом ко всем частям сразу. Неэффективно. Обрабатывать частями значительно эффективнее. 64-разрядные адресация — хорошая помощь помогающая легко организовать доступ к различным областям памяти более 3-х гиг. Реализация такого маппинга — значительно проще чем AWE окна(точнее даже писать ничего не надо). Но повышает ли она на данный момент эффективность программ, на мой взгляд нет.
Ну, некто IBM AS/400 утвержает, что не только повышает, но и вообще равных нет (это я умную книжку читал с картинками)
AF> Производительность программ повышается. Хотя бы потому, что не требуется тратить время на разнообразные конверсии и вспомогательные алгоритмы.
Вообще-то производительность на сегодня резко повышается за счет распаралеливания (хм, как пишется-то?) работы: на несколько ядер, на несколько процессоров, на несколько юнитов в кластере, на несколько компьютеров в сети, и т.д. Или я что-то путаю?
AF> Обычно много памяти и не нужно. Дисплей то не 31Kx31K — а всего 2Kx2K — т.е. 16 мегабайт. Большое адресное пространство нужно не для того, что бы увеличить объём памяти — её может быть столько же — а для того, что бы упростить алгоритмы. AF> Производительность программ повышается. Хотя бы потому, что не требуется тратить время на разнообразные конверсии и вспомогательные алгоритмы.
Производительность програмиста повышается (быстрее напишет программу),
а производительность самой програмы от наличия большого адресного пространства при таком же объеме
физической памяти практически никогда не повысится.
Не зря все нормальые серверы БД имеют собственный кеш, а не полагаются на возможности ОС по кешированию.
Нет конечно, но если ты мне объяснишь смысл загонять два числа в один регистр (полученные из двух адресов или одно из чисел уже находится в каком-то из регистров), то может и соглашусь?
