Войти
ПрограммированиеФорумОбщее

AngelScript (комментарии) (10 стр)

Страницы: 17 8 9 10 11 12 Следующая »
#135
11:02, 1 мар. 2012

Кстати, неплохо бы еще дописать в статью про модификатор + который добавляют к названию типа. Мол что тогда двигло само будет заниматься подсчетом ссылок для данной функции.


#136
14:06, 1 мар. 2012

UP
У AngelScript появился JIT компилятор https://github.com/BlindMindStudios/AngelScript-JIT-Compiler
интересно было бы посмотреть на сравнительные тесты производительность может ктонить сделать AngelScript vs Lua?
JIT использует С++11

#137
19:47, 1 мар. 2012

Chaos_Optima
> интересно было бы посмотреть на сравнительные тесты
+1

#138
20:32, 1 мар. 2012

Только про существование в луа ffi и статических типов не забудьте:)

Кстати арена существует довольно давно, луа неплохо выступает и без жит компилятора: http://shootout.alioth.debian.org/

#139
20:37, 1 мар. 2012

угу и желательно вот эти тесты
http://www.gamedev.ru/flame/forum/?id=11843&page=6
к слову сейчас потестил AS vs AS JIT
JIT версия в 6 раз быстрее в релизе

#140
21:00, 1 мар. 2012

Chaos_Optima
> угу и желательно вот эти тесты
Угу и тогда вызов функций движка через ffi. Это раз в 15 быстрее.

Хотя кого вообще это волнует... У меня например на луа весь цикл рендера написан, и не всякий полностью С++ движок способен обогнать луа хотя бы на пару %.

ЗЫ в тестах от DDMZ градус неадеквата просто фееричен. Чел явно не знает языка луа и кинулся писать для него тесты... Буэээ

#141
21:42, 1 мар. 2012

RPG
> ЗЫ в тестах от DDMZ градус неадеквата просто фееричен. Чел явно не знает языка
> луа и кинулся писать для него тесты... Буэээ
Напиши адекватные. Хотя тут мне кажется будет тоже самое, ты извернешся и напишешь тесты которые будут удачны для луа и неудачны для всего остального.
А вообще мерять миллисикунды бред-же, тут главное удобство.

#142
23:21, 1 мар. 2012

RPG
> Угу и тогда вызов функций движка через ffi. Это раз в 15 быстрее.
слова без доказательств тщетны.
RPG
> DDMZ градус неадеквата просто фееричен.
Почему? По моему его тесты вполне адекватные, в начале он делал тесты на производительность самого языка (5 стр), а потом он проделал тесты на взаимодействие скриптового языка и нэйтивного кода, что по моему мнению также очень важно. Например у меня архитектура движка построена таким образом что поля классов у меня напрямую проброшены в нэйтив, что делает работу скрипта практически прозрачной, поэтому тест на переменную доступную из С++ для меня крайне важен.
Также скрипты у меня привязываются к самим объектам, а если объектов много то и скорость вызова функции скрипта для меня тоже довольно важна.
по этим 2 параметрам AS намного обходит LUA в тех тестах. + особо критичные места по производительности я могу с минимальными изменениями перенести из скрипта в нэйтив что тоже даёт плюсы. Также AS это типизированный язык что лично для меня намного удобнее нежели динамическая типизация, да и синтаксис привычнее.

#143
0:56, 2 мар. 2012

Он сделал на луа две обертки для функции, которая делает инкремент переменной. Луа передаёт параметры по значению, а не по ссылке, странно вообще видеть такой тест. Для того, чтобы менять поля структур используйте методы, проброшенные в скрипты, вас блин вообще чему в школе учили? Первое правило ООП - менять структуру объекта только методами иначе получите хрен знает что работающее хрен знает как.
>у меня архитектура движка построена таким образом что поля классов у меня напрямую проброшены в нэйтив
Вот как раз об этом речь. В нормальных движках почему-то ни одна внутренняя структура не меняется "в лоб", для всего есть методы, которые задокументированы.
Другой тест стопицитмильон раз вызывает опять же пустую функцию с одним параметром. На практике за один кадр из движка от силы вызывается три сотни функций. Хотите в скрипте делать цикл по миллиону объектов, как тут один товарищ хотел в соседней теме сделать? Ну от такого и С++ загнётся.

Нужно делать сравнение на реальных движках а не гонять сферического коня в вакууме. То что AS вызывает функцию на 0.001 мс быстрее чем луа (что в 10 раз быстрее, чем луа) никак не скажется на производительности и наоборот. Посмотрите хотя бы скорость работы хэш-таблиц если они вообще там есть. Предлагаю желающим сравнить мой движок, полностью написанный на луа с AS или пусть даже С++ эквивалентом на какой-нить простой игре. Держу пари что при идентичных технологиях вы не сможете обогнать луа даже на пару процентов.

Мне правда всегда казалось что скриптовый язык создан для удобства а не для скорости. Считать столкновения галактик на луа... Ну в общем-то с его JIT-компилятором уже можно.

Chaos_Optima
> Также AS это типизированный язык что лично для меня намного удобнее нежели
> динамическая типизация, да и синтаксис привычнее.
Вот с этого надо начинать, а не искать оправдание в каких-то тестах производительности. Это дело десятое, если синтаксис привычнее - ну пиши всё на с++: и классы, и скорость, и синтаксис знакомый, статическая типизация есть. Вообще не понимаю зачем тогда вам скрипт. Скрипт как раз и должен сильно отличаться от С++, имо. Время компиляции сейчас можно уже не учитывать у меня здоровенная прога собирается секунд 30, а чахлый движок, сделанный на коленке и того быстрее.

Хотите скорость? Гуглите luajit ffi. Скорость работы простого цикла сравнима с С++, вызовы функций - тоже. Я тут фибоначчи на луа писал, так он си обгонял поначалу (если в компиляторе не указать оптимизацию).

3eR0.1ive
> Напиши адекватные. Хотя тут мне кажется будет тоже самое, ты извернешся и
> напишешь тесты которые будут удачны для луа и неудачны для всего остального.
Я не обладаю вредной привычкой лезть в ту область, в которой не разбираюсь, со своим уставом. Но и не могу пройти мимо бездарного слепого поливания луа грязью, да ещё и кривыми бенчмарками. Хороший язык, проблем с производительностью у него не было нет и не будет никогда. Всем её хватает. Стиль/типизация и т. п. - о вкусах спорить бесполезно. Я с РНР лет восемь проработал и динамические типы данных для меня не являются чем-то экстраординарным. А уж какой тормоз РНР - и ничего... Ничего плохого про AS ещё не сказал, а со мной уже куча народу спорит:-D

#144
1:23, 2 мар. 2012
rpg@rpg$ time ./lua_linux32 fib.lua 
9227465

real  0m1.148s
user  0m1.140s
sys  0m0.004s
rpg@rpg$ gcc fib.c
rpg@rpg$ time ./a.out 
9227465

real  0m1.501s
user  0m1.496s
sys  0m0.000s
fib.tar
Вот когдатошний тест луа на скорость. Хотя это конечно ничего не значит. В gcc пришлось оптимизатор отрубить - иначе он пустой цикл выкидывает.
#145
2:05, 2 мар. 2012

RPG
> ну пиши всё на с++
Зачем? вот смотри у меня есть редактор карт в нём есть редактор скриптов что позволяет мне писать скрипт и тут же его проверять. так что писать исключительно всё на ++ не удобно.
RPG
> Предлагаю желающим сравнить мой движок, полностью написанный на луа с AS или
> пусть даже С++ эквивалентом на какой-нить простой игре
с удовольствием сравню. к сожалению мой двиг пока не готов для написания чего либо но когда  доделаю до такого состояния с удовольствием посоревнуюсь в производительности.
RPG
> Первое правило ООП - менять структуру объекта только методами иначе получите
> хрен знает что работающее хрен знает как.
это не правило это всего лишь определение слова инкапсуляция.
RPG
> В нормальных движках почему-то ни одна внутренняя структура не меняется "в
> лоб", для всего есть методы, которые задокументированы.
ну ты наверно не понял что я хотел сказать. вот простой пример есть объект допустим плеер на этот объект вешается скрипт по управлению и внутри скрипта
делается примерно вот так.
Object.pos.x+=10.0f;
конечно можно и так
Object.pos.setPos(10,0,0);
так вот pos это базовая переменная которая прокинута из С++ в скрипт.(у меня архитектура основывает на так называемом Облаке данных имеется синглтон DataCloud с помощью которого и происходит расшаривание данных при этом при получении данных мы получаем защищённый и потокобезопасный указатель и обмен информацией в данном случае происходит прозрачно что обеспечивает наилучшую производительность + DataCloud уже умеет всё это сериализовать. первая версия оказалась правда неудачной и крайне неудобной но вот вторая верси оказалась настолько удобной что я переписал менеджер ресурсов под неё)), осталось дописать некоторые провайдеры этих данных в шейдеры, скрипты и нет, и можно будет уже что-то делать)
RPG
> Ну от такого и С++ загнётся.
Ну Unity оч даже хорошо справляется там такая же система, скрипт прикручивается к объекту.
RPG
> Вот когдатошний тест луа на скорость.
для студии под винду есть аналог? хочется всётаки сравнить

#146
2:56, 2 мар. 2012

Chaos_Optima
> У AngelScript появился JIT компилятор
> https://github.com/BlindMindStudios/AngelScript-JIT-Compiler
Вах, сущай, круто!

#147
5:36, 2 мар. 2012

Chaos_Optima
> это не правило это всего лишь определение слова инкапсуляция.
Правильно, это она из составных частей парадигмы ООП. Спрашивается если вы не используете парадигмы ООП, зачем вам вообще С++? А что тогда такое по-вашему парадигма? Отсутствие инкапсуляции, наследования и полиморфизма это уже чисто си. Хотя си не так уж плох:) Кстати с такими взглядами можно и задуматься...
Chaos_Optima
> конечно можно и так
> Object.pos.setPos(10,0,0);
обычно так и делают. Никогда не видел чтобы движок выплевывал свою внутренности в скрипт. Хотя в луа и так можно. И получаете накладные расходы только на передачу параметнов, кстати в луа именно из-за того что параметры передаются через стек с помощью внешней библиотеки это дело чутка подтормаживает. Удобство - плати. Есть ffi, который быстр но не позволяет так легко рулить аргументами - скорость. Я выбрал кстати второе:) Но не потому что скорость, а потому что движок был 100 килобайт, а теперь 20.

Chaos_Optima
> для студии под винду есть аналог? хочется всётаки сравнить
под винду для луа я кинул ехешник. А под винду из сей сами собирайте, тем более собирать нечего. Запускать lua_win.exe fib.lua. Используйте PowerShell честно сворованный майкрософтом у юникса:) Но хорошо что в винде тоже осознали в необходимости хорошего терминала.

Chaos_Optima
> с удовольствием сравню. к сожалению мой двиг пока не готов для написания чего
> либо но когда  доделаю до такого состояния с удовольствием посоревнуюсь в
> производительности.
У меня 2D так что достаточно чего-то простенького. Например, есть Match3 в две сотни строк. Или просто что-то, что двигает объекты по экрану. Я просто это к тому что 99.9% времени процессора тратится на графику и движок, а не на скрипты. И у меня на луа в движке написано вообще всё, вплоть до сценического графа (двиг только тяжелые функции выполняет - графику рисует).

На луа я свой выбор остановил из-за существования lQuery. ПО сути это компактный аналог JavaScript. А jQuery очень классная штука: http://jquery.com/
Вот такой мощный инструмент можно получить в графическом движке. Очень легко писать систему событий и вообще игры. Прототип-ориентированное программирование сильно отличается от классического, но мне, как человеку веба, эти понятия знакомы давно.

#148
9:39, 2 мар. 2012

RPG
> Хороший язык, проблем с производительностью у него не было нет и не будет
> никогда. Всем её хватает.
Безспорно, тут чисто дело вкуса. Но если я не ошибаюсь, кто-то с той стороны баррикад заговорил первым про скорость.

#149
15:25, 2 мар. 2012

RPG
> Спрашивается если вы не используете парадигмы ООП, зачем вам вообще С++?
эм. то есть если не следуешь строго парадигме программирования то всё язык можно не использовать? и причём тут С++? у меня всё инкапсулировано в двиге
RPG
> Отсутствие инкапсуляции, наследования и полиморфизма это уже чисто си. Хотя си
> не так уж плох:)
а кто говорит что я это нарушаю? то что ты используешь ООП ещё не значит что абсолютно ко всем полям ты должен обращаться исключительно через методы.
надо подходить ко всему с умом и понимать где можно раскрывать данные а где нет.
RPG
> Никогда не видел чтобы движок выплевывал свою внутренности в скрипт
а кто говорит про внутренности двига?
RPG
> И получаете накладные расходы только на передачу параметнов
ну в AS если использовать Object.pos.x+=10.0f; оверхеда вообще не будет
RPG
> Есть ffi
насколько я понял это что-то вроде статической типизации для языка так?
RPG
> У меня 2D так что достаточно чего-то простенького.
хм а у меня всё заточено под 3D. а 2D двиг и 3D различаются как небо и земля.
RPG
> Я просто это к тому что 99.9% времени процессора тратится на графику
эм на графику процессорное время вообще не должно тратится т.к. обрабатываться должна на видюхе.

RPG
> Вот такой мощный инструмент можно получить в графическом движке.
эм jQuery? а разве он не предназначен для быстрого доступа к элементам HTML?  зачем он в игровом двиге то?

Страницы: 17 8 9 10 11 12 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.