Board.KolibriOS.org

Official KolibriOS board
It is currently Wed Feb 19, 2020 11:42 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 55 posts ]  Go to page Previous 1 2 3 4 Next
Author Message
PostPosted: Wed Sep 12, 2012 10:33 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Ядро операционной системы как раз и есть та самая задача. 32-х бит адресного пространства уже не хватает для комфортной работы ядра и драйверов.


Top
   
PostPosted: Wed Sep 12, 2012 11:18 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1382
Serge wrote:
Ядро операционной системы как раз и есть та самая задача. 32-х бит адресного пространства уже не хватает для комфортной работы ядра и драйверов.

:shock:

Горацио, бывают заморочки
с которых все ботаники фигеют.


У.Шекспир, Гамлет, акт 1.


Top
   
PostPosted: Thu Sep 13, 2012 7:22 am 
Serge wrote:
Ядро операционной системы как раз и есть та самая задача. 32-х бит адресного пространства уже не хватает для комфортной работы ядра и драйверов.

Сильно напомнило:
Quote:
С Хабра, обсуждение даты релиза iPhone 5:
stalkerxxl: В этот день миллионы счастливых обладателей iPhone 4S в одно мгновение станут нищебродами =))


Top
   
PostPosted: Thu Sep 13, 2012 11:55 am 
Offline

Joined: Wed Sep 15, 2010 7:22 pm
Posts: 101
Serge! Я не имел в виду, что 64-битную версию KolibriOS не имеет смысла делать ...


Top
   
PostPosted: Thu Sep 13, 2012 12:10 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
FireWall
Тем не менее ядро как раз и есть эта массовая пользовательская задача. Потому что все мы им пользуемся, даже если и не задумываемся над этим. И для ядра современного компьютера 4Гб адресного пространства уже мало. А для 99.9% массовых пользовательских программ "не игрушек" достаточно 32 бит.


Top
   
PostPosted: Thu Sep 13, 2012 1:06 pm 
Serge
Обычно я тебе верю, потому что ты аргументируешь. В данном случае прозвучало лишь заявление и никакой почвы под ним не подведено.


Top
   
PostPosted: Thu Sep 13, 2012 1:13 pm 
Offline

Joined: Wed Sep 15, 2010 7:22 pm
Posts: 101
Но у ядра есть PAE и PSE-36 ! И я как раз говорю о массовом пользователе, а не о специфических профессиональных задачах.

Другое дело, что легче создать универсальную операционноу систему (и это ничего, что она на компьютере массового пользователя будет тупо занимать место), чем две различные (одну - компактную и 32-х битную для массового использования, другую - продвинутую и 64-х битную для отдельных профессиональных а также обыденных серверных и корпоративных нужд (для настоящих корпоративных и научных всё равно нужен суперкомпьютер)). То же относится и для аппаратных платформ ... Вот и усаживают всех нас на сильно усечённую корпоративно-серверную платформу (рынок, мать твою)


Top
   
PostPosted: Thu Sep 13, 2012 4:43 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Аргументация.

Посмотрим на код sys_ipc_send.

Теперь представим что 32-х битные приложения Колибри работают под 64-х битным ядром.
Адресное пр-во каждого процесса помимо обычного мапинга на адреса 0 - 2Гб также мапится на адреса 512Гб + номер_слота*2Гб. Соответственно в режиме ядра есть одновременный доступ к адресным пространствам всех процессов и копирование ipc можно сделать простым rep movsq. Цена вопроса 4Кб для одной таблицы PML3 или 8 для двух таблиц если увеличить доступное приложению пространство до 4 Гб. Это только один пример.


Top
   
PostPosted: Thu Sep 13, 2012 8:25 pm 
Offline

Joined: Wed Sep 15, 2010 7:22 pm
Posts: 101
Ну сэкономим время заметно меньшее необходимого для ring3 -> ring0 -> ring3 (это для вычисления и копирования нескольких (в случае KolibriOS в 99,9% - одной, самой первой) последовательных записей из таблицы PD процесса на стандартный участок PD текущего контекста , соответствующий верхней области адресного пространства) :)

Удобно то оно конечно удобно (для программиста, пишущего ядро), но меня умиляет наблюдать за тем, как в Menuet64 в регистрах общего назначения мелькают скорее 16-и битные числа. (что-то вроде 0x00000000000xxxxx) Вы предлагаете разнообразить их чем-то вроде 0x000000хх000xxxxx. ну будет выглядеть чуть веселее. Но, на мой взгляд, - это из области "бешенства с жиру".


Top
   
PostPosted: Thu Sep 13, 2012 9:38 pm 
Offline
User avatar

Joined: Tue Aug 25, 2009 4:45 pm
Posts: 796
64битная система хороша тем, что можно обойтись вообще без маппинга памяти


Top
   
PostPosted: Thu Sep 13, 2012 11:59 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1382
FireWall прав, 64-битная адресация генерит гораздо более рыхлый (и потенциально более медленный) код.

И это еще очень большой вопрос, что для истории важнее - наличие 8 новых длинных регистров или отсутствие 32 (а то и 48) бесполезных нулей в каждом адресе.

Я опять в ту же тему: истина всегда должна быть где-то посередине...

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
PostPosted: Fri Sep 14, 2012 12:17 pm 
Offline

Joined: Wed Sep 15, 2010 7:22 pm
Posts: 101
Кстати, если говорить конкретно о KolibriOS, то идею одновременного доступа ко всем приложениям со стороны ядра можно осуществить и в текущем 32-битном варианте, выделив 4Мб*256 = 1Гб адресного пространства для повторного отображения приложений, для которых хватает 4 Мб.

А в целом дискуссия приобретает так сказать "философский характер": у каждого может быть своё мнения по поводу того, что он считает комфортным, достаточным и необходимым.

Мои философские взгляды таковы:
(1) Минимальная оправданная конфигурация для 64-битного процессора начинается с 4Гб оперативной памяти на борту. Такая нормальная - 16 Гб :)
(2) Выше названные удобства 64-битной адресации считаю мелкими в том смысле, что
- с одной стороны: ради них переходить с 32-х бит на 64 - НИ В КОЕМ СЛУЧАЕ;
- если же у нас на борту 64-процессор - грех не воспользоваться.

Другой вопрос, что заставить использовать MMX или SSE для 64-битной арифметики компилятор gcc (вместо цепочечного использования 32-х битных GPR) мне так и не удалось :) Поэтому информация, говорящая, что при перекомпиляции приложения с 32-х бит на 64-бита приложения начинает исполняться быстрее - сущая правда. Тому причиной:
- большее число регистров (а значит меньший поток данных процессор <-> память, связанный с временными данными и соглашениями вызова),
- неумение компиляторов рационально использовать MMX и XMM регистры (а в этом случае 64 битная арифметика на x86_64 будет существенно быстрее).
Как говориться, 64-битность x86_64 тут ни причём. (Для пояснения выскажу гипотезу, что если бы против 16-ти 64-х битных регистров в X86_64 с теперешними компиляторами, поставить 32 32-х битных регистров (в compatability mode) + научить компиляторы рационально использовать всё это хозяйство (перекомпилировать всё равно потребуется - на нормальном компиляторе :) ) - то этот рациональный 32-х битный код в compatability mode исполнялся ещё быстрее)
-----------------------------------
Дополнение:

Похоже, что 64-битную арифметику на IA32 осуществить хоть и можно - но сложно ( (1) использовать SSE2 (2) преобразование : i64_t -> Fpu -> i64_t). Так что ещё один маленький аргумент не в мою пользу :(


Top
   
PostPosted: Sat Sep 15, 2012 1:55 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1382
Давайте поставим вопрос другим ребром: а на кой нам вообще сдались 64 бита?

Иногда действительно нужно выходить из 4Гб-пространства.
В частности - для задач трассировки и выбора оптимального маршрута, когда (и если) имеет место т.н. "комбинаторный взрыв" -
необходимость перебора всевозможных комбинаций и перестановок большого числа исходных элементов.

Конкретных прикладных задач очень немного - их можно перечислить по пальцам:
1) трассировка проводов на многослойных печатных платах
2) очень реалистичный многолучевой рендеринг
3) строительный, оптомеханический и аэрокосмический трехмерный дизайн
4) оптимизация временных задержек между логическими вентилями на очень сложных процессорах и FPGA
5) обратные задачи в определении целей (на зашумленных сигналах) в радиолокации и распознавание трехмерных объектов по 2-мерному видеоряду
6) обработка временных рядов и долгосрочное прогнозирование в метеорологии и гидрографии.
7) некоторые задачи тепло-массопереноса, химической кинетики и газодинамики
8 (может забыл чего?) - дополните кто еще что-нибудь вспомнит. (ядро не предлагать :) )

Все перечисленные задачи настолько сложны и ресурсоёмки, что им ВСЕГДА выделяют практически монопольный приоритет в любой реальной системе.
В Колибри для ОДНОЙ подобной задачи вполне можно выделить отдельную голову, и гонять ее в монопольном 64-битном режиме.
При этом ядро и подсистема ввода-вывода остаются в 32-битном поле, взаимодействуя с 64-битной головой через общие страницы памяти и MSI-прерывания.


Top
   
PostPosted: Sat Sep 15, 2012 6:09 pm 
Offline
User avatar

Joined: Tue Aug 25, 2009 4:45 pm
Posts: 796
Simvolnye vychisleniya


Top
   
PostPosted: Sun Sep 16, 2012 4:58 pm 
Offline

Joined: Wed Sep 15, 2010 7:22 pm
Posts: 101
(1) Для символьных вычислений не нужно >4Гб адресного пространства (обычно), но при наличии 64-битных регистров (вместо 32-х битных) почти всегда наблюдается существенное увеличение производительности (например, на числах с произвольной точностью при умножении производительность может возрасти больше чем в два раза).

(2) Многоканальная студийная звукозапись, когда весьма желательно иметь возможность разместить весь проект, содержащий порой >32-х каналов (это на CD 1 минута занимает 10 Мб, при студийном качестве - это > 40Мб, так что на 40 дорожек по 10 минут каждая будет 40 * 40 * 10 = 16000 Мб).


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 55 posts ]  Go to page Previous 1 2 3 4 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited