Ну, какбы, пишу я, bin и count. Никакой стандартной библиотеки, никаких импортов, в питоне это считай О(1).
Первая ссылка в гугле утверждает, что bin — это конвертация числа в строку с его двоичным представлением. Итого Ваше решение переводит число в строку (под которую надо еще память выделить), и в ней считает количество символов '0'. Надеюсь, не нужно объяснять почему это решение не является ни лучшим, ни эталонным, ни вообще адекватным.
С другой стороны, давать такой вопрос на собеседовании тоже странно, так как это не обычная задачка, к которой можно придумать хорошее решение за пару минут, тут его нужно знать (обычно подразумевается то которое (n & (n-1)), гуглится по «count bits in a number»). Хотя если кандидат напишет перебор бит, то можно проверить понимание битовой арифметики.
P. S. должно было быть ответом на коммент, промахнулся.
Я к тому, что если у нас 2 ядра (тоже «несколько»), то, кодируя кадры то на одном, то на другом, мы получим обратную пропускную способность 0.04 с, а это всего лишь 25 fps, не 30. Но с четырьмя — да, все в порядке.
Если Вы не в состоянии качественно решить простые алгоритмические задачи (а в статье все задачи простые) — то даже будучи гуру фреймворков Вы не сможете создать качественный продукт. Я не предлагаю зубрить весь литкод, но задачи на «пройдись по массиву» / «посортируй и пройдись по массиву» проблем вызывать не должны.
С другой стороны — позиция Яндекса в этой ситуации вызывает мягко говоря недоумение. Предлагать пройти весь этот ад из собеседований с однотипными задачами, что бы потом получить… 200К? Видимо, работать у них — большая честь.
Если Вы храните коллекцию с неиспользованными данными — это не утечка данных, это просто неоптимальный по памяти код. А вот если Вы объявляете коллекцию удаленной или теряете на нее все ссылки, не освободив при этом память — это называется утечкой, и в безопасном Rust'е это вроде как невозможно.
Просто для справки, эти push/pop предназначены не для передачи аргументов, а для сохранения состояния тех регистров общего назначения, которые функция обязана сохранять согласно calling convention.
А я, в свою очередь, должен поверить слову Вашей девушки, переданному Вами по испорченному телефону? :)
Самое интересное то, что ведь ролик нисколько не противоречит этому Вашему исследованию. Ему и незачем противоречить, ведь из одинаковой способности к математике мальчиков и девочек в целом не следует, что в числе тех, кто станет профессиональным математиком, мужчин и женщин также будет равное количество. Правда, не следует только в рассуждениях настоящих ученых, целью которых является объективное исследование, а не пропихивание желаемых тез.
Ну Вы как бы тоже привязались к своей статье, написанной теми, кто в области биологии, психологии или социологии не специализируется вообще, а ролик, в котором человек, имеющий такую экспертизу, рассказывает где культура, а где физиология — Вашего внимания не достоин.
Иметь общий код между cpu и gpu очень полезно для акселерации.
Общий код можно худо-бедно, но иметь и на GLSL/HLSL. Непонятно, что именно из {C++ \ C} нужно (кроме шаблонов).
Я понял, удобство — зло.
Ведь можно врапперов наделать на все случаи жизни =)
Или взять уже готовые, интересно, почему Вы эту часть комментария проигнорировали. Суть в том, что с Vulkan'ом у меня выбор больше, чем с Metal'ом.
Под TBDR железо ваш код нормально работает?
Надо будет — будет нормально работать. Кстати, у Apple тут действительно все хорошо — мне нравится идея Tile Shader'ов, хотя кажется, что можно было бы и по-гибче; вангую их скорое появление в Vulkan'е. Только вот этот дизайн не очень согласуется с Вашей логикой — зачем пользователю морока с рендерпассами?
MSL основан на C++, что уже само по себе ставит его на уровень выше HLSL/GLSL.
Мне на GPU только этого «уровня выше» не хватало. Сейчас побегу выделять регистры на хранение таблиц виртуальных функций классов. Из C++ в языках шейдеров разве что шаблоны нужны.
Ага, и hello triangle в 1000 строк =)
И в каждой из 1000 строк содержится полезная для драйвера и GPU информация. Ну и да, вы профессионально разрабатываете hello world'ы, или мы о серьезных приложениях говорим?
Если для вас компактный код Metal является менее удобным чем полотнища Vulkan-кода, то могу только посетовать что у каждого свои тараканы в голове.
Во-первых, если Вы пишете простыни explicit Vulkan-кода вместо реализации и использования врапперов под Ваш конкретный случай — то на счет тараканов я с Вами согласен.
Во-вторых, Vulkan разрабатывался как API, минимизирующее неявные операции в драйвере. И кроме многословности, это также означает, что программист имеет значительно больше контроля над происходящим и может оптимизировать под свой случай те вещи, который в Metal'е реализованы втупую в драйвере. Вот например цитата из статьи:
still uses a traditional resource model where each resource has certain “usage flags” it has been created with but does not require pipeline barriers or layout transitions, and a traditional binding model where each shader stage has several slots you can freely assign resources to.
То есть, если я правильно понял, нормальных барьеров и таблиц дескрипторов в наличии нет.
А если все эти возможности не нужны, и заморачиваться не хочется — берите публичные врапперы, их полно, или вообще что-то вроде DX11onVk/GLonVk используйте, получите точно такой же компактный код. Возможно даже найдется враппер, мимикрирующий под Metal.
Очевидно кроссплатформенность присутствует.
Она присутствует настолько, насколько позволяет Apple, ведь набор железа и ОС, на которых Metal будет запускаться, полностью ими контролируется. Область применения Vulkan'а, очевидно, намного шире.
Статья о том, как после OpenGL ES все что угодно будет облегчением. Написано даже:
If you come from Direct3D or console world, you may take every single one of these for granted
Кстати, Vulkan в статье тоже упоминается — как технология, способствовавшая появлению полезных тулзов, которые Apple создать не удосужилась, так как это не способствует продвижению их вендорлокнутой проприетарщины.
На Вулкане писал, и большинство его сложностей вызваны кроссплатформенностью. То есть тем, чего в Apple никогда даже не пытались достичь.
Windows/VS 2019. Но я понял, в чем было дело — я не включил поддержку AVX2. С ней происходит векторизация внутреннего цикла изначального варианта, вызываются функции "__vdecl_sin4"/"__vdecl_cos4", которые видимо обрабатывают по 4 аргумента за раз, и тогда соотношение времени выполнения двух алгоритмов у меня примерно совпадает с Вашим. Но тут стоит заметить, что для оптимизированного алгоритма компилятор векторизацию не сделал (хотя unroll на 10 итераций сделать смог), если доделать ее — результат должен улучшиться.
Странные у Вас тайминги. Я не смог запустить Ваш ассемблер, но сварганил сравнение изначального C++ с оптимизированным — так у меня оптимизированный в 9 быстрее. Но точность — да, проседает, причем я даже не знаю почему, вроде бы вычисление тригонометрии должно быть менее точным чем сложения/умножения.
Вот код:
Она найдена в Интернете в сборнике эксплойтов. Ничто не говорит о том, что кто-то использовал конкретно Spectre, а не ворох других более опасных уязвимостей.
Ну и если что, в холиварах по унижению Intel'а такой аргумент не катит — уязвимость присутствует во всех процессорах со спекулятивным исполнением, включая Intel, AMD, ARM и другие.
Первая ссылка в гугле утверждает, что bin — это конвертация числа в строку с его двоичным представлением. Итого Ваше решение переводит число в строку (под которую надо еще память выделить), и в ней считает количество символов '0'. Надеюсь, не нужно объяснять почему это решение не является ни лучшим, ни эталонным, ни вообще адекватным.
С другой стороны, давать такой вопрос на собеседовании тоже странно, так как это не обычная задачка, к которой можно придумать хорошее решение за пару минут, тут его нужно знать (обычно подразумевается то которое (n & (n-1)), гуглится по «count bits in a number»). Хотя если кандидат напишет перебор бит, то можно проверить понимание битовой арифметики.
P. S. должно было быть ответом на коммент, промахнулся.
С другой стороны — позиция Яндекса в этой ситуации вызывает мягко говоря недоумение. Предлагать пройти весь этот ад из собеседований с однотипными задачами, что бы потом получить… 200К? Видимо, работать у них — большая честь.
Самое интересное то, что ведь ролик нисколько не противоречит этому Вашему исследованию. Ему и незачем противоречить, ведь из одинаковой способности к математике мальчиков и девочек в целом не следует, что в числе тех, кто станет профессиональным математиком, мужчин и женщин также будет равное количество. Правда, не следует только в рассуждениях настоящих ученых, целью которых является объективное исследование, а не пропихивание желаемых тез.
Или взять уже готовые, интересно, почему Вы эту часть комментария проигнорировали. Суть в том, что с Vulkan'ом у меня выбор больше, чем с Metal'ом.
Надо будет — будет нормально работать. Кстати, у Apple тут действительно все хорошо — мне нравится идея Tile Shader'ов, хотя кажется, что можно было бы и по-гибче; вангую их скорое появление в Vulkan'е. Только вот этот дизайн не очень согласуется с Вашей логикой — зачем пользователю морока с рендерпассами?
И в каждой из 1000 строк содержится полезная для драйвера и GPU информация. Ну и да, вы профессионально разрабатываете hello world'ы, или мы о серьезных приложениях говорим?
Во-первых, если Вы пишете простыни explicit Vulkan-кода вместо реализации и использования врапперов под Ваш конкретный случай — то на счет тараканов я с Вами согласен.
Во-вторых, Vulkan разрабатывался как API, минимизирующее неявные операции в драйвере. И кроме многословности, это также означает, что программист имеет значительно больше контроля над происходящим и может оптимизировать под свой случай те вещи, который в Metal'е реализованы втупую в драйвере. Вот например цитата из статьи:
То есть, если я правильно понял, нормальных барьеров и таблиц дескрипторов в наличии нет.
А если все эти возможности не нужны, и заморачиваться не хочется — берите публичные врапперы, их полно, или вообще что-то вроде DX11onVk/GLonVk используйте, получите точно такой же компактный код. Возможно даже найдется враппер, мимикрирующий под Metal.
Она присутствует настолько, насколько позволяет Apple, ведь набор железа и ОС, на которых Metal будет запускаться, полностью ими контролируется. Область применения Vulkan'а, очевидно, намного шире.
Кстати, Vulkan в статье тоже упоминается — как технология, способствовавшая появлению полезных тулзов, которые Apple создать не удосужилась, так как это не способствует продвижению их вендорлокнутой проприетарщины.
На Вулкане писал, и большинство его сложностей вызваны кроссплатформенностью. То есть тем, чего в Apple никогда даже не пытались достичь.
Вот код:
Ну и если что, в холиварах по унижению Intel'а такой аргумент не катит — уязвимость присутствует во всех процессорах со спекулятивным исполнением, включая Intel, AMD, ARM и другие.