Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну извините. Я же не работаю с указателями, не оперирую понятиями типа "адрес объекта", не удаляю объекты вручную.
Непринципиально.
ВВ> В CLI даже синтаксис разный:
Ну и что?
ВВ>Причем второй пример более высокоуровневый чем первый.
Ничуть. Уровень один и тот же.
ВВ>Угу. А за счет чего он может быть верифицирован?
За счет сознательного исключения возможностей, которые верифицировать не получается. При чем тут уровни? Вот, скажем, Сингулярити не может гарантировать верификацию для DMA, потому что аппаратура не позволяет его нужным образом контроллировать. Это, по твоему, означает, что механизм DMA более низкоуровневый, чем обращение к портам IO или отображение в адресное пространство?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
FR>>Нет проблема в том что в той же приставке всего 256 метров памяти, а игра требует гораздо большего объема
AVK>А мужики то не знают.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, FR, Вы писали:
FR>>Здравствуйте, gandjustas, Вы писали:
G>>>А можно работать напрямую с видеопамятью хоть где-нибудь под Windows? Ответ — нет. FR>>Ответ да. DirectDraw создаешь поверхность в видеопамяти и вперед. G>А причем тут 3d?
Утверждалось то что выделено, а это неправда.
G>>>Да и наибольшие тормоза в графических движках вызывает не отрисовка и текстутрирование (они уже давно выполняются на видеокарте), а отсечение невидимых поверхностей, расчет столкновений итп. FR>>Угу и часто эти алгоритмы требуют много памяти и оптимизации доступа к этой памяти с учетом кеша и т. п. что проще делать в средах без GC. G>Бред. Все эти оптимизации дадут максимум 20%, при этом оптимизация алгоритма может в разы увеличить скорость.
Я писал эти алгоритмы так что не надо теоретических ихвышлений, одна только оптиизация мапов под память у меня дала больше 50% выигрыша.
FR>>Для шейдеров не нужны и бесполезны более высокие уровни абстракций, слишком короткие и ограниченые "программы" они пока подерживают, и существующих сиобразных языков сейчас более чем достаточно. G>Ключевое слово "пока" — выделено. G>Уже сейчас есть возможность написать на F# код, который будет выполняться как на CPU, так и на видеокарте. В неуправляемой среде можно сделать такое?
Конечно какая разница управляемый код или нет, это ничем ни отличается от написания любого транслятора.
G>>>Не ждите появления завтра сумер-мега управляемого 3d-движка на .NET, большенство технологий которые нужны для написания движка еще "сырые", ни в одном большом проекте пока не будут использоваться. Также многие игростудии пока что испытывают страх перед управляемыми платформами в 3d движках.
FR>>Игростудии пишут сейчас игры в основном для приставок, а там до сих пор всего 256 (512 вместе с видео) метров памяти на борту. Кроме того большая часть приставок не контролируются ms и там NET еще долго не появится. G>Для большенства приставок и DirectX нету, там вообще другие "законы".
Здравствуйте, AndrewVK, Вы писали:
AVK>А мужики то не знают.
Кстати подобные игры без проблем пишутся на смеси питон (или луа) (80%) С++ (20%) сам работал
в этой отрасли.
Но для больших и не PC игр это уже не проходит. Те же питон и луа кстати в них тоже для скриптования
предпочтительней чем управляемые ява или шарп из-за легкого и полного контроля над выделением памяти.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, FR, Вы писали:
FR>>>Здравствуйте, gandjustas, Вы писали:
G>>>>А можно работать напрямую с видеопамятью хоть где-нибудь под Windows? Ответ — нет. FR>>>Ответ да. DirectDraw создаешь поверхность в видеопамяти и вперед. G>>А причем тут 3d?
FR>Утверждалось то что выделено, а это неправда.
В контексте разработки 3d движков очень даже правда.
Можете еще драйвера вспомнить.
G>>>>Да и наибольшие тормоза в графических движках вызывает не отрисовка и текстутрирование (они уже давно выполняются на видеокарте), а отсечение невидимых поверхностей, расчет столкновений итп. FR>>>Угу и часто эти алгоритмы требуют много памяти и оптимизации доступа к этой памяти с учетом кеша и т. п. что проще делать в средах без GC. G>>Бред. Все эти оптимизации дадут максимум 20%, при этом оптимизация алгоритма может в разы увеличить скорость.
FR> FR>Я писал эти алгоритмы так что не надо теоретических ихвышлений, одна только оптиизация мапов под память у меня дала больше 50% выигрыша.
Значит до этого алгоритм далеко неоптимальный был.
Я имел счатье один раз оптимизировать на ассемблере код, скомпилированный на C. При всех выкрустах удалось вытянуть только 20% процентов. Потом поменяли алгоритм и получили прирост в 2 с чем-то раза.
FR>>>Для шейдеров не нужны и бесполезны более высокие уровни абстракций, слишком короткие и ограниченые "программы" они пока подерживают, и существующих сиобразных языков сейчас более чем достаточно. G>>Ключевое слово "пока" — выделено. G>>Уже сейчас есть возможность написать на F# код, который будет выполняться как на CPU, так и на видеокарте. В неуправляемой среде можно сделать такое? FR>Конечно какая разница управляемый код или нет, это ничем ни отличается от написания любого транслятора.
Ну напишите транслятор С++ или его подмножества в язык шейдеров.
G>>>>Не ждите появления завтра сумер-мега управляемого 3d-движка на .NET, большенство технологий которые нужны для написания движка еще "сырые", ни в одном большом проекте пока не будут использоваться. Также многие игростудии пока что испытывают страх перед управляемыми платформами в 3d движках. FR>>>Игростудии пишут сейчас игры в основном для приставок, а там до сих пор всего 256 (512 вместе с видео) метров памяти на борту. Кроме того большая часть приставок не контролируются ms и там NET еще долго не появится. G>>Для большенства приставок и DirectX нету, там вообще другие "законы". FR>Угу, вот поэтому успеха NET там долго не будет.
Да, только "там" постоянно сокращается.
Здравствуйте, Aen Sidhe, Вы писали:
AS>В новом стандарте — лямбды. МС обещала в 2010 студии сделать их в С++. Ну я С++ не сильно интересуюсь — больше не вспомню.
Здравствуйте, gandjustas, Вы писали:
FR>>Утверждалось то что выделено, а это неправда. G>В контексте разработки 3d движков очень даже правда.
В этом контексте тоже неправда, доступ к видеопамяти без проблем доступен и из D3D
IDirect3DVertexBuffer9::Lock
G>Можете еще драйвера вспомнить.
При чем тут драйвера.
FR>> FR>>Я писал эти алгоритмы так что не надо теоретических ихвышлений, одна только оптиизация мапов под память у меня дала больше 50% выигрыша. G>Значит до этого алгоритм далеко неоптимальный был.
Тут уже выше был аналог моей ситуации суммирование массива по строкам и столбцам занимает разное время.
Алгоритм при этом не меняется. У меня менялись аллокоторы памяти и была сделана локализация доступа.
G>Я имел счатье один раз оптимизировать на ассемблере код, скомпилированный на C. При всех выкрустах удалось вытянуть только 20% процентов. Потом поменяли алгоритм и получили прирост в 2 с чем-то раза.
Алгоритм не всегда можно поменять.
G>>>Уже сейчас есть возможность написать на F# код, который будет выполняться как на CPU, так и на видеокарте. В неуправляемой среде можно сделать такое? FR>>Конечно какая разница управляемый код или нет, это ничем ни отличается от написания любого транслятора. G>Ну напишите транслятор С++ или его подмножества в язык шейдеров.
А зачем мне писать подмножество C++ на C++ может мне инетереснее подмножество Ocaml'ана этом же самом Ocaml'е.
И давай не виляй покажи преимущества именно управляемого кода в этом вопросе.
FR>>Угу, вот поэтому успеха NET там долго не будет. G>Да, только "там" постоянно сокращается.
Здравствуйте, AndrewVK, Вы писали:
AVK>За счет сознательного исключения возможностей, которые верифицировать не получается. При чем тут уровни? Вот, скажем, Сингулярити не может гарантировать верификацию для DMA, потому что аппаратура не позволяет его нужным образом контроллировать. Это, по твоему, означает, что механизм DMA более низкоуровневый, чем обращение к портам IO или отображение в адресное пространство?
На мой взгляд автоматическое управление памятью — это более высокий уровень по сравнению с прямой работой с указателями.
Здравствуйте, FR, Вы писали:
ВВ>>На боксе кстати 512, причем разделения на видео и не-видео нет. +10 МБ (кажется) кэш. FR>Угу. Только текстуры и другие видеоданные как раз и сожрут большую ее часть.
А как иначе-то? Это и к немногим игрушкам, написанным специально под PC, тоже относится. Текстурки-то там почетче будут.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>На мой взгляд автоматическое управление памятью — это более высокий уровень по сравнению с прямой работой с указателями.
Автоматическое управление памятью — это внешний механизм. Разумеется, работа с ним это более высокий уровень. Но это самое управление памятью никаким образом не имеет отношения к работе с видеопамятью. Просто параллельна ей. И никак не мешает. То, что в С++ одна и та же механика используется для того и другого, совсем не означает, что это идентичные вещи. По факту — для управления созданием/удалением объектов в куче механика есть, для работы с поверхностями DirectX механики нету. Просто нету. И не потому что абстракции при этом противопоказаны, а потому что никто не озаботился.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, FR, Вы писали:
AVK>>Даже один факт способен опровергнуть теорию.
FR>Какой теории?
проблема в том что в той же приставке всего 256 метров памяти, а игра требует гораздо большего объема и в таких условиях ручное управление на порядки эффективнее чем GC
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
FR>>Какой теории?
AVK>
проблема в том что в той же приставке всего 256 метров памяти, а игра требует гораздо большего объема и в таких условиях ручное управление на порядки эффективнее чем GC
Ты очень невнимательно читал, я выделил нужное.
В условиях нехватки памяти теория очень даже верна.
Здравствуйте, AndrewVK, Вы писали:
AVK>Автоматическое управление памятью — это внешний механизм. Разумеется, работа с ним это более высокий уровень. Но это самое управление памятью никаким образом не имеет отношения к работе с видеопамятью. Просто параллельна ей. И никак не мешает. То, что в С++ одна и та же механика используется для того и другого, совсем не означает, что это идентичные вещи. По факту — для управления созданием/удалением объектов в куче механика есть, для работы с поверхностями DirectX механики нету. Просто нету. И не потому что абстракции при этом противопоказаны, а потому что никто не озаботился.
Да дело даже не в видео-памяти. Если даже рассматривать только PC как платформу, то мне кажется сборка мусора может вносить довольно критический оверхед даже при работе с обычной ОЗУ. Памяти-то с одной стороны хоть и много, но с другой — ее постоянно не хватает. Игрушка спокойно может скушать гиг оперативы, и не только не подавится, но и еще попросит. Запаса-то особо не чувствуется. А память кончится — упремся в жесткий диск, и прощай производительность.
А теперь представим, что мы не только хотим написать движок на дотнете, но и сделать его более "абстрактным", упростить модификацию и добавление новых фич... Мне кажется, в таком случае выжать соки из железа совсем не получится.
А если взять приставки — то там вообще все тяжко. Железки-то по современным мерках уже не ахти какие, а ведь пользователи с каждой новой частью сериала закономерно ожидают каких-нибудь улучшений и новых красивостей. Это ж не PC, где мы добавили красивостей, задрали системные требования, пришили лейбл "best played on nvidia" — и шито крыто, заодно и железо продавать помогаем. С приставкой по определению приходится жить с тем, что есть.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А как иначе-то? Это и к немногим игрушкам, написанным специально под PC, тоже относится. Текстурки-то там почетче будут.
На PC все гораздо проще, объем доступной памяти намного больше, есть подкачка из виртуального файла для обычной памяти и отображение на системную для видео. В приставках же память очень даже ресурс. Вот тут http://www.dtf.ru/articles/print.php?id=4071 неплохо описана типичная работа с памятью в приставках.
Здравствуйте, FR, Вы писали:
FR>На PC все гораздо проще, объем доступной памяти намного больше, есть подкачка из виртуального файла для обычной памяти и отображение на системную для видео. В приставках же память очень даже ресурс. Вот тут http://www.dtf.ru/articles/print.php?id=4071 неплохо описана типичная работа с памятью в приставках.
Судя по тому же Кризису — память для PC это тоже ресурс. А подкачка из свопа == тормоза. Как и использование системной памяти вместо видео. Игра ведь это не слайдшоу
