Не согласен. Их как раз много где нужно решать (да практически везде найдётся что-то, что можно/нужно сделать эффективнее и лучше), но вот позволить себе ими пользоваться могут очень немногие. В т.ч. и из-за нетехнологичности даваемых результатов.
Потому что это Академия, а не Продакшен. У них задача — придумать новый метод, опробовать его и показать возможности и потенциальные бенефиты. Для этого мегаразмеров в задачах не нужно.
«Можно делать» не значит «нужно делать». 3D печать ещё очень дорогое удовольствие и будет таковым скорее всего ещё долго. Поэтому проста и дешевизна тех.процесса — почти всегда и везде очень важны.
Тут наверное имеется ввиду в одном линейном направлении, то бишь 32768*32768 ~ 1млрд элементов.
Нет, думаю, что моя оценка верна. Столь большие модели они не пробовали делать, это довольно ясно следует из статьи и сопроводительного файла примеров.
Не стоит говорить за весь андроид. Причин, почему тормозит может быть триллион и во многих из них ФФ может быть явно не виноват. ФФ у меня даже на старом Galaxy S4, забитым под завязку, работал хорошо, не говоря уж о новом U12+…
Ой какие знакомые грабельки)
Остаётся только со всем согласиться. И ещё предложить добавить трик, учитывающий проблему ссылок и strict-aliasing: если так сложилось, что в performance critical код приходит переменная (особенно POD) по ссылке, то имеет смысл сделать временную служебную переменную по значению, в которую сразу загрузить то, что было по ссылке, и использовать её. Тогда мы обезопасим себя от бесконечных загрузок значения из памяти через ссылку. Наблюдал в таких условиях десятикратные приросты скорости.
Не спроста стараются передавать POD переменные по значению, но во первых, бывает legacy, а во вторых, — тип может быть под шаблоном, который не всегда развернётся в POD.
Нет, думаю, что моя оценка верна. Столь большие модели они не пробовали делать, это довольно ясно следует из статьи и сопроводительного файла примеров.
Остаётся только со всем согласиться. И ещё предложить добавить трик, учитывающий проблему ссылок и strict-aliasing: если так сложилось, что в performance critical код приходит переменная (особенно POD) по ссылке, то имеет смысл сделать временную служебную переменную по значению, в которую сразу загрузить то, что было по ссылке, и использовать её. Тогда мы обезопасим себя от бесконечных загрузок значения из памяти через ссылку. Наблюдал в таких условиях десятикратные приросты скорости.
Не спроста стараются передавать POD переменные по значению, но во первых, бывает legacy, а во вторых, — тип может быть под шаблоном, который не всегда развернётся в POD.