Извините, ничего не найдено.

mr.DIMAS · 27.02.2015, 20:49

Давно на булке не было хорошего срача по поводу двух родственных языков. Пора его начать.

Уже как месяц, в перерывах между рисованием моделек и карт для своей игры, пишу говношутер на чистом си. Что могу по этому поводу сказать:
1) Почувствовал себя полным нубом в программировании когда у меня отняли stl с его std::vector и std::map. Пришлось писать свои велики, проходя по граблям снова и снова.
2) Компиляция просто офигенно быстрая, сейчас проект размером 250 кб кода компилируется mingw за 5 сек, для сравнения при смене компилятора на g++( то есть си++ компилятор ) тот же проект компилируется за 23 секунды.
3) Размер кода тоже меньше раза в 3 (тут скорее линкуется рантайм c++ в экзешник, поэтому такая разница)
4) Производительность практически одинаковая( разница 1-3%) при тех же ключах оптимизатора. Но производительность неоптимизированных версий различается на 10-15%. Причем си обходит си++.
5) Так как некоторые куски кода я брал из движка своей игры, то при портировании их на си, удалось серьезно их оптимизировать.
6) Наследование сменилось композицией, в некоторых местах оно даже удобнее наследования.
7) При программинге на си стал больше уделять внимания структуре игры\движка.

В итоге не могу сказать что си прям очень сильно понравился, но он избавляет от гемора с наследованием и прочей ООП мишурой.

Кароче let the срач begins!

Knightmare · 27.02.2015, 22:31

Ну чот попытка совсем никакая.

гемора с наследованием и прочей ООП мишурой.

Конкретнее.

Samodelkin · 27.02.2015, 23:46

Про С++ что-либо конкретное сказать сложно, так как язык очень разносторонний.

Я считаю тут дело не в языке, а в том как на нём программировать. С++ так устроен что подразумевает набор конкретных методик и подходов для конкретного проекта, и в случае игр или движков эти методики часто не совпадают с теми которые написаны в книгах по введению в С++. Однако у программиста может сложиться стереотип что программировать надо так как учили с детства (как в этих книгах). Хотя например в Data Oriented Design подходе вообще подвергается критике большинство ООП методик к программированию. При этом подходы DOD удачно ложатся как на С так и на С++. Только в случае С меньше выбора и программист возможно своими усилиями может прийти к тем же выводам самостоятельно. А вот например есть интересная концепция pure function, которая формально относится к функциональным языкам (не путать с процедурными) таким как Haskell, однако эту штуку можно воспроизвести на С/С++ (ключом компилятора или эксплуатировав правило не использовать глобальные переменные и делая метод static'ом). А ещё есть варианты как на С можно программировать ООП подходом. Так что можно сделать вывод что эти языки не являются строго процедурными в случае С или строго ООП в случае С++ -- они достаточно гибкие чтобы программировать используя множество разнообразных подходов и техник.

Так что в случае с mr.DIMAS'ом мне кажется что С из-за своих некоторых ограничений просто дал задуматься о таких вещах, которые на С++ мы часто делаем по привычке. Однако теперь ничто не мешает код получившийся на С перенести на С++ и он останется таким же эффективным, потому что эффективность в данном случае обуславливается подходом, а не языком.

Так что если спорить, то о том какие подходы программирования лучше использовать для создания игр/игровых движков, а язык уж как нибудь подстроится (или нет -- тогда просто выбираем другой язык).

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

Что касается меня то я планирую некоторые куски кода С++ попробовать переписать на С. Но это скорее эксперимент, чтобы удостовериться в некоторых деталях связанных с синтаксисом. В целом С++ более строгий язык по части типов и как следствие более надежный в этом плане.

mr.DIMAS · 28.02.2015, 00:58

Еще сишечка заставляет вспоминать простые алгоритмы типа сортировки массивов\списков( вот только не надо напоминать про qsort ), что позволяет прокачать "скилл" перед собеседованием - у наших работодателей трешовые вопросы на собеседованиях, поэтому приходится такую ерунду вспоминать и задрачивать перед тестом.

А ещё есть варианты как на С можно программировать ООП подходом

http://www.cs.rit.edu/~ats/books/ooc.pdf - оно?

Таких извращений я давно не видел.

Хотя у себя в говношутере использую следующий подход

typedef struct entity_s {
    vec3_t localPosition;
    vec3_t localScale;
    quat_t localRotation;
    mat4_t globalTransform;
    mat4_t localTransform;
    mat4_t invBindTransform;
    struct entity_s * parent;
    list_t surfaces;
    list_t childs;
    char skinned;
    char name[64];
    char propBuffer[512];
    list_t keyFrames;
    int totalFrames;
    anim_t * anim;
    char visible;
    char animated;
    char globalTransformCalculated;
    float depthHack;
    /* components */
    camera_t * camera;
    light_t * light;
    body_t * body;
    struct entity_s *instanceOf;
} entity_t;

extern list_t g_entities;

entity_t * Entity_Create( void );
entity_t * Entity_CreateInstance( entity_t * source );
void Entity_GetLookVector( entity_t * ent, vec3_t * look );
void Entity_GetRightVector( entity_t * ent, vec3_t * right );
void Entity_GetUpVector( entity_t * ent, vec3_t * up );
void Entity_GetGlobalPosition( entity_t * ent, vec3_t * absPos );
void Entity_Free( entity_t * ent );

....

и т.д

что в общем-то немного напоминает ооп

Что касается меня то я планирую некоторые куски кода С++ попробовать переписать на С

То есть прямо на C89\C99 написать и компилировать именно этим сишным компилятором? Что за код? Из рейкастинга что-то?

Samodelkin · 28.02.2015, 01:35

Сообщение от mr.DIMAS

Еще сишечка заставляет вспоминать простые алгоритмы типа сортировки массивов\списков( вот только не надо напоминать про qsort ), что позволяет прокачать "скилл" перед собеседованием - у наших работодателей трешовые вопросы на собеседованиях, поэтому приходится такую ерунду вспоминать и задрачивать перед тестом.

Возможно совпадение, но как раз на этой недели я реализовывал данных алгоритм сортировки. Дело в том что вариант из с++std требует использовать итераторы, а qsort из cstd я посчитал старым и не стал разбирать в принципе (хорошее оправдание). У меня есть класс для работы с биллбоардами (это в движке рейкастинга), это вещь похожая на спрайты и их требуется сортировать по дальности от камеры чтобы в дальнейшем правильно подавать в пайплайн с альфаблендингом, и вот элементы quicksort'а я интегрировал прямо в этот класс. Однако нужно ли это требовать как необходимое знание если в этом можно разобраться в течении дня по мере необходимости?

http://www.cs.rit.edu/~ats/books/ooc.pdf - оно?

Таких извращений я давно не видел.

ООП в целом != реализации ООП в C++. Речь идёт скорее о частичных реализациях ООП подходов, как у тебя или как в OpenGL где есть набор функций и есть индексы/дескрипторы объектов, которые передаешь в функцию, как некоторой аналог указателя this который неявно передаётся первым аргументом в методах C++ согласно соглашению о вызовах thiscall.

То есть прямо на C89\C99 написать и компилировать именно этим сишным компилятором? Что за код? Из рейкастинга что-то?

Скорее С11 -- там есть несколько важных улучшений касательно современных требований железа (например реализация многопоточности). Я решил попробовать такой эксперимент после того как узнал о DOD подходе, а он базируется как раз на принципах зависимости от железа, поэтому чем лучше язык оперирует данными в контексте железа (это не значит что он должен быть более низкоуровневый, скорее низкоуровневость некоторое следствие, которое не всегда удаётся побороть) тем успешнее можно реализовать данные подходы.
Ну например математическая библиотека вполне очевидное место которое можно попробовать написать на С. То есть такой же быстрый код можно написать и на С++ но С даст тоже самое с более простым синтаксисом, вот об этом я и говорю. Например если я на С++ хочу сделать POD структуры и функции для их работы, то мне нужно следовать некоторым правилам чтобы структура была POD (для надёжности добавить проверку через std::is_pod, делать методы static, добавлять noexcept для исключения проверок на перехваты (это кстати визуал студии не касается -- там исключения отличаются от стандарта) и прочие штуки, в то время как С по другому делать и не умеет, и всё что я напишу будет так как мне нужно без утяжеления синтаксиса. Поэтому как я сказал это эксперимент касается синтаксиса, читабельности кода, а не каких то методов синтеза более оптимального или быстрого бинарного кода, по идее он должен быть одинаковый, за исключением каких то деталей, зависящих от компиляторов.

mr.DIMAS · 28.02.2015, 01:52

Ну например математическая библиотека вполне очевидное место которое можно попробовать написать на С

По началу у меня была дикая попоболь от сишной математики( то бишь без операторов )

typedef struct {
    float x;
    float y;
    float z;
} vec3_t;

void Vector3_Zero( vec3_t * v );
void Vector3_Set( vec3_t * v, float x, float y, float z );
void Vector3_Add( vec3_t * out, const vec3_t * a, const vec3_t * b );
void Vector3_Subtract( vec3_t * out, const vec3_t * a, const vec3_t * b );
void Vector3_Negate( vec3_t * out, const vec3_t * a );
void Vector3_Multiply( vec3_t * out, const vec3_t * a, const vec3_t * b );
void Vector3_Divide( vec3_t * out, const vec3_t * a, const vec3_t * b );
void Vector3_Cross( vec3_t * out, const vec3_t * a, const vec3_t * b );
float Vector3_Dot( const vec3_t * a, const vec3_t * b );
float Vector3_Normalize( vec3_t * out, const vec3_t * a );
float Vector3_Length( const vec3_t * a );
float Vector3_SqrLength( const vec3_t * a );
void Vector3_Lerp( vec3_t * out, const vec3_t * a, const vec3_t * b, float t );
void Vector3_Scale( vec3_t * out, const vec3_t * a, float scale );
void Vector3_Copy( vec3_t * out, const vec3_t * a );
float Vector3_Angle( const vec3_t * a, const vec3_t * b );
void Vector3_Swap( vec3_t * a, vec3_t * b );
float Vector3_SqrDistance( const vec3_t * a, const vec3_t * b );
void Vector3_Middle( vec3_t * out, const vec3_t * a, const vec3_t * b );
void Vector3_Min( vec3_t * out, const vec3_t * a, const vec3_t * b );
void Vector3_Max( vec3_t * out, const vec3_t * a, const vec3_t * b );

Обычное сложение векторов a = b + c превращается в

vec3_t a,b,c;
Vector3_Set( &b, 1, 2, 3 );
Vector3_Set( &c, 3, 4, 5 );
Vector3_Add( &c, &b, &c );

Но после того как написал физику для игры( а там сплошные вектора кругом ), стало привычно. Кстати напоминает математику из D3DX.

Samodelkin · 28.02.2015, 02:37

Да есть выбор, либо пользуешься классами и перегрузкой операторов и получаешь мало буков, либо пишешь в си-стайл и в варианте на с++ получаешь даже более длинные тексты чем в си.

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

Причина почему в d3dx использовали такой подход я думаю кроется в том числе в намерении сделать библиотеки совместимые со множеством разных нативных языков. Не думаю что думать о таких вещах правильно когда цель gapi вычислять графику как можно быстрее. В dx11 они вроде сосредоточились исключительно на с++11 (из нативных языков, а так конечно вездесущий шарп там есть тоже).

Вообще если вернуться к вопросу оптимизации то твоя структура не очень правильно написана:

typedef struct entity_s {
    vec3_t localPosition;
    vec3_t localScale;
    quat_t localRotation;
    mat4_t globalTransform;
    mat4_t localTransform;
    mat4_t invBindTransform;
    struct entity_s * parent;
    list_t surfaces;
    list_t childs;
    char skinned;
    char name[64];
    char propBuffer[512];
    list_t keyFrames;
    int totalFrames;
    anim_t * anim;
    char visible;
    char animated;
    char globalTransformCalculated;
    float depthHack;
    /* components */
    camera_t * camera;
    light_t * light;
    body_t * body;
    struct entity_s *instanceOf;
} entity_t;

Например такие толстые вещи как name[ 64 ] и propBuffer[ 512 ] нужно убирать вниз, потому что следом за ними идут более тонкие и нужные поля, а префетчер начинает тратить время на чтение этих толстых массивов и не подготавливает вовремя нужные данные в кеш.
Ещё лучше делить такие большие структуры на "горячие" и "холодные" части. Предположим что первые три поля используются очень часто (каждый кадр или чаще), а другие реже, по мере трансформации объекта или запроса на изменение (ну тут ты сам лучше знаешь что и когда у тебя используется). Поэтому данные лучше распределить по двум структурам.

// Первая:
typedef struct {
    vec3_t localPosition;
    vec3_t localScale;
    quat_t localRotation;
} entityHot_t;

// Вторая:
typedef struct {
    // Всё остальное.
} entityCold_t;

Теперь множество этих структур будет расположено двумя массивами так:

entityHot_t hotEntities[ number ];
entityCold_t coldEntities[ number ];

Такое размещение называется Structure Of Arrays (SOA). В случае большой структуры как у тебя это Array Of Structs (AOS).
Обход первого массива (hotEntities) займет гораздо меньше времени, потому что потребуется прокешировать гораздо меньше данных чем во втором случае.

Возможно в языках с таким синтаксисом это не очень удобно, или же потребуется что-то придумать с макросами или обёртками. Но я видел более "заточенные" для игр языки где это решалось вот так:

struct entity_t {
    vec3_t SOA pos; // hot part
    char SOA name[ 512 ];
};

// Теперь когда делаем массив ентити:
entity_t entities[ 1024 ];

Компилятор видит метки SOA и размещает данные в памяти так что сначала идёт массив из 1024 векторов, а затем массив из массивов чаров. Таким образом горячая часть остается компактной на уровне железа, а программист видит абстракцию и продолжает работать со структурой как единым целым.

Nerd · 28.02.2015, 02:44

Кстати, какие под Си есть макросы кроме cmacro?

mr.DIMAS · 28.02.2015, 12:11

Кстати в твоём примере показана интересная особенность языка С -- из за отсутствия inline такие короткие функции могут стать причиной частых кеш-промахов и большого оверхеда на сам вызов функций.

Вроде есть жи inline
http://www.greenend.org.uk/rjk/tech/inline.html

Например такие толстые вещи как name[ 64 ] и propBuffer[ 512 ] нужно убирать вниз,

Эти куски кода ждут своего ̶п̶р̶и̶н̶ц̶а̶ велосипеда в виде строк. То есть там будет указатель вместо толстоты

Igor · 28.02.2015, 13:47

Мне кажется, кое-кто не учитывает такой фактор, как время разработки. Да, можно писать офигенно быстрые штуки на Си, велосипедить списки, сортировки и прочее. Но нафига? Писать, сравнивать производительность, искать ошибки. Придётся расстаться либо с надёжностью, либо со временем, которое уйдёт на тестирование.

Обычное сложение векторов a = b + c превращается в
vec3_t a,b,c; Vector3_Set( &b, 1, 2, 3 ); Vector3_Set( &c, 3, 4, 5 ); Vector3_Add( &c, &b, &c );
Но после того как написал физику для игры( а там сплошные вектора кругом ), стало привычно. Кстати напоминает математику из D3DX.

Опять же, когда есть готовый алгоритм, подобный код писать можно.
Но если алгоритм разрабатывать "на ходу", пробовать менять различные его части, сравнивать точность вычислений и прочее, то код вида a = b+c намного проще для изменений и поиска ошибок.
Кстати, одна ошибка уже есть: в твоём примере c = b+c.

Кроме того, не раскрыта тема высокоуровневых оптимизаций. В С++ или java я могу в несколько строчек заменить, например, реализацию списка с ArrayList на LinkedList и этим повлиять на производительность.
Значительная часть потерь скорости зависит не от константы времени выполнения, а от ассимптотики - судя по моему опыту, возможность легко и быстро писать/изменять код даёт намного больший бонус, чем мелкие локальные оптимизации.

Кроме того, всякие локальные оптимизации есть смысл использовать только в "бутылочном горлышке", в остальных случаях можно забить и не тратить своё время.

mr.DIMAS · 28.02.2015, 14:03

Придётся расстаться либо с надёжностью, либо со временем, которое уйдёт на тестирование.

Когда пишешь для себя, то на все это можно забить, другое дело на работе.

Да, можно писать офигенно быстрые штуки на Си, велосипедить списки, сортировки и прочее. Но нафига?

Скажи это линуксоидам

, или разрабам gcc, или даже freetype

Igor · 28.02.2015, 14:12

Когда пишешь для себя, то на все это можно забить,

Нет. Если какой-то алгоритм работает неправильно, я буду искать ошибки в самом алгоритме, а не в реализациях сортировок и прочего - это тоже экономия времени.
P.S. Когда делал свою реализацию матриц, ради интереса написал к ней тесты - поймал несколько ошибок и ещё как минимум одну не поймал.

Samodelkin · 28.02.2015, 16:54

Сообщение от Igor

Кроме того, всякие локальные оптимизации есть смысл использовать только в "бутылочном горлышке", в остальных случаях можно забить и не тратить своё время.

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

Сообщение от Igor

Мне кажется, кое-кто не учитывает такой фактор, как время разработки. Да, можно писать офигенно быстрые штуки на Си, велосипедить списки, сортировки и прочее. Но нафига? Писать, сравнивать производительность, искать ошибки. Придётся расстаться либо с надёжностью, либо со временем, которое уйдёт на тестирование.

Можно поспорить. DOD даёт лучшее понимание структуры кода, как следствие лучше отлаживается и быстрее разрабатывается (за счёт гибкости). Потому что мы отходим от концепции объектов как в ООП и оперируем этапами трансформации данных из одного состояния в другое, а это (имхо) для таких вещей как движки и игры подходит лучше, где почти всё состоит из пайплайнов. Возможно ООП для других задач подходит больше, я бы даже сказал что в тех же движках на более высоких уровнях, когда проектируешь интерфейсы для пользователя можно оперировать именно ООП.

И потом одна важная вещь: разработка кода это не весь процесс разработки, иногда в перспективе лучше один раз хорошо поработать над движком, на котором затем можно выпустить целую серию игр без больших проблем, что в целом сэкономит время.

Сообщение от Igor

Кроме того, не раскрыта тема высокоуровневых оптимизаций. В С++ или java я могу в несколько строчек заменить, например, реализацию списка с ArrayList на LinkedList и этим повлиять на производительность.
Значительная часть потерь скорости зависит не от константы времени выполнения, а от ассимптотики - судя по моему опыту, возможность легко и быстро писать/изменять код даёт намного больший бонус, чем мелкие локальные оптимизации.

Ну тема о низкоуровневых аспектах. Так то конечно чем выше -- тем больше возможностей. Начинают с архитектуры движка/приложения. Но даже наверху уже надо задуматься о том чтобы удачно легло на железо. Например при ООП концепции об этом редко думают и в итоге не остается места для более низкоуровневых оптимизации. В DOD думают над этим и получившийся код ложиться на железо как надо. Низкоуровневые оптимизации и ассемблирование это самый бек-энд всего процесса оптимизации, но он будет невозможен если с самого начала пойдешь по неверному пути. Даже автоматическая оптимизация сработает намного лучше если всё правильно подготовишь для неё.

ABTOMAT · 01.03.2015, 23:10

[fatmode=ON]

Смысл этого топика "Я хочу в 10 раз больше писать кода, который в 20 раз сложнее обслуживать ради 0.05% улучшения производительности" ?

[/fatmode]

Igor · 02.03.2015, 00:34

ссылочка на хабр
Вот пример - ошибку в сортировке timsort нашли только тогда, когда попытались математически доказать корректность алгоритма. И то, нашли только сейчас, и некорректная реализация оказалась в Android SDK, Oracle JDK и OpenJDK.
Принципы работы сортировок, списков, деревьев знать надо, но писать их самому "просто потому что могу" не стоит.