Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Что-то я в эт совсем не верю. Реально этого SSE кода в большнистве приложений кот наплакал — где там плавающая арифметика ?

У нас — везде.

PD>Ну а если все же есть — вынести ее в DLL и все.

Именно оно и вынесено.

PD>Ты для начала попробуй создать DLL с 500 Кб кода, а потом поговорим.


Без комментариев.
Размеры исходников современных проектов себе представляешь? Не ресурсов и всякой фигни, а тупо подсчет суммарного размера *.h/*.cpp/*.cs файлов?


PD>Что же касается данных и ресурсов, то их дублировать совсем незачем.

Нету ресурсов, а данные — исключительно вещественные литералы, требуемые для алгоритмов.


V>>Да хоть за 5 секунд. Сделал ты 2 длл, как ты ими пользоваться намерен, если они не подменяют одна другую во время инсталляции, а лежат рядом с разными именами?

PD>А зачем им лежать-то ? Инсталлятор выбирает нужную и записывает только ее. Или ты боишься, что заменят на машине процессор на худший ? Ну что же, можно и это предусмотреть и предложить ренисталляцию. Хотя вероятность такого события 10^-N.

Нет, дело в Click-once и манифестах. Ты не сможешь провернуть такой фокус. Ты даже не сможешь провернуть такой трюк, как копирование/переименование при первом запуске одной из установленных библиотек (если нет админских прав), ну типа чтобы выбрать одну из скачанных по Click-once. Безопасность, однако.

Здравствуйте, Antikrot, Вы писали:

A>угу, а еще давай ты расскажешь в каком месте ядру будет лучше от этих -msseX

Они не только вещественные данные обрабатывают. Отлично подходят для вычисления всяких хешей и контрольных сумм.

Здравствуйте, Antikrot, Вы писали:

A>угу, а еще давай ты расскажешь в каком месте ядру будет лучше от этих -msseX

А да, забыл про драйвера аудио и видео. Например, шумоподавление и эхоподавление выполняется драйвером DirectX на уровне исполнения ядра, а не юзверского кода...

Здравствуйте, Antikrot, Вы писали:


A>И это говорит человек, который требует от других знать как ОС работает внутри Кстати, выбор в конфигураторе таки влияет, но sse тут не причём. Кроме того — а ты точно уверен, что оно не будет *медленнее*?

Для GCC последних версий — не будет. Кстати, этот зоопарк несовместимых по командам x86-х — реальный аргумент в пользу Шеридана в его агитации собирать все из исходников.

A>> S>Ясен пень, они просто вынуждены уходить в сторону многоядерности.
A>> пень не ясен. у тебя уже есть масштабируемые алгоритмы для всего-всего?
S>Они обязательно уже должны быть? Вдобавок еще и у меня?
S>Дядь, а можно они будут не у меня, а их просто напишут более опытные программисты, а?

Зачем обязательно более опытные? Интсрумент (а язык программирования — это в первую очередь всего лишь инструмент) должен помогать программисту, а не мешать ему. Вот, ознакомься на досуге: http://grey-kristy.livejournal.com/87271.html

A>>ты не совсем понял. Ц++ тут чуть ли не худший вариант.

V>Не говори ерунды. С++ предоставляет низкоуровневые сервисы к аппаратуре и интерфейсу ОС, точно такие же, какие ты бы получил на С или даже асме. Если ты имеешь ввиду инструменты, типа Эрланга, то их эффективность связана исключительно с эффективной реализацией легкий потоков, что и на С++ прекрасно делается на фиберах.

Угу, и сколько человеколет для этого нужно?

Здравствуйте, DOOM, Вы писали:

DOO>Мне, как потребителю, глубоко филетово до того, какие они там преобразования Фурье использовали и прочие малопонятные вещи — я вижу просто: есть картинка №1 — симпатичнее и менее требовательная, есть картинка №2 — менее симпатичная и тормозящая. Отсюда вывод: картинка №2 создавалась некачественно. При чем тут написанные ими требования? Я тоже много что написать могу...

Игра это далеко не только картинка.

Здравствуйте, DOOM, Вы писали:

DOO>Еще раз. Давайте не будем прикидываться шлангами. Возьмем для примера движок HL2 — явно более продвинутый, чем у первого хитмана. Тем не менее, он прекрасно себя чувствует даже на PIII 800 с 256 Мб ОЗУ.
Ты ничего не путаешь?
С минимальными настройками может он и заведётся, но тормозить будет.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ты для начала попробуй создать DLL с 500 Кб кода, а потом поговорим.
Я правильно понимаю что под 500 кб кода понимается размер бинаря?
Такие размеры в числодробилках достижимы легко, сложнее даже сделать меньше чем 500 кб при оптимизации по скорости.

Здравствуйте, vdimas, Вы писали:

PD>>Что-то я в эт совсем не верю. Реально этого SSE кода в большнистве приложений кот наплакал — где там плавающая арифметика ?

V>У нас — везде.

Так что у вас. У большинства приложений — вряд ли.

V>
V>Без комментариев.
V>Размеры исходников современных проектов себе представляешь? Не ресурсов и всякой фигни, а тупо подсчет суммарного размера *.h/*.cpp/*.cs файлов?

Меня мало интересуют размеры исходников, это дело разработчиков. А 500 Мб чистого кода — это очень немало.

Вот пожалуйста

ntoskrnl.exe Ядро ОС как-никак

19C000 .text , т.е. 1.5 Мб кода.

nvcuda.dll. Тоже не шутка, ПО для GPU.

1F2000 .text, т.е. 2 Мб.

winmm.dll

26000 .text. Всего-то 150 Кб.

win32k.sys (вот уж где ужас должен быть!)

29F000 .text Ан нет, примерно 2.8 Мб


PD>>Что же касается данных и ресурсов, то их дублировать совсем незачем.

V>Нету ресурсов, а данные — исключительно вещественные литералы, требуемые для алгоритмов.

Ну и храните их в отдельной DLL.


V>>>Да хоть за 5 секунд. Сделал ты 2 длл, как ты ими пользоваться намерен, если они не подменяют одна другую во время инсталляции, а лежат рядом с разными именами?

PD>>А зачем им лежать-то ? Инсталлятор выбирает нужную и записывает только ее. Или ты боишься, что заменят на машине процессор на худший ? Ну что же, можно и это предусмотреть и предложить ренисталляцию. Хотя вероятность такого события 10^-N.

V>Нет, дело в Click-once и манифестах. Ты не сможешь провернуть такой фокус. Ты даже не сможешь провернуть такой трюк, как копирование/переименование при первом запуске одной из установленных библиотек (если нет админских прав), ну типа чтобы выбрать одну из скачанных по Click-once. Безопасность, однако.

Что за ерунда ? Есть инсталлятор. Он распаковывает в какой-то временный каталог (иногда видимо для юзера, даже порой спрашивая его — куда ?, иногда невидимо). Потом берет оттуда то, что надо и записывает в Program Files\ProductName\. Что за проблемы ? Зачем мне что-то еще потом без админских прав делать-то ? Там будет только та DLL, которая нужна.

Здравствуйте, CreatorCray, Вы писали:

CC>Я правильно понимаю что под 500 кб кода понимается размер бинаря?

Нет. Секции .text в бинаре.

См. http://rsdn.ru/forum/flame.comp/3780625.1.aspx

Автор: Pavel Dvorkin
Дата: 20.04.10

Здравствуйте, neFormal, Вы писали:


DOO>>Точно не помню. То ли HL 1, то ли IGI... Давно это было.
F>HL1 по картинке и функционалу до "Хитмана" очень далеко..
Ты с каким хитманом сравниваешь? Там была убогая низкодетальная мультяшная графика. В отличие от...

F>IGI в плане картинки такой же или чуть лучше, но это всё таки 3D-шутер с более простым функционалом..
Непонятно... Ну да — трупы там нельзя было таскать по лесенке (кстати, я как в хитмане не отразил мега реалистичности этого процесса) — но в целом там ого-го было... Те же размеры локаций...

DOO>>Еще раз. Давайте не будем прикидываться шлангами. Возьмем для примера движок HL2 — явно более продвинутый, чем у первого хитмана. Тем не менее, он прекрасно себя чувствует даже на PIII 800 с 256 Мб ОЗУ.
F>что то по поводу памяти у меня очень большие подозрения.. ну и по качеству картинки тоже сомневаюсь..
F>какие нибудь ссылки/доказательства есть?.
В HL2 я первый раз играл именно на такой конфигурации — грузилось долго, но игровой процесс совершенно не тормозил.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, DOOM, Вы писали:

DOO>>Еще раз. Давайте не будем прикидываться шлангами. Возьмем для примера движок HL2 — явно более продвинутый, чем у первого хитмана. Тем не менее, он прекрасно себя чувствует даже на PIII 800 с 256 Мб ОЗУ.
CC>Ты ничего не путаешь?
CC>С минимальными настройками может он и заведётся, но тормозить будет.
Нет не путаю. Я в него даже достаточно долго играл, пока не дошел до большого жука — где бажный движок скриптов все-таки заглючил окончательно и вортигон после выпиливания железы их жука тупо завис...

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Ты для начала попробуй создать DLL с 500 Кб кода, а потом поговорим.
CC>>Я правильно понимаю что под 500 кб кода понимается размер бинаря?
PD>Нет. Секции .text в бинаре.
PD>См. http://rsdn.ru/forum/flame.comp/3780625.1.aspx

Автор: Pavel Dvorkin
Дата: 20.04.10

500 КБ секция кода — легко.
По ссылке ты речь ведёшь о МБ

Здравствуйте, CreatorCray, Вы писали:

CC>500 КБ секция кода — легко.
CC>По ссылке ты речь ведёшь о МБ

Да, но все ядро системы вместо с графикой и окнами — примерно 4 Мб. Так что 500 Кб — это более 10% ядра ОС.

Здравствуйте, vdimas, Вы писали:

V>Ну а в шустрых процах от АМД того времени никакого SSE2 не было. А производительность 3200+, зачем же его на мусорку? Для офисных задач это более чем подходящая машинка и таких компов хватает вокруг да около.

Странно, мой 3200+ вполне себе SSE2 и SSE3 поддерживает, как раз года 3 назад выпустился. Хотя тот же mplayer при динамической подгрузке оптимизаций SSE3 не видит .

Здравствуйте, Mamut, Вы писали:

V>>Не говори ерунды. С++ предоставляет низкоуровневые сервисы к аппаратуре и интерфейсу ОС, точно такие же, какие ты бы получил на С или даже асме. Если ты имеешь ввиду инструменты, типа Эрланга, то их эффективность связана исключительно с эффективной реализацией легкий потоков, что и на С++ прекрасно делается на фиберах.

M>Угу, и сколько человеколет для этого нужно?

В числодробилках? Ровно столько, сколько стоит изобрести и отладить алгоритм. А реализация готового алгоритма на любом из языков (поддерживающих арифметические вычисления) — это такая незаметная и под микроскопом ерунда, что обсуждать тут нечего.

Или ты про реализацию фиберов спрашивал? Все уже давно работает.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Меня мало интересуют размеры исходников, это дело разработчиков. А 500 Мб чистого кода — это очень немало.

PD>Вот пожалуйста

Что хотел примерами сказать?

V>>Нету ресурсов, а данные — исключительно вещественные литералы, требуемые для алгоритмов.

PD>Ну и храните их в отдельной DLL.

Выпал в осадок... Павел, не торопись ты с ответами... Вещественные литералы — это аналоги целочисленных констант, во всех числодробилках ведется борьба за увеличение скорости подкачки вещественных чисел, и предлагать мне организовать доступ к ним через thunk — это просто из ряда вон. Я уже молчу об организационных проблемах: нафига мне многие сотни дополнительно экспортируемых символов из DLL?


PD>Что за ерунда ? Есть инсталлятор. Он распаковывает в какой-то временный каталог (иногда видимо для юзера, даже порой спрашивая его — куда ?, иногда невидимо). Потом берет оттуда то, что надо и записывает в Program Files\ProductName\. Что за проблемы ? Зачем мне что-то еще потом без админских прав делать-то ? Там будет только та DLL, которая нужна.

В большинстве популярных настроек политик инсталлятор могут запускать юзвери с админскими правами (иногда "продвинутые", но это больше на домашних PC). А Click-once позволяет скачивать, обновлять и устанавливать приложения обычным юзверям. В этом случае прога ставится не в PF, а в локальный кеш браузера, который периодически чистится.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, CreatorCray, Вы писали:

CC>>500 КБ секция кода — легко.
CC>>По ссылке ты речь ведёшь о МБ

PD>Да, но все ядро системы вместо с графикой и окнами — примерно 4 Мб. Так что 500 Кб — это более 10% ядра ОС.

Это только тот код, который работает с абстракциями. А все реальные дрова, реализующие эти абстракции, кодеки и т.д. — многократно больше.

V>>>Не говори ерунды. С++ предоставляет низкоуровневые сервисы к аппаратуре и интерфейсу ОС, точно такие же, какие ты бы получил на С или даже асме. Если ты имеешь ввиду инструменты, типа Эрланга, то их эффективность связана исключительно с эффективной реализацией легкий потоков, что и на С++ прекрасно делается на фиберах.

M>>Угу, и сколько человеколет для этого нужно?

V>В числодробилках? Ровно столько, сколько стоит изобрести и отладить алгоритм. А реализация готового алгоритма на любом из языков (поддерживающих арифметические вычисления) — это такая незаметная и под микроскопом ерунда, что обсуждать тут нечего.

V>Или ты про реализацию фиберов спрашивал? Все уже давно работает.

Не про реализацию фиберов. А про реализацию многопоточности + асинхронных сообщений + отслеживания ошибок в этих сообщениях + иерархии процессов, как в Эрланге (где все это уже есть — бери и пользуйся). Более того, какого уровня должен ыть программист на C/C++, чтобы все это реализовать на фиберах.