Pull to refresh
9
0

Пользователь

Send message
sizeof(array<int,10>) >= sizeof(int[10])
Это классическая перестраховочное допущение. На практике я не вижу причины, почему не должно выполняться равенство. Или может у Вас они есть?
kozzztik
Ну, какбы, пишу я, bin и count. Никакой стандартной библиотеки, никаких импортов, в питоне это считай О(1).
Первая ссылка в гугле утверждает, что bin — это конвертация числа в строку с его двоичным представлением. Итого Ваше решение переводит число в строку (под которую надо еще память выделить), и в ней считает количество символов '0'. Надеюсь, не нужно объяснять почему это решение не является ни лучшим, ни эталонным, ни вообще адекватным.
С другой стороны, давать такой вопрос на собеседовании тоже странно, так как это не обычная задачка, к которой можно придумать хорошее решение за пару минут, тут его нужно знать (обычно подразумевается то которое (n & (n-1)), гуглится по «count bits in a number»). Хотя если кандидат напишет перебор бит, то можно проверить понимание битовой арифметики.
P. S. должно было быть ответом на коммент, промахнулся.
Я к тому, что если у нас 2 ядра (тоже «несколько»), то, кодируя кадры то на одном, то на другом, мы получим обратную пропускную способность 0.04 с, а это всего лишь 25 fps, не 30. Но с четырьмя — да, все в порядке.
Ну Вы лучше уточните это «несколько», а то ведь 2 ядра — это тоже несколько.
Сейчас бы сравнивать автора статьи с Линусом Торвальдсом.
Если Вы не в состоянии качественно решить простые алгоритмические задачи (а в статье все задачи простые) — то даже будучи гуру фреймворков Вы не сможете создать качественный продукт. Я не предлагаю зубрить весь литкод, но задачи на «пройдись по массиву» / «посортируй и пройдись по массиву» проблем вызывать не должны.
С другой стороны — позиция Яндекса в этой ситуации вызывает мягко говоря недоумение. Предлагать пройти весь этот ад из собеседований с однотипными задачами, что бы потом получить… 200К? Видимо, работать у них — большая честь.
Если Вы храните коллекцию с неиспользованными данными — это не утечка данных, это просто неоптимальный по памяти код. А вот если Вы объявляете коллекцию удаленной или теряете на нее все ссылки, не освободив при этом память — это называется утечкой, и в безопасном Rust'е это вроде как невозможно.
Эмм, а владение в 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 никогда даже не пытались достичь.
А в чем выражается удобство Metal'а?
Вопрос неверный. Правильно «нужно ли пингвина наследовать от птицы?». Ответ — зависит от ситуации.
Windows/VS 2019. Но я понял, в чем было дело — я не включил поддержку AVX2. С ней происходит векторизация внутреннего цикла изначального варианта, вызываются функции "__vdecl_sin4"/"__vdecl_cos4", которые видимо обрабатывают по 4 аргумента за раз, и тогда соотношение времени выполнения двух алгоритмов у меня примерно совпадает с Вашим. Но тут стоит заметить, что для оптимизированного алгоритма компилятор векторизацию не сделал (хотя unroll на 10 итераций сделать смог), если доделать ее — результат должен улучшиться.
Странные у Вас тайминги. Я не смог запустить Ваш ассемблер, но сварганил сравнение изначального C++ с оптимизированным — так у меня оптимизированный в 9 быстрее. Но точность — да, проседает, причем я даже не знаю почему, вроде бы вычисление тригонометрии должно быть менее точным чем сложения/умножения.
Вот код:
Тест
#include <stdio.h>
#include <stdlib.h>
#define _USE_MATH_DEFINES
#include <math.h>
#include <chrono>

void ht_cpp0(double* data, double* result, int n)
{
    double phi = 2.0 * M_PI / n;
    for (int i = 0; i < n; ++i)
    {
        double sum = 0.0;
        for (int j = 0; j < n; ++j)
        {
            double w = phi * i * j;
            sum += data[j] * (cos(w) + sin(w));
        }
        result[i] = sum / sqrt(n);
    }
}

void ht_cpp1(double* data, double* result, int n)
{
    double phi = 2.0 * M_PI / n;
    double cos_phi = cos(phi);
    double sin_phi = sin(phi);
    double sqrtn = 1 / sqrt(n);
    double sin_dw = 0.0;
    double cos_dw = 1.0;
    for (int i = 0; i < n; ++i)
    {
        double sin_w = 0.0;
        double cos_w = 1.0;
        double sum = 0.0;

        for (int j = 0; j < n; ++j)
        {
            sum += data[j] * (cos_w + sin_w);
            double new_cos_w = cos_w * cos_dw - sin_w * sin_dw;
            double new_sin_w = sin_w * cos_dw + cos_w * sin_dw;
            cos_w = new_cos_w;
            sin_w = new_sin_w;
        }

        result[i] = sum * sqrtn;
        double new_cos_dw = cos_dw * cos_phi - sin_dw * sin_phi;
        double new_sin_dw = sin_dw * cos_phi + cos_dw * sin_phi;
        cos_dw = new_cos_dw;
        sin_dw = new_sin_dw;
    }
}

double MeanSquaredError(double* data1, double* data2, int n)
{
    double sum = 0;
    for (int i = 0; i < n; i++)
    {
        double df = data1[i] - data2[i];
        sum += df * df;
    }
    return sqrt(sum);
}

int main()
{
    enum : int { data_length = 10000 };
    double data_src[data_length];
    for (int i = 0; i < data_length; i++)
        data_src[i] = i + 1;
    double data_in[data_length];
    double data_out[data_length];

    {
        auto t0 = std::chrono::high_resolution_clock::now();
        ht_cpp0(data_src, data_in, data_length);
        ht_cpp0(data_in, data_out, data_length);
        auto t1 = std::chrono::high_resolution_clock::now();
        std::chrono::duration<double> ms_double = t1 - t0;
        double err = MeanSquaredError(data_src, data_out, data_length);
        printf("cpp0 : %lf\terr : %1.10lf\n", ms_double, err);
    }

    {
        auto t0 = std::chrono::high_resolution_clock::now();
        ht_cpp1(data_src, data_in, data_length);
        ht_cpp1(data_in, data_out, data_length);
        auto t1 = std::chrono::high_resolution_clock::now();
        std::chrono::duration<double> ms_double = t1 - t0;
        double err = MeanSquaredError(data_src, data_out, data_length);
        printf("cpp1 : %lf\terr : %1.10lf\n", ms_double, err);
    }

    system("pause");
}
Она найдена в Интернете в сборнике эксплойтов. Ничто не говорит о том, что кто-то использовал конкретно Spectre, а не ворох других более опасных уязвимостей.
Ну и если что, в холиварах по унижению Intel'а такой аргумент не катит — уязвимость присутствует во всех процессорах со спекулятивным исполнением, включая Intel, AMD, ARM и другие.

Information

Rating
Does not participate
Registered
Activity