Здравствуйте, FR, Вы писали:
FR>Полно и не read only, например динамическое заполнение вершиных и индексных буферов, по довольно замороченному алгоритму и со скоростью близкой к пропускной способности ОЗУ. И вообще общение с 3D API практически очень близко к системному программированию. Мне кажется писать именно 3D движек на функциональном языке (даже на ocaml) будет намного сложнее чем на C/C++.
Так стресс-тест и есть стресс-тест. Работа с полной отдачей. Я не специалист по 3d движкам, но насколько я понимаю, 3d engine — это, в основном, геометрия и оптимизация (по памяти, нагрузке на процессор и нагрузке на ускоритель). Т.е. масса нетривиальных алгоритмов. Самое то для проверки возможности языка, претендующего на универсальность.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Здравствуйте, FR, Вы писали:
FR>>Полно и не read only, например динамическое заполнение вершиных и индексных буферов, по довольно замороченному алгоритму и со скоростью близкой к пропускной способности ОЗУ. И вообще общение с 3D API практически очень близко к системному программированию. Мне кажется писать именно 3D движек на функциональном языке (даже на ocaml) будет намного сложнее чем на C/C++.
INT>Так стресс-тест и есть стресс-тест. Работа с полной отдачей. Я не специалист по 3d движкам, но насколько я понимаю, 3d engine — это, в основном, геометрия и оптимизация (по памяти, нагрузке на процессор и нагрузке на ускоритель). Т.е. масса нетривиальных алгоритмов. Самое то для проверки возможности языка, претендующего на универсальность.
Я согласен, что это не плохой стресс тест, но объем работы слишком большой. Например типичный современный движок на С++(Ogre, Nebula 2) это 5 — 7 Mb кода.
И я не уверен что переписывание такого движка например на ocaml, существенно уменьшит его объем и сделает более простым использование.
Просто многие функциональные фишки например та же ленивость и неупорядоченность вызовов могут только помешать в системе где как раз требуется жестко выстроенные по времени вызовы.
Здравствуйте, FR, Вы писали:
FR>Я согласен, что это не плохой стресс тест, но объем работы слишком большой. Например типичный современный движок на С++(Ogre, Nebula 2) это 5 — 7 Mb кода.
Типичный современный — да. Но во-первых, движок — понятие растяжимое... Голый OpenGL — тоже, в некотором роде движок. Остальное нужно только чтобы иметь одновременно и приличную картинку и приличный FPS
FR>И я не уверен что переписывание такого движка например на ocaml, существенно уменьшит его объем и сделает более простым использование.
Вот и интересно бы было проверить
FR>Просто многие функциональные фишки например та же ленивость и неупорядоченность вызовов могут только помешать в системе где как раз требуется жестко выстроенные по времени вызовы.
Уже не раз говорилось, что не стоит смешивать вычисление и управление. Чисто функциональная программа может выполнять только вычисления. Управление на основе этих вычислений осуществляет всегда некоторая императивная надстройка.
Такая схема может вызывает проблемы в действительно реал-тайм системах, где требуется очень быстрая реакция.
Большая часть движка, все-таки, вычисления (например, значения и порядка вершинных и текстурных координат), а не управление.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Здравствуйте, FR, Вы писали:
FR>>Я согласен, что это не плохой стресс тест, но объем работы слишком большой. Например типичный современный движок на С++(Ogre, Nebula 2) это 5 — 7 Mb кода. INT>Типичный современный — да. Но во-первых, движок — понятие растяжимое... Голый OpenGL — тоже, в некотором роде движок. Остальное нужно только чтобы иметь одновременно и приличную картинку и приличный FPS
Даже (вернее особенно) не голый, а со всеми расширениями OpenGL сейчас уже не движок а скорее прямой интерфейс к аппаратуре. Если же брать DirectX в pure режиме, то это вообще тончайшая прослойка к драйверу.
FR>>И я не уверен что переписывание такого движка например на ocaml, существенно уменьшит его объем и сделает более простым использование. INT>Вот и интересно бы было проверить
интерес может в человеко-годы вылится
FR>>Просто многие функциональные фишки например та же ленивость и неупорядоченность вызовов могут только помешать в системе где как раз требуется жестко выстроенные по времени вызовы. INT>Уже не раз говорилось, что не стоит смешивать вычисление и управление. Чисто функциональная программа может выполнять только вычисления. Управление на основе этих вычислений осуществляет всегда некоторая императивная надстройка.
Так тут как раз может получится что прослойка сильно толще основного кода.
INT>Такая схема может вызывает проблемы в действительно реал-тайм системах, где требуется очень быстрая реакция.
так основное применение 3D движков игры, которые достаточно (насколько это возможно на не real-time OS) близки к real-time.
INT>Большая часть движка, все-таки, вычисления (например, значения и порядка вершинных и текстурных координат), а не управление.
Я же говорю алгоритмы сильно специализированны и императивны по большей части.
Здравствуйте, Sinclair, Вы писали:
S>Кстати, если верно то, что я понял об функциональных языках, то на них можно писать совершенно замечательный гуй. Только нужно отвлечься от этих дурацких Button1.Width=71.
Это называется ООП.
S>По идее, если придумать удачное описание гуя, то всякий докинг и прочее должно очень изящно получаться. При помощи функций высшего порядка
А это называется XAML.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, faulx, Вы писали:
VD>>Так же многие тут предлагали создать более близкий к жизник пример. А то примеры уж больно оторваны от жизни. Например, интересно было бы поглядеть на то как будет выглядеть динамическая веб-страничка на одном из ФЯ.
F>Это не подойдет? Если верить тому, что написано здесь, это то, что нужно.
Неоткрывается.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, faulx, Вы писали:
VD>Не думаю, что кто-то из здесь присуствующих способен создать подбный пример. Да и вряд ли его можно будет легко понять. Ведь как не крути это будет огромный объем кода.
VD>Но как пример того, что такие проекты возможны и есть было бы неплохо заполучить ссылку на подобное приложение
>Это не подойдет? Erlang.
На самом деле не открывается эта ссылка. У тебя она пустая.
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, faulx, Вы писали:
VD>>Не думаю, что кто-то из здесь присуствующих способен создать подбный пример. Да и вряд ли его можно будет легко понять. Ведь как не крути это будет огромный объем кода.
VD>>Но как пример того, что такие проекты возможны и есть было бы неплохо заполучить ссылку на подобное приложение
>>Это не подойдет? Erlang.
Q>На самом деле не открывается эта ссылка. У тебя она пустая.
Здравствуйте, faulx, Вы писали:
F>>>Это не подойдет? Если верить тому, что написано здесь, это то, что нужно.
VD>>Неоткрывается.
F>Странно, у меня все работает.
Открылось. Но там же ничего скачать нельзя.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, faulx, Вы писали:
F>Здравствуйте, VladD2, Вы писали:
INT>>>Имху, реальным стресс-тестом для любого языка общего назначения может быть серьезная real-time 3d графика и/или физика...
VD>>Не думаю, что кто-то из здесь присуствующих способен создать подбный пример. Да и вряд ли его можно будет легко понять. Ведь как не крути это будет огромный объем кода.
VD>>Но как пример того, что такие проекты возможны и есть было бы неплохо заполучить ссылку на подобное приложение
F>Это не подойдет? Erlang.
Поправил-бы ты ссылочку , а то зело смешно (http://Это/)
F>Вроде видел и другие ссылки, но они менее серьезные.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, faulx, Вы писали:
F>>Борюсь с тэгами, и они пока побеждают. Я имел в виду Wings. Впрочем, в 3D-графике я не специалист, может, это и не то.
FR>Не то, это просто редактор 3D моделей.
В любом случае неважно, Erlang не подходит для таких задач. Будет слишком медленно, и никаких плюсов взамен.
, но насколько я понимаю, 3d engine — это, в основном, геометрия и оптимизация (по памяти, нагрузке на процессор и нагрузке на ускоритель). Т.е. масса нетривиальных алгоритмов. Самое то для проверки возможности языка, претендующего на универсальность.
