Ещё один глупый вопрос....

Everything you can't fit into other forums
  • Serge wrote:Ядро операционной системы как раз и есть та самая задача. 32-х бит адресного пространства уже не хватает для комфортной работы ядра и драйверов.
    :shock:

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


    У.Шекспир, Гамлет, акт 1.
  • Serge wrote:Ядро операционной системы как раз и есть та самая задача. 32-х бит адресного пространства уже не хватает для комфортной работы ядра и драйверов.
    Сильно напомнило:
    С Хабра, обсуждение даты релиза iPhone 5:
    stalkerxxl: В этот день миллионы счастливых обладателей iPhone 4S в одно мгновение станут нищебродами =))
  • Serge! Я не имел в виду, что 64-битную версию KolibriOS не имеет смысла делать ...
  • FireWall
    Тем не менее ядро как раз и есть эта массовая пользовательская задача. Потому что все мы им пользуемся, даже если и не задумываемся над этим. И для ядра современного компьютера 4Гб адресного пространства уже мало. А для 99.9% массовых пользовательских программ "не игрушек" достаточно 32 бит.
  • Serge
    Обычно я тебе верю, потому что ты аргументируешь. В данном случае прозвучало лишь заявление и никакой почвы под ним не подведено.
  • Но у ядра есть PAE и PSE-36 ! И я как раз говорю о массовом пользователе, а не о специфических профессиональных задачах.

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

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

    Теперь представим что 32-х битные приложения Колибри работают под 64-х битным ядром.
    Адресное пр-во каждого процесса помимо обычного мапинга на адреса 0 - 2Гб также мапится на адреса 512Гб + номер_слота*2Гб. Соответственно в режиме ядра есть одновременный доступ к адресным пространствам всех процессов и копирование ipc можно сделать простым rep movsq. Цена вопроса 4Кб для одной таблицы PML3 или 8 для двух таблиц если увеличить доступное приложению пространство до 4 Гб. Это только один пример.
  • Ну сэкономим время заметно меньшее необходимого для ring3 -> ring0 -> ring3 (это для вычисления и копирования нескольких (в случае KolibriOS в 99,9% - одной, самой первой) последовательных записей из таблицы PD процесса на стандартный участок PD текущего контекста , соответствующий верхней области адресного пространства) :)

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

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

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

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • Кстати, если говорить конкретно о 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). Так что ещё один маленький аргумент не в мою пользу :(
  • Давайте поставим вопрос другим ребром: а на кой нам вообще сдались 64 бита?

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

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

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

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

    Users browsing this forum: No registered users and 5 guests