Здравствуйте, 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-битных процессорах?
