Открыт исходный код физического движка MuJoCo

классно

// Про код

Проект написан на C/C++

Весь движок-то src/engine/ у них на голой сишке. Причём код всё равно содержит эмуляцию классов, а также что-то типа RAII

// advance simulation in two phases: before input is set by user
void mj_step1(const mjModel* m, mjData* d) {
  TM_START;
  mj_checkPos(m, d);
  mj_checkVel(m, d);
  mj_fwdPosition(m, d);
  mj_sensorPos(m, d);
  mj_energyPos(m, d);
  mj_fwdVelocity(m, d);
  mj_sensorVel(m, d);
  mj_energyVel(m, d);
  if (mjcb_control) {
    mjcb_control(m, d);
  }
  TM_END(mjTIMER_STEP);
}

  // local space
  mjtNum* vec = mj_stackAlloc(d, nv);
  int* vec_ind = (int*) mj_stackAlloc(d, nv);

  // clear update counter
  ctx->nupdate = 0;

  ...

  mjFREESTACK;

Получается, даже гуглята не умеют писать на C++ или им запрещают... byko3y

// Про перф

оптимизирован для максимальной производительности

О какой производительности идёт речь, если у них боттлнек в GIL, о чём они сами и пишут?

Performance As a C library with no dynamic memory allocation, MuJoCo is very fast. Unfortunately, raw physics speed has historically been hindered by Python wrappers, which made batched, multi-threaded operations non-performant due to the presence of the Global Interpreter Lock (GIL) and non-compiled code. In our roadmap below, we address this issue going forward.

Ведь всем известно, что избавиться от динамических аллокаций — это главное в ускорении физической симуляции (нет).

Ну ладно, видимо изначально стояла цель не написать что-то эффективное, а по-быстрому сбацать PoC для дёрганья из питона и всякой машинки. А когда они поняли, что их поделка адово тормозит из-за того же самого питона, код великодушно подарили сообществу. Прикольно 🙂

Пишу сюда потому как оригинал грохнули, вот прямо на глазах.

ЛОР в первую очередь ценен своим сообществом.

Не могу не согласиться.

Аватарка каждого - месседж всем остальным, читающим его посты

Дык, а сыр бор то о чём? У меня вот не было аватарки, и в обозримом будущем не предвидится. И чего? Не в аватарках счастье ;)

wiki: Одна из целей использования аватара, которую преследует часть пользователей, — отразить какие-либо специфические черты характера пользователя и помочь создать достаточно точное впечатление у собеседников о его внутреннем духовном мире и статусе (этому же служит и т. н. никнейм). Также проявляется желание пользователя украсить свой профиль. Аватар является желательным (но не обязательным) атрибутом участника веб-форумов

Если сообщество ЛОР более не может себе позволить такую роскошь - это печально, но не смертельно. А срач про аватарки я завёл, чтобы подсветить эту проблему.

Кстати, в контексте темы HPC, премодерация (аватарок, сообщений), которую тут некоторые предлагали, это как раз что-то типа GIL... Убивает нормальное взаимодействие в сообществе, а следовательно снижает его эффективность 😉

Очень часто бывает что в компании решения принимаются не программистами, либо теми из них, кто выше по служебной лестнице, но ниже по интеллекту. Я когда фрилансил с этим часто сталкивался. Я им говорю: проще сжать и перевести в jpeg картинки на сервере заранее, а не в момент запроса. Мне: «нет, там 80 терабайт - это всё сжать нереально и хранить сжатое негде». Дык сжатое же займёт всего 5% места? Нет и всё…

Или другой случай: работал над оконным менеджером для Линукса, где заказчик хотел чтобы окна можно было плавно «приближать и удалять» как видеокамерой без аппаратного ускорения (OpenGL, например). Это при том что все элементы оконного интерфейса заказчик требовал сделать в SVG. То есть, на каждый фрейм полноэкранной анимации, надо было делать растеризацию всех окон при максимальном удалении). Особенно трудно бывает, когда заказчик платит деньги, а над тобой ещё своего программиста ставит, который деньги не платит, но «настойчиво советует» как лучше сделать…

Ну а по большому счёту да: писать на Си только чтобы избежать ООП - это бред, конечно. Можно и на Си++ писать без ООП. Ну или с минимальным ООП в некритических местах. Я так и делаю, в принципе… Зато на Си++ отличная поддержка многопоточности. Никто не заставляет выделять память динамически: используй свои структуры, без контейнеров STL и всё. Делов-то! Кстати, и обратное тоже верно: на Си ещё как можно в стиле ООП писать, как это делается в GTK.