OSDev

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

1) Современные шейдеры пишутся на высокоуровневых языках, а не на "шейдерных ассемблерах". Соответственно, их трансляция по сложности сопоставима с таковой для, например, Си (тем более, что HLSL синтаксически весьма похож на Си). Но, в отличие от центральных процессоров, системы команд графических процессоров серьёзно меняются с каждым новым поколением, поэтому сам по себе транслятор -- вещь весьма нестабильная (его постоянно надо допиливать и перепиливать, причём поддерживая генерацию кода под разные модели ГП -- это одна из причин, почему драйверы что Невидии, что АМД такие здоровые).

2) В современным графических процессорах (начиная ещё с поколения, непосредственно предшествовавшего DirectX 10; у Невидии ему соответствуют видюхи серии GeForce 7xxx, у АМД, тогда ещё АТИ -- не помню точно, но вроде 1ххх), технически нет ни вершинных, ни пиксельных, ни каких-либо ещё других специализированных шейдеров: архитектура эти ГП стала унифицированной. Различные названия для шейдеров (вершинные, пиксельные, геометрические, вычислительные, ещё там какие-то) отражают логические функции этих самых шейдеров, но никак не наличие каких-либо отличий в собственно коде.

3) Начиная с графических процессоров, соответствующих требованиям DirectX 10, шейдеры могут достаточно свободно обращаться к различным областям памяти, причём как на чтение, так и на запись. Более того, сама память, к которой в процессе работы обращается ГП, стала виртуальной, и за её отображение на физическую отвечает как аппаратура ГП, так и драйвер.

Прямое. Нет у них тех разработок.

Поэтому и нету.

Бред несёте Вы. Но он в мою пользу. О том и речь не было базы. А почему на западе была?
Потому что распил и всё такое.

Разработка не пошедшая в массы не стоит денег на неё затраченных. Почему нет упоминаний? Да, потому что не востребованы.



С300 по твоему не серьёзно. Ну-ну.

Зато у UTF-8 куча геморроя с работой с этими строками. Так что для хранения в виде файлов он ещё пригоден, но в качестве рабочей кодировки, имеющей место быть в ОЗУ -- ну его нафиг.

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



У меня с этим проблем точно не будет, хотя я использую UCS-2. Даже изменений в подпрограммах не потребуется, скорей всего: суррогатные пары просто будут трактоваться как два разных символа, чего для нужд создания-поиска-уничтожения объектов ядра хватает (ну а за файлы отвечают файловые системы, а не ядро, почему и АПИ расширять не придётся: ядро лишь передаёт им запросы на выполнение).


Так в том-то и дело, что определённая категория этого ноя вполне обоснована. Очень часто проектировщики ПО рассчитывают на то, что их продуктом будут пользоваться профессионалы. Более продвинутые разрабы на профессионалов не надеются, но рассчитывают, что у пользователя будет время и желание разобраться. Однако это не так. Ни времени, ни желания разбираться или читать справку у большинства пользователей нет, поэтому там, где можно сделать одну большую кнопку "поехали", должно быть так. Это называется "интуитивно понятный UI". Таковы реалии и ничего с этим не поделать. Сложный продукт не будет иметь коммерческого успеха.[/quote]

Поправочка: сложный продукт для простых задач. Если сама по себе задача сложна, для неё невозможно создать простой продукт "для блондинок". К примеру, САПРы или там ПО для трёхмерного дизайна и анимации будут оставаться сложными в силу сложности решаемых ими задач (упрощение здесь означает уменьшение возможностей, что для профессионального инструмента неприемлем). Вот в случае с простыми задачами -- тут да, надо стремиться к простоте (но не доводить до абсурда; например, установщик ОС должен уметь работать на "автопилоте" с минимальным ручным вмешательством, но должен допускать и тщательную ручную настройку всех мыслимых и немыслимых параметров: для некоторых сфер применения это может оказаться важным, ну а для всего остального -- "автопилот").

Пожалуй, соглашусь, что Вы -- тролль. База была, но эта база была не в виде ПК. Абсолютно та же ситуация была и на Западе. Если месье Безье придумал свои кривые при проектировании автомобилей в 1960-х годах, на какой технике, по-Вашему, он работал? На ПК, которые появились лишь в 1980-х? Тогда Франция воистину крута: вон сколько лет у них имеется машина времени, которую они тщательно скрывают.



Опять полная глупость. Эти советские разработки очень даже шли в массы. Например, типовые комплексы бухучёта для всяких там десадов и школ эксплуатировались на мини-ЭВМ, начиная примерно с середины 1970-х годов, в каждом сколько-нибудь крупном городе СССР (ориентировочно -- начиная с численности населения в 50 тыс. человек). У каждого крупного промышленного предприятия был свой вычислительный центр, на котором, естественно, крутился и бухучёт, и САПР, и много чего другого. Если Вы этого не видели и не знаете, это ещё не означает, что этого не было.



С-300, к Вашему сведению, создан ещё в СССР, когда никакого Линукса и в помине не было; соответственно, управляет этим комплексом специализированная советская машина со специализированной же советской системой. Да и тогдашний "Эльбрус" (никакого отношения к военному управлению не имеющий, кстати) занимал огромное место и базировался на идеях БЭСМ-6, с которой был, насколько помню, отчасти совместим (ну а нынешние "Эльбрусы" к нему никаким боком-раком не относятся, да и не являются, по сути, нашей разработкой: на них стоят процессоры SPARC).

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

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

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

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

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

Верно подмечено про разность архитектур. Действительно меняется все с каждым годом. Но дело в том, что сам DX 10 настолько еще свежий и новый, что про него не всегда идет речь. Потому как можно написать комплекс программ под современные веяния времени, а потом после релиза проекта тут ж появляется новое железхо и стандарты. Но это пример брать не особо хорошо, потому что оно требует новых видеокарт. В ином случае приложение написанное под старые 1-2 версии шейдеров будет запускаться везде. Но под новые требовать видеокарту, да и еще не дешевую. Но смешно получается, чтобы сделать расчеты, нужно бежать покупать видеокарту. Не проще специализированное оборудование для таких целей или услуги оплатить.

Написать компилятор для языка С тоже не проблема. Это мелочи. Как раз таки движок OGRE имеет свой высокоуровневый язык для GPU. Этому модули не уделено много внимания, но результат на лицо - все работает. Движок популярен и востребован.

Написать компилятор С++, и другие более навороченные языки - это уже трудности.
Джон Кармак написал даже свою версию языка С для игры - QuakeC. Там тоже много всего. Достойная альтернатива DLL. Не скрипт, но и не машинный код. Но все же. Свое подобие Java.

У меня кстати завалялся компилятор для Си где-то свой. Это осуществимо. По сравнению с разработкой ОС - это не так сложно.

Можете попробывать самому это сделать. И убедиться сами. Примеров масса в инете "как написать компилятор С". Может мне привести доказательства?(только время нужно чтоб все в порядок привести).

ЗЫ И с оптимизацией тоже.

Какого именно??


Я же сказал, - это наименьшее зло из перечисленных.


:lol: :))))) Нут так с таким же успехом вы можете трактовать и последовательности UTF-8, как 2-3-4 разных символа :)
Кстати, большинство стандартных текстовых библиотек (ну кроме подсчёта длины строки в СИМВОЛАХ), в т.ч. сортировка, поиск (без регулярных выражений) и много чего другого работает с UTF-8 без переделок.


Конечно задачи усложняются. Но всё равно можно сделать продукт с удобным и интуитивно понятным интерфейсом, а можно с совершенно невозможным. Вы пробовали работать в 3DS Max? А в автокаде? Да на освоение самых простых вещей может уйти не один день! Сравните интерфейс Corel Draw и Adobe Illustrator (два более-менее равноценных продукта). Я несколько раз пытался осилить иллюстратор, в конце концов расслабился и выкинул его из головы. Зато с корелом никаких проблем не возникает (кроме некоторой степени глючности самого корела).
В конце концов, сложность САПР - это в значительной степени миф, обусловленный именно сложностью пользовательского интерфейса. Ничего такого, в чём в принципе не смог бы разобраться выпускник технического ВУЗа в них нет. Подтверждение тому - с развитием технолигий более сложные задачи становятся доступными чайникам и даже детям! Визуальное программирование лего-роботов, трёхмерное моделирование в виртуальных лего-конструкторах :) и пр-пр-пр. С P-CAD профессионально работаю много лет - не понимаю, какие могут быть непреодолимые сложности в понимании принципов дизайна плат. Есть ряд несложных технологических норм и понимание электронных схем, всё остальное - дебри интерфейса и опыт - сюда ни в коем случае не нажимай, а вот чтобы сделать то-то, нужно сделать такую неочевидную последовательность действий. На освоение до степени автоматизма ушёл не один месяц сношений с UI при том, что в электронике я далеко не новичок.

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Автокад освоил без труда интерфейс достаточно простой. 3D Max так и не освоил не нашёл подходящего учебника. Знакомая тоже дальше чем нарисовать кубик и объединить с шариком не пошла.

А вот зато blender. blender это опенскоре замена 3D Max. Так вот интерфейс запутанный, но достаточно продуманный. Хороший видео материал помог быстро научиться делать примитивные вещи. Без опыта старт занял 1 день, кресло я нарисовал где-то за полчаса. Прогресс по сравнению с 3D Max колоссальный. Планирую изучать дальше как будет время.
Спрашивал подружку сможет ли она нарисовать в 3D макс к примеру ножницы она сказала не с может. А в блендере для меня это пройденный этап.

По поводу кодировок. Решать за китайцев я не буду. Они сами уже решили и у них есть свои кодировки поэтому выберу самую простую. Проблем с биг-ендинг у меня нет. Формат хранения,не связан с форматом обработки. Размер символа фиксирован, поэтому опять таки проблем нет. А да поддержки юникода тоже нет. И не будет. Заголовки это не проблема.

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



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

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



Зависит от задач. Например, я попробовал разобраться в фотошопе, но не осилил, поэтому остановился на кореловском фотопаинте: всё, что мне надо, он делает, причём проще, чем фотошоп. В короле дров тоже рисую время от времени. А вот мой приятель-художник поработал в кореле и вышвырнул его нафиг: с точки зрения профессионального использования он абсолютно по всем статьям уступает фотошопу и иллюстратору: некоторых возможностей нет вообще, другие есть, но неполноценные, третьи делаются сложней, чем в навороченных фотошопе/иллюстраторе... Ну и глюки, конечно, тоже свою роль играют.

Так что не надо стремиться сделать простым всё. Просто должны быть инструменты для профессионалов (где главное -- функциональные возможности) и "для блондинок" (в том же художестве я -- как раз та самая блондинка, нихрена не соображаю и изучать что-либо не желаю: мне нужно, грубо говоря, уметь делать bmp-файл нужного разрешения из готового изображения, и ничего более).



А вот с этим полностью согласен.

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



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

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