64 бит ОС

 
BG ceci_ #26.01.2005 13:16  @Реконструктор#26.01.2005 13:05
+
-
edit
 

ceci_

втянувшийся

Реконструктор>
Или все-таки есть еще кое-что?
 

Реконструктор> Вопрос, разумеется, риторический. И если ls-у не надо быть 64 битным, почему бы его не сделать сразу 8 битным? :rolleyes: Представляеш сколько места сэкономиш, а функциональность - та же. :rolleyes: [»]

Нет сдесь скорее вопрос в совместимости
Вот пример:

> file vmunix
vmunix: ELF-64 executable object file - PA-RISC 2.0 (LP64)

> file /bin/ls
/bin/ls: PA-RISC1.1 shared executable dynamically linked

> file /bin/tar
/bin/tar: PA-RISC1.1 shared executable dynamically linked
 
BG Реконструктор #26.01.2005 13:21
+
-
edit
 
Ром, основная причина наращивания разрядности - это стремление обрабатывать как можно больше данных на единицу времени.
В этом смысле, если стринговые функции этого паршивого лс-а обрабатывают цыпочки побайтно, это будет медленно. Если поток будет иметь двубайтовую основу, то программа будет работать быстрее. Максимальная производительность будет достигнута когда квант потока равен разрядности процессора. Мне несколько неудобно такие вещи разъяснять ТЕБЕ. :)
Опкоды здесь не имеют никакого значения. Они так или иначе не настоящие. :)
 
BG Реконструктор #26.01.2005 13:24
+
-
edit
 
ceci_> Нет сдесь скорее вопрос в совместимости

Не знаю как там в Линуксе, но расклад дел в ХР64 такой:

Совместимость
Операционная система Windows XP 64-Bit Edition предоставляет мощную платформу для интеграции 64-разрядных технических приложений и 32-разрядных бизнес-приложений благодаря использованию эмулятора WOW64 (Windows on Windows 64) для процессоров x86.
 


Т.е. эмулятор, какой есть для 16 битных проложений в 32 битном ХР. :)
 
RU Balancer #26.01.2005 13:27  @Реконструктор#26.01.2005 13:21
+
-
edit
 

Balancer

администратор
★★★★☆
Реконструктор> Ром, основная причина наращивания разрядности - это стремление обрабатывать как можно больше данных на единицу времени.

Это - в переходе с 32 бит на 64 :)
Но это не единственная причина. Объёмы данных - столь же важны. Файлы в 4Гб в наше время - обыденность :) Оперативки больше 4Гб - вполне адекватная система.

А вот раньше с 16 бит на 64 переходили практически исключительно из-за крайней узости 64кБ блоков данных :)

Реконструктор> В этом смысле, если стринговые функции этого паршивого лс-а обрабатывают цыпочки побайтно, это будет медленно. Если поток будет иметь двубайтовую основу, то программа будет работать быстрее. Максимальная производительность будет достигнута когда квант потока равен разрядности процессора.

Вопрос только в необходимости такой скорости. Т.к. сортировку всё равно придётся вести даже не побайтно, а посимвольно (разницу видишь? нет?). А скорость копирования массивов 64-хбитным потоком и 32-хбитным будет отличаться в единицы процентов :)

Реконструктор> Опкоды здесь не имеют никакого значения. Они так или иначе не настоящие. :) [»]

Имеют :)
 
RU Balancer #26.01.2005 13:28  @Реконструктор#26.01.2005 13:24
+
-
edit
 

Balancer

администратор
★★★★☆
Реконструктор> Т.е. эмулятор, какой есть для 16 битных проложений в 32 битном ХР. :) [»]

Очень сомневаюсь, что также :)
16-битные приложения работали в отдельных VM.
А 32-хбитные, думаю (могу ошибаться) работают просто в отдельных сегментах.
Кто прояснит этот вопрос? :)
 
BG Реконструктор #26.01.2005 14:04
+
-
edit
 
Balancer> Вопрос только в необходимости такой скорости. Т.к. сортировку всё равно придётся вести даже не побайтно, а посимвольно (разницу видишь? нет?).

Это, очевидно, необезательно. Если сами символы отсортированы по отношению к их кодам в кодовой таблице, то сравнение цыпочек можно делать порциями, равными разрядности процессора.

Balancer>А скорость копирования массивов 64-хбитным потоком и 32-хбитным будет отличаться в единицы процентов :)

Клянусь, если найду 64 битный компилятор, сделаю тесты и кину их тебе в лицо. <_<
 
BG Реконструктор #26.01.2005 14:16  @Balancer#26.01.2005 13:28
+
-
edit
 
Balancer> Очень сомневаюсь, что также :)
Balancer> 16-битные приложения работали в отдельных VM.
Balancer> А 32-хбитные, думаю (могу ошибаться) работают просто в отдельных сегментах.
Balancer> Кто прояснит этот вопрос? :) [»]

Вообще-то, они могут работать бок-о-бок. :) Там есть отдельный 64 битный режим, но на нем можно запускать 32 битные программы. :) Вот цитатик:

Like all x86 processors, AMD64 chips power up in real mode, and it's up to to the operating system to shift it into 32-bit protected mode or into 64-bit "long" mode (as AMD calls it). This flexibility ensures that desktops and servers have full compatibility with 32-bit Windows, Linux, FreeBSD, NetWare and other operating system. The shift to 64-bit functionality is enabled by a 64-bit-aware operating system during its own bootstrap process. At that point, pointers can be 64-bits in length, the register extensions and the REX prefix become enabled, the extra quadword and double quadword data types turn on... you get the idea.

But that doesn't mean that every application, running in long mode, has to be a 64-bit app. Because the AMD64 microarchitecture uses the same instructions for 64-bit computing as it uses for 32-bit operations—with just a special prefix for the 64-bit operations—classic 32-bit applications run natively on an AMD64 processor (using a submode of long mode called "compatibility mode") without any modifications, taking advantage of a transparent thunking layer that implements 32-bit calls by translating parameters as necessary, and then calling the 64-bit kernel. As far as the user is concerned, it's just load-and-go. Performance is increased: According to AMD, the extra efficiencies of the 64-bit kernel are such some 32-bit applications will actually run faster on a 64-bit operating system than they will on a 32-bit OS.

While an individual 32-bit app is still limited to a 4GB address space, the operating system and microarchitecture can provide an exclusive address space for that 32-bit app and its data—and don't need to share that address space with the OS kernel, page tables or other apps. Thus, 32-bit Windows apps that are "large address aware" will immediately gain in scalability when running within a 64-bit operating system on the AMD64 architecture. Sweet.

The only limitations are that a 64-bit application must be loaded by a 64-bit operating system, and that an individual application can't mix 32-bit and 64-bits; it has to be one or the other. Of course, a 64-bit operating system can run both 32-bit and 64-bit processes at the same time, and in fact, those processes can use the OS's own interprocess communications structures to pass data between each other. So, a 32-bit legacy user-interface app can use ODBC or JDBC calls to work with a new 64-bit database, all running on the same 64-bit operating system.

In fact, where it's appropriate, you might gain real benefits from intentionally running both 32-bit and 64-bit apps at the same time. Because there's no performance hit, you can choose the instruction set for each application that best suits your needs: 64-bit for greater scalability and 16-byte data operations, and 32-bit for smaller binaries and compatibility with older x86 hardware.

Try that with another 64-bit processor. Only AMD64 processors give you the power of 64-bit computing and zero-compromises compatibility with the familiar 32-bit x86 microarchitecture. AMD may be the new kid on the 64-bit block... but they got it right.
 


Если кто интересуется программированием AMD64, рекомендую:

Welcome to AMD Developer Central | AMD's Software Developer Portal

developer; dev; development; developing; devcenter; devcentral; developer tools; forums; online community; x86; resource; support; support; AMD APP SDK; GPGPU; APU; heterogeneous computing

// www.amd.com
 



А по теме - эмулятор нужен хотя бы на уровне API. Без слоя, который транслирует старые 32 битные данные в новые 64 битные, никак не обойтись. Представим себе, например, некую API функцию sum, которая в ХР-32 имеет вид:
int32 sum(int32 a, int32 b);
а в ХР-63, соответственно:
int64 sum(int64 a, int64 b);
Чтоб 32 битная программа выполнялась корректно на 64 бит ОС, то нужен промежуточный слой:

code text
  1. int32 sum(int32 a, int32 b)
  2. {
  3. int64 a64, b64;
  4. a64 = a32; b64=b32;
  5. return sum(a64, b64);
  6. }
 
+
-
edit
 

Balancer

администратор
★★★★☆
На дня поставил две абсолютно идентичных Lubuntu разной разрядности в виртуалках. Немного сравнения затраченной памяти в 32 и 64 битах:

 32.0.1700.7632.0.1700.76
?? Balancer #23.01.2014 01:56  @Balancer#23.01.2014 01:26
+
-
edit
 

Balancer

администратор
★★★★☆
Туда же.

VIRT у Хрома просто отжигает:

Немного LibreOffice:
 32.0.1700.7632.0.1700.76
+
-
edit
 

Nikita

аксакал

Balancer> VIRT у Хрома просто отжигает:

Это нормальная современная техника программирования на тему. Вы ещё "бытовой" SQL Server не видели:
Прикреплённые файлы:
SQL Server and Virtual memory.png (скачать) [7,48 кбайт, 7 загрузок] [attach=370990]
 
 
Учитесь читать.  9.09.0

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru