Кодерский уголок

nop, дадите ссылку тогда, хорошо?
А то по нашим местным тестам на векторизацию, Clang пока проигрывает GCC в производительности.

 

hidefromkgb, Steel Rat, напишу, пожалуй, короткое резюме тут.
Суть теста была простейшая. Сгенерено штук 30 версий кода обмена двух половинок 32-битного числа и еще до кучи несколько функций обмена байтов в 32 и 16-битном слове. 39 всего. Речи о simd, автовекторизации и разворачивании циклов не шло вообще и были приняты меры во избежание активации данных фич. Весь код бенчмаркался через RDTSC и анализировался в Interactive Disassembler.
Только умница clang сумел упростить буквально все версии до одной инструкции. GCC упростил почти все, но сам код цикла бенчмарка, содержащего эту инструкцию, сгенерил менее эффективный, чем три других компилятора. ICC сократил треть, но сгенерил наиболее эффективный цикл из пяти инструкций для тех, с которыми справился. Цикл этот на i7 Haswell выполнялся ровно за такт на итерацию. MSVC правильно сократил лишь четверть, причем ICC и MSVC тупили на разном коде. Но несколько однотактовых циклов сгенерил и он.
К сожалению, Linux тестировался на другой машине, с процессором на Westmere, т.к. в Virtualbox RDTSC толком не работает. Все варианты цикла у clang там отработали за 2 такта на итерацию, но зато он справился и с теми, которые у Intel работали за 16. clang признан победителем из за огромного отрыва(в разы) по суммарному времени. Ну и, когда цикл будет развернут, преимущество Intel испарится полностью.
Вывод: clang умнее всех справился с упрощением выражений. ICC - лучше всех в микрооптимизациях под intel-архитектуру, но высокоуровневая оптимизация не годится clang в подметки и даже от GCC отстает.

 

nop, ну а параметры сборки, оптимизации и всё такое?
У меня вот GCC обычно медленнее, но совсем не потому что медленнее, а потому что я на нём лишь тестирую сборку на предмет компиляции в posix среде. Т.е. ничего не настраиваю, только включаю все ворнинги. Поэтому неудивительно, что у него программа работает медленнее, чем сборка релиза под виндой с включенной оптимизацией.
clang вообще в глаза не видел.

 

Steel Rat, ну ты, конечно, думаешь, что озаботившись множеством вещей, что перечислил выше и настроив (забыл упомянуть) еще и кросскомпиляцию 32 и 64-битных версий, забыл написать хотя бы -O3? в wintel же выставлена в студии полная оптимизация с предпочтением быстрого кода и все флажки, имеющие отношение к скорости, кроме автовекторизации. Разрешено самые последние наборы команд, вплоть до того, что Ida отказывается дизассемблировать некоторые фрагменты clang-овского бинарника.

 

2 All: есть маленькая, но дурацкая сверхзадачка.
Имеется стереозапись, в ней по центру - речь, а по всей стереобазе намазано музыки и шумов. Надо речь оставить, а всё остальное по возможности удалить или хотя бы прилично ослабить. Простейший навскидку алгоритм - для каждого канала перегнать отсчёты в частоты (преобразование фурье), взять для каждой частоты минимальное значение из двух каналов, перегнать обратно в отсчёты; это оставит центр стереобазы неизменным, крайние точки задавит начисто, промежуточные - пропорционально расстоянию от центра. (Вариант: частоты, отличающиеся на больше чем сколько-то процентов, вообще обнулять нафиг, - тогда останется только узкий сектор по центру, но могут пропадать куски речи просто потому что совпали по частоте с проснувшимя в углу стереобазы саксофоном. :-( )
Более радикальный вариант: перегнать отсчёты в частоты сразу для обоих каналов как комплексные числа; выбросить частоты, у которых "фи" не вписывается в определённый диапазон углов; перегнать обратно в отсчёты. (Кстати, играми с допустимым диапазоном углов можно реализовать и минусовку.)
Кто может такое напрограммить? Я увы - ни с fftw в частности, ни с БПФ вообще, ни с комплексными числами настолько плотно не дружу. :-(
Или, возможно, есть уже готовые проги такого рода и я ломлюсь в открытую дверь?

 

Рыжий Тигра, сразу скажу, сам не делал. Но задача в общем случае ИМХО простого решения не имеет. И даже решения средней сложности А программ, которые просто пользуются тем, что речь обычно занимает строго центр и имеет ограниченную полосу частот, по моему, навалом.

 

Есть такое. Но они даже минусовку качественную слепить не могут. :-( А интересно копнуть как раз в частотную область - хотя бы по соображениям физиологии, т.к. у нашего слуха - частотная природа: улитка - детектор-резонатор на несколько десятков тысяч узких частотных полос, ушные раковины - резонаторы, характеристики коих зависят от направления прихода звука в сагиттальной плоскости...

 

Пришлось попрограммироваться с 16-сегментным ЖК-индикатором, вот таким:



Сочинил к нему шрифт с кириллицей. Делюсь, вдруг кому понадобится - в игре имитировать ЖК-индикатор или ещё под что:



Для цифр специально скопировал начертания с 7-сегментного индикатора, чтобы быстрее узнавались. :-)
Буквы "Ё" и "Ў" не влезают хоть тресни. :-( "№", "$", "*", "=", буквы "Б", "Д", "Й" и особенно "Ц", "Щ", "Ї" на себя не очень похожи, но догадаться можно.

PS:



:-)))))

 

Если что, вот довольно простая реализация прямого БПФ, написанная мной пару лет назад: раскрыть

Код:

#define NO_EXT_KEYS

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <math.h>

#define LOGSIZE 10
#define RELFREQ 6.5

#define SIZE (1<<LOGSIZE)
#define PW2(x) (1<<(x))

typedef struct {
    double real, imag;
} complex;

complex cmake(double real, double imaginary)
{
    complex c;
    c.real = real; c.imag = imaginary;
    return c;
}
complex csum(complex x, complex y) {return cmake(x.real + y.real, x.imag + y.imag);}
complex cmul(complex x, complex y)
{
     return cmake(x.real*y.real - x.imag*y.imag, x.real*y.imag + x.imag*y.real);
}
complex cexp(complex x)
{
   return cmul(
        cmake(exp(x.real), 0),
        cmake(cos(x.imag), sin(x.imag))
   );
}
double carg(complex x) {return sqrt(x.real*x.real + x.imag*x.imag);}
complex cinv(complex x) {return cmake(-x.real, -x.imag);}


double array[SIZE];
double array2[SIZE];
double *arr = &array, *arr2 = &array2;

complex W[SIZE];

complex result[SIZE];
complex result2[SIZE];
complex *res = &result, *res2 = &result2;
    

int main()
{
    int i, s, n;
    double *t;
    complex *r;

    for (i = 0; i < SIZE; i++) {
        arr[i] = sin(2*M_PI*i / SIZE * RELFREQ);
        printf("%f \n", arr[i]);
    }
    printf("\n");

    
    
    for (s = LOGSIZE; s > 1; s--) {    //разбиение прореживанием по времени
        for (i = 0; i < SIZE; i++)
            arr2[PW2(s-1) * ((i&1) + (i>>s)) + i/2] = arr[i];
        t = arr; arr = arr2; arr2 = t;
    }
    
    for (i = 0; i < SIZE; i++) {           //перенесение в комплексный массив
        result[i] = cmake(arr[i], 0);
    }
    for (i = 0; i < SIZE/2; i++) {         //вычисление поворотных коэффициентов
        W[i] = cexp(cmake(0, -2*M_PI * i / SIZE));
        W[i+SIZE/2] = cinv(W[i]);
    }

    for (s = 1; s <= LOGSIZE; s++) {   //"бабочка"
        for (i = 0; i < SIZE; i++) {
            n = (i % PW2(s-1)) + ((i>>s)<<s);
            res2[i] = csum(
                    res[n],
                    cmul(res[n + PW2(s-1)], W[(i % PW2(s)) << LOGSIZE >> s])
            );
        }
        r = res; res = res2; res2 = r;
    }
 
    for (i = 0; i < SIZE; i++)
       printf("%f\n", carg(res[i]));
    printf("\n");
        
    return 0;
}

. Обратного, к сожалению, нет, но он там вроде как-то почти так же делается, не помню уже.

 

Просто оставлю это здесь - http://www.bromeon.ch/articles/raii.html

 

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

 

Ээээ, дык RAII - это и оно есть?!

У тебя часто ошибки в деструкторе вызванном delete?

 

Ну да.

Александреску вот тут жаловался, например: http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758
(раздел "Solution 3: The Real Approach" )

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

 

А я вот хочу пожаловаться на Александреску, это из-за него на свет появилось исчадие ада именуемое бустом.

RAII - не панацея, да. А наговнокодить с простыми указателями можно ваще миллионом способов.

Я не заставляю, а ваще речь о C++ и не использовать, в С++, конструктор и деструктор - это прямой путь к Победе над Системой! =)
Давай прекратим этот бесполезный спор? Меня вот в статье по этой ссылке тоже обозвали всячески (я, панимаешь, считаю, что это личное дело программиста), но не спорю с автором, а сюда ссылку кинул ибо написано толково.

 

Согласен, статья хорошая.

 

Экспериментировал с созданием кроссплатформенного приложения (пока только Windows/Android), в результате появилось компактная C++ либа, позволяющая писать, собственно, приложения. Я не делал упор на 2D/3D, либа только создаёт контекст от OpenGL (ES) 2.0 и до OpenGL 4.5. А уж как контекст будет использован - на усмотрение пользователя. Сейчас она могёт:

• создание окна
• обработка основных событий
• создание графического контекста
• примитивная поддержка спрайтов (это в сильно черновом виде)

В общем, исходники нужны? Для начинающих на Андроиде NDK - это ваще подарок, а не либа. =)

 

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

 

@Bato-San, твой ответ не засчитывается.

 

Други, есть фрагмент в исходниках уважаемой зарубежной конторы:

const char *idCompiler:рunctuation[] = {
"+=", "-=", "*=", "/=", "%=", "&=", "|=", "++", "--",
"&&", "||", "<=", ">=", "==", "!=", "::", ";", ",",
"~", "!", "*", "/", "%", "(", ")", "-", "+",
"=", "[", "]", ".", "<", ">" , "&", "|", ":", NULL
};
...
const char **ptr;
...

Но при компиляции выдает ошибку C2440: значение типа const char*[37] нельзя присвоить char ** в следующей строке:

for( ptr = punctuation; *ptr != NULL; ptr++ )

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

Как устранить ошибку?

 

@Kristobal Hozevich Hunta, const char **ptr; -> char **ptr;