Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 5, Пользователей: 0 ...
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
| Центр информации по операционным системам :: Форумы :: Концепции :: ОС-21 |
|
<< Предыдущая тема | Следующая тема >> |
| Идея возможности проектирования ОС с высоким КПД использования аппаратных средств | ||
| Переход на страницу 1 2 [3] 4 ... 15 16 17 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| Jurik |
| ||
 ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | 2dcc: ты походу реально то ли плохо думаешь то ли плохо читаешь  Облегчу тебе задачу. Официальное название чипа GeForce 8800 Кодовое имя G80 Технология 90 нм 681 миллион транзисторов (!) Унифицированная архитектура (массив общих процессоров для потоковой обработки вершин и пикселей, а также других возможных видов данных) Аппаратная поддержка последних новшеств DirectX 10, в том числе и новая шейдерная модель - SM4, генерация геометрии и запись промежуточных данных из шейдеров. 384 бит шина памяти, 6 независимых контроллеров шириной 64 бита, поддержка GDDR4 (1.8Ггц) Частота ядра 575 МГц (GeForce 8800 GTX) 128 скалярных ALU с плавающей точкой (целочисленные и плавающие форматы, поддержка FP 32бит точности в рамках стандарта IEE 754, MAD+MUL без потери тактов) ALU работают на удвоенной частоте (1.35ГГц для 8800GTX) 32 текстурных блока, поддержка FP16 и FP32 компонент в текстурах И это всё на 575 мегагерц. Некотоыре задачи будт просто летать. А те которые не будут просто хотя бы будут сняты с ЦП что уже плюс. | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | 2 dcc: теперь выяснили у кого подход невдумчивый ? у nvidia которая реализовала CUDA и соответствующие инструментарии или у тебя ? я думаю NVdia лохи конечно же ... да и научные задачи по расчетам которые на 3d ускорители перекладывают это то же хреня .. dcc же ведь посмотрел что там всего 575 Мегагерц .. взвесил ..у Core 2 2800 ... больше .. круто ! так держать! | ||
| Наверх | | ||
| Hmmm |
| ||
  ID пользователя #719 Зарегистрирован: Среда 09.08.2006 11:29Местонахождение: Москва Сообщений: 108 | Вы, Jurik, не переживайте так. Большинство из того о чем Вы тут говорите в сущности решается уже сейчас, причем до смешного просто: открытые исходники + оптимизирующий компилятор. Хотите соптимизированной многопоточности? Нет проблем - есть такая замечательная везчь, как OpenMP. Ну лично мне она не очень нравится, я руками делаю оптимизированную многопоточную реализацию лучше чем компилятор, но это пока. Скоро появятся еще набор теорем под данную проблематику и мой опыт будет описан математически. Конечно в своих построениях Вы идете дальше, но мы пока текущего этапа не прошли. Скажите, а когда Вы рассуждаете о новом процессоре NVidia, Вы предполагаете что Вам будет доступно прямое программирование этого процессора (открытый набор команд framebuffer'а)? А если нет, тогда Вам опять предложат жмых в виде дров от производителя, в которых можно только догадываться что делается на GPU а что на CPU. Лично меня уже достали производители секретящие программирование своего железа. | ||
| Наверх | | ||
| Freeman |
| ||
 ID пользователя #3 Зарегистрирован: Четверг 01.07.2004 14:57Сообщений: 207 | Hmmm написал(а) ... Лично меня уже достали производители секретящие программирование своего железа. Так я о чём? Нужна новая мотивация, и её надо придумать. Супер-оптимизация по сравнению с ней - как два байта об текстолит. | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | 2Hmmm Я ж и писал что производитель может скрывать при данном подходе реализацию своего железа но сам может поставлять некие примитивы с законеченной фцункциональностью оптимизированные под его это самое скрытое железо ..одно другому не мешает ... | ||
| Наверх | | ||
| Hmmm |
| ||
| ID пользователя #719 Зарегистрирован: Среда 09.08.2006 11:29Местонахождение: Москва Сообщений: 108 | Jurik написал(а) ... 2Hmmm Я ж и писал что производитель может скрывать при данном подходе реализацию своего железа но сам может поставлять некие примитивы с законеченной фцункциональностью оптимизированные под его это самое скрытое железо ..одно другому не мешает ... Мешает! Если низкоуровневое API закрыто, то я ограничен теми "кубиками" которые мне предоставляет разработчик дров. Невозможно написать API на все случаи жизни. Сегодня нужно декодировать MP3, завтра Василий Пупкин изобретет мегасупербупералгоритм который я захочу использовать, и что? Дожидаться пока Nvidia его себе в дрова имплементирует? А если я разработчик, и мне хотелось бы мощу видюхи под счет задействовать? Ну вот подкинули мне б/у Geforce 6600, и чего? Во многих физических задачках для расчета такие алгоритмы используются, что ожидать их реализации на уровне дров попросту нереально. Поэтому выход по большому счету один - открытые API. Никакой осью эту проблему не решить. Если хотите оптимизаций - работайте с железом. Правда можно предложить еще один подход - виртуализация, но не на уровне машины, а на уровне теорем оптимизации. Т.е. кусок алгоритма отправляется в некоторый оптимизирующий модуль, поставляемый вместе с дровами, который выдает скомпилированный результат и прогноз его исполнения. На основании этих прогнозов и стоимости перехода от одной среды исполнения к другой, производится конкурс между оптимизирующими модулями. Но это настолько абстрактные рассуждения, что я их только в качестве теоретической альтернативы предлагаю. | ||
| Наверх | | ||
| k0l0b0k |
| ||
 ID пользователя #265 Зарегистрирован: Четверг 07.04.2005 14:48Местонахождение: Great Dnepr Сообщений: 36 | написал(а) ... а к этому кстати хорошо подходит MSIL, или подобие. виртуализация, но не на уровне машины, а на уровне теорем оптимизации | ||
| Наверх | | ||
| Freeman |
| ||
| ID пользователя #3 Зарегистрирован: Четверг 01.07.2004 14:57Сообщений: 207 | Jurik написал(а) ... одно другому не мешает ... Чем докажешь? Hmmm написал(а) ... Поэтому выход по большому счету один - открытые API. Никакой осью эту проблему не решить. Хе! А чем тогда, если не ОСью? Hmmm написал(а) ... Если хотите оптимизаций - работайте с железом. Это и делается сегодня. В чём идея-то? Hmmm написал(а) ... Правда можно предложить еще один подход - виртуализация, но не на уровне машины, а на уровне теорем оптимизации. Т.е. кусок алгоритма отправляется в некоторый оптимизирующий модуль, поставляемый вместе с дровами, который выдает скомпилированный результат и прогноз его исполнения. На основании этих прогнозов и стоимости перехода от одной среды исполнения к другой, производится конкурс между оптимизирующими модулями. Здраво рассуждаешь. Hmmm написал(а) ... Но это настолько абстрактные рассуждения, что я их только в качестве теоретической альтернативы предлагаю. Вроде в Москве живёшь, а не веришь. <span class='smallblacktext'>[ Редактирование суббота 10.03.2007 23:27 ]</span> | ||
| Наверх | | ||
| Jurik |
| ||
| ID пользователя #837 Зарегистрирован: Среда 07.03.2007 13:39Сообщений: 81 | 2Hmmm Мечтать что производители будут выпускать а) полную документацию к железу б) спец драйвера в) ещё и компилятор из MSIL в их код оптимизированный под железо Это вообще нереал Более реально если некие примитивы поставляются с ОС и есть имплементации их для некого оборудования. Если надо, можно сделать новый примитив с оптимизацией под например SSE или ещё под что, что открыто и без труда делается .. выйгрш может не тот но примитив будет новый .Nvidia потом (если сука захочет  сделает свою реализацию данного примитива . Я понимаю что ВСЕ случаи таким образом не охватить но это уже прибавит в скорости изрядно в 90% задач. ВСЕ узкоспециализированные задачи конечно не оптимизировать. Но во многих задачах даже научных используются более менее распространенные вещи которые как раз будут оптимизированы в первую очередь. API допутим открыт. И интерфейсы. А вот реализацию примитива открыть под железа ни одного производителя не заставить Но возможность добавлять свои примитивы. Но уж реализует их NVidia например или ATI или нет это уже их дело. тут можно только кошельком голосовать. заставить их нельзя.2Freeman драйвер современной видео карты напичкан оптимизацией а специфики железа при этом ты не знаешь. так что одно другому не мешает. А если на таком простом уровне непонятки то я собственно ничего доказывать не собираюсь. Я привел модель. Если утверждаете что явная ошибка укажите в чем. | ||
| Наверх | | ||
| Hmmm |
| ||
| ID пользователя #719 Зарегистрирован: Среда 09.08.2006 11:29Местонахождение: Москва Сообщений: 108 | Freeman написал(а) ... Hmmm написал(а) ... Поэтому выход по большому счету один - открытые API. Никакой осью эту проблему не решить. Хе! А чем тогда, если не ОСью? Я имел в виду API железок. Когда мне нужно покавыряться напрямую в каком нибудь девайсе я всегда могу написать дрова которые мне будут делать всю работу. Да и исходники оси у меня под рукой, если что - всегда можно даже ядро перековырять. Но хрена лысого у меня что выйдет если железо закрытое. Как на закрытых виндах люди со своими проблемами ковыряются я конечно не в курсе, там конечно вся надежда на мудрость microsoft. Кошмар, короче...  | ||
| Наверх | | ||
| Переход на страницу 1 2 [3] 4 ... 15 16 17 | |
Powered by e107 Forum System