OSDev

DX10 появился в 2007 году, если память не изменяет. Для ИТ-отрасли это очень давно. Так что тех, кто до сих пор ориентируется на DX9, можно смело называть некрофилами :) Конечно, требовать, чтобы у каждого было новейшее железо, просто глупо (у меня оно новейшее, но только потому, что моя побочная работа -- его тестировать; у 99,99999% пользователей такой возможности нет). Но вот ориентироваться в перспективных разработках на то, что давно уже не выпускается...

Это не мелочи, хотя и не очень большая проблема. А вот написать высокоэффективный транслятор, который реально оптимизирует сравнимо с хорошим ассемблерщиком...

А компилятор Си мне писать приходилось. Больше не хочу и не буду ни за какие деньги (ну, разве что под угрозой смертной казни). Вот Паскаля или там Ады -- это можно и даже нужно, если время будет.

StasBaybak, в дополнение к предыдущему. При разработке под графические процессоры (неважно, разработке чего именно) необходимо учитывать вот ещё какой момент. По сути, ГП реализуют идеологию SIMD -- т.е. один поток инструкций и много потоков данных. На практике это означает, если в общих чертах, следующее.

Предположим, есть у нас некоторая программа (шейдер), обсчитывающая что-то там. Каждый поток (нить) этой программы работает со своей порцией данных (например, обсчитывает свой пиксель, если это пиксельный шейдер). Однако алгоритм работы остаётся один и тот же.

Далее, для запуска этой программы драйвер выделяет необходимые ресурсы, и в частности, распределяет программы по "процессорным блокам", после чего запускает на выполнение. Каждый такой крупный "блок" включает в свой состав одно устройство управления (оно считывает из памяти и декодирует команды, после чего вырабатывает управляющие сигналы для остальных блоков) и несколько арифметико-логических устройств (16, 32, 64 -- зависит от архитектуры ГП); кроме того, имеются вспомогательные блоки -- например, для чтения и записи памяти. Благодаря наличию множества АЛУ такой процессорный блок в каждый момент времени выполняет одну и ту же команду над несколькими группами данных, чем и достигается параллельная обработка (тот самый SIMD).

Но что происходит, если в потоке команд встречается условный переход? Понятное дело, что для одних потоков (нитей) условие может соблюдаться, а для других -- нет. Но ведь все АЛУ одного процессорного блока всегда выполняют одну и ту же команду! Поэтому здесь происходит следующее. Те потоки, для которых условие соблюдается, продолжают работать на этом же процессором блоке и дальше. А вот те, где условие не выполнено, своё выполнение на этом блоке прекращают: в дальнейшем вместо выполнения операций над данными в соответствии с командами программы для них выполняется одна и та же команда "нет операции" (блок управления запоминает, что для соответствующих потоков условие оказалось ложным, и просто не выдаёт управляющие сигналы на соответствующие АЛУ и блоки обращения к памяти). Чтобы продолжить выполнение этих ветвей (с ложным условием), требуется вмешательство драйвера. Он либо запускает их на выполнение на другом процессорном блоке с той точки, где оно было прекращено в связи с ложностью условия, либо дожидается окончания выполнения программы на текущем процессорном блоке и затем запускает его в работу над этими "ложными" потоками. Таким образом, любое ветвление приводит к ухудшению степени параллелизма, и в итоге может оказаться, что, хотя процессорный блок может одновременно работать над 16-32-64 потоками, он фактически выполняет лишь один поток, а остальные простаивают. Именно этим, кстати, объясняются разные результаты в тестах на ГП от Невидии и АМД: у АМД формально больше пиковая производительность, но его ГП намного сильней страдают от ветвлений. Поэтому на шейдерах, где ветвлений мало или нет вообще, АМДшные ГП показывают более хороший результат, чем Невидийные, ну а если там куча ветвлений -- то наоборот.

Эту особенность работы ГП требуется учитывать при создании любого ПО для него. В частности, хороший компилятор должен учитывать особенности реакции процессора на ветвления и стараться оптимизировать алгоритм таким образом, чтобы их было поменьше. А это, согласитесь, задача куда более сложная, чем тупо странслировать оператор присваивания.

Типичные задачи -- поиск подстроки в строке, вырезка части строки и т.д. В UTF-8 это решается сложней, чем в других кодировках, а заодно ухудшает производительность.

ну а определение положения символа для UTF-8 сложней, чем для UTF-16

В общем, насчёт кодировки я утверждаю, что UTF-8 -- сплошное говно, отстой и т.п., и им пользоваться не следует.

Поправочка-с... не сложней, чем в UTF-16 :)

В любом случае при хранении текстовой информации у UTF-16 и UTF-32 нет преимуществ перед UTF-8, одни недостатки.

Кстати, ещё один аргумент - любой валидный ASCI-текст автоматически является валидным UTF-8 текстом. С другими кодировками это не так. При обработке, согласен, в некоторых случаях UTF-32 может иметь преимущества. А UTF-16 - ни рыба, ни мясо. Г-но полное. Сочетает в себе недостатки 8 и 32-битной кодировки.

Сдаюсь!!!

Не знал такого. Знал, что обработка идет паралельно, но чтоб так.
Спасибо за ценную информацию, пригодиться.

(Не натыкался на статьи, которые описывают столь подробно работу графического GPU)

Либо так же, либо сложней, чем в UTF-16. Причина проста: у UTF-16 длина символа (2 или 4 байта) устанавливается путём анализа старшего байта, и всё. (если там определённые коды, то имеет место быть суррогатная пара, и соответственно, общая длина символа -- 4 байта; все остальные случаи -- длина символа 2 байта). А вот в UTF-8 требуется последовательно анализировать байт за байтом до тех пор, пока не будет определена длина символа. Соответственно, такой анализ сложней и медленней.

Неправда, а точней, полуправда. Если хранить тексты, нормально кодирующиеся в 7-битном ASCII -- то действительно, только недостатки.

Однако если это текст на китайском, то в UTF-16 он займёт меньше места, чем в UTF-8

Так что Ваше утверждение слишком категорично, скажем для разнообразия культурно :)

Опять-таки, слишком большая категоричность. Во-первых, допустимым текстом UTF-8 будет не любой допустимый ASCII, а любой, укладывающийся в "классический" 7-битный ASCII, а не в расширенный 8-битный.

Теперь что касается 16-разрядной кодировки. Её обработка, безусловно, сложней, чем 32-разрядной (требуется анализ на суррогатные пары), но она по-любому быстрей, чем для UTF-8 (см. про определение длины символа в самом начале)

в современном мире, где часто используются символы, выходящие за пределы 128 кодов стандартного ASCII, а соответственно, кодируемые как минимум двумя байтами в UTF-8: в таком случае последний не имеет преимущества над UTF-16 по объёму занимаемой памяти, но проигрывает по скорости обработки из-за более долгого анализа длины символа.

А разве на ixbt не описывалось? Я-то сам разбирался по техническим презентациям, главным образом от Невидии, ну и плюс в общении с ихними инженерами кой-какие нюансы выяснялись... Кроме того, AMD в своё время открыла документацию на доставшиеся ей вместе с купленной АТИ графические процессоры -- это как раз первые ДХ10-совместимые были. Понятно, что современные отличаются от них, но общие идеи во многом те же самые (ДХ11 куда меньше внёс дополнительных требований к графическим процессорам по сравнению с ДХ10, чем ДХ10 по сравнению с ДХ9; более того, ту же тесселяцию можно делать и на процессоре, соответствующем требованиям ДХ10, но не ДХ11, просто это придётся программировать ручками, а работать оно будет много дольше, чем на ГП для ДХ11, поскольку не будет специализированной аппаратной поддержки).

Ну а вообще, если всерьёз интересуетесь графикой, завязывали б с некрофилией :) Она представляет несомненный исторический интерес, но ориентироваться надо всё ж на современность и перспективу...

Кстати, об Ogre. Я не знаток Си++ (не говоря о том, что я ненавижу все языки, пошедшие от Си, за их ужасный синтаксис и низкую надёжность), но, тем не менее, его исходники мною воспринимались без особых напрягов -- приходилось только спрашивать время от времени приятеля (работающего в игрострое и хорошо знающего Си++) про некоторые тонкие моменты ООП и тому подобные вещи. В то же время исходники компиляторя ФриПаскаля читать почти невозможно: написано абсолютно безобразно. Это лишний раз иллюстрирует, что исходный язык для восприятия важен (при прочих равных исходник на Паскале/Аде объективно легче воспринимается, чем исходник на Си и тем более на Си++), но ещё важней соблюдать хороший стиль программирования. Создатели Огра не злоупотребляют извращёнными возможностями Си++ -- и в результате его вполне можно понять, ну а создатели ФриПаскаля... Глядя на их труды, поневоле задумываешься о пользе абортов (и сожалеешь о невозможности предсказания целесообразности таковых, пока это не поздно).

Вы говорили про определение НАЧАЛА символа. Начало символа в UTF-8 определяется тоже предельно просто. Символы с кодами 0-7Fh - это цельный символ. В остальных случаях, если встретившийся код больше или равен 0C0h - это первый байт символа, независимо от его длины. Всё.

Оооо! Какой прогресс! Я жму вашу руку! Наконец вы начинаете общаться в правильном ключе, - уважительно!! :)

Тэкс, теперь вы уже про ДЛИНУ символа говорите? ОК, это тоже определяется предельно просто. Длину символа СРАЗУ задаёт первый байт последовательности.

Даже в русском языке полно пробелов, цифр, знаков препинания и прочих символах. Так что текст получается плотней. Это раз.
Хотите вы или нет, но UTF-16 тоже требует анализа на возможную длину символа, даже если суррогатные пары и не встречаются. Значит не выигрывает, или выигрыш получается весьма незначительным. Это два.

И наконец. Подавляющее большинство работы с текстом не предполагает его сложного анализа. 90% т.н. "работы с текстом" это - хранение текста в базах данных, поиск на прямое совпадение, сортировка строк, вывод сообщений, в крайнем случае с простым форматированием, обмен сообщениями и пр. мутотень, - ВСЁ это не отличается от обработки обычного ASCII-текста. В то время, как работа с 16 и 32-битными кодировками вынуждает делать вторую копию большинства системных функций для передачи параметра WCHAR*. Даже поиск начала символа и определение длины строки в символах - уже встречаются весьма не часто.

Я тоже многое ненавижу. Но долг зовет. Чтобы быть проффесионалом нужно терпеть, даже если это не нравиться.

А поподробней можно? У меня лично отложилось в голове, что по первому байту можно судить лишь о том, один байт в символе или более одного, но нельзя установить длину, если она больше 1.

Если первый байт - 110*****, в символе два байта.
Если первый байт - 1110****, в символе три байта.
Если первый байт - 11110***, в символе четыре байта.
Теоретически, возможны длины до 6 байт, однако стандарт определяет коды только с максимальным размером 4 байта.