LINUX.ORG.RU

Тупой вопрос про кеш цпу


2

1

Здорово, мужики. Ща я расскажу вам небольшую предысторию.

Я пишу программку — простенький рендерер для множества вокселей в пространстве. Над множеством вокселей я строю вспомогательную структуру — дерево, где у узла 8 дочерних узлов, а в листьях хранятся данные (т.е., непосредственно воксели). Извините, мальчики, я плохо владею терминологией, но вроде это называется октодеревья. Далее у меня есть функция поиска пересечения луча и вокселя в множестве, такого, чтобы оно было ближайшим к точке, из который луч исходит.

Далее, сам рендерер может быть такой:

1) Для каждого пикселя на экране пускаем луч, который обходит это дерево с корня до листов, и, если есть пересечение, ставим точку на экран (я использую SDL и пишу в surface->pixels)

2) Подмечаем, что для близких лучей (мало отклоняющихся) путь от корня дерева до листа с данными почти одинаков (например root->a->b->c->d и root->a->b->c->e) и начинаем поиск с листа, возвращаесь, если надо, к корню.

И вот вопрос: для второго случая надо записывать в surface->pixels элементы не один за другим, как в таком коде:

int i,j;
int p = 0;
for (i=0; i<surface->w; i++)
{
    for (j=0; j<surface->h; j++)
    {
        *((Uint32*)surface->pixels+p) = calc_color();
        p++;
    }
}

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

int i,j,k,l;
for (i=0; i<surface->w/SQUARE_LEN; i+=SQUARE_LEN)
{
    for (j=0; j<surface->h/SQUARE_LEN; j+=SQUARE_LEN)
    {
        for (k=0; k<SQUARE_LEN; k++)
       {
            for (l=0; l<SQUARE_LEN; l++)
           {
                *((Uint32*)surface->pixels+(i+k)*width+j+l) = calc_color();
            }
        }
    }
}

Сильно ли это скажется на производительности из-за промахов в кеше? Или какие варианты могут быть, чтобы локальность и в смысле обхода дерева (в двухмерном пространстве) сохранить, и в смысле записи в pixels.

Мальчики, выручайте, ога?



Последнее исправление: Vikusya (всего исправлений: 1)

Ну размер pixels таков: 800x600 точек, каждая 32 бита

Vikusya
() автор топика

Толсто.

anonymous
()

Святая толстота...

TDrive ★★★★★
()

Сильно ли это скажется на производительности из-за промахов в кеше?

На каком процессоре?

Ты сначала напиши, чтобы хоть как-нибудь код работал, а потом уж думай о кэше, если профайлер скажет, что в этом участке затык.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Кстати, если попробуешь собрать, скажи, пожалуйста, всё ли собирается. Собирать cmake'ом, там написано как, но если что:

mkdir mybuild && cd mybuild && cmake -DCMAKE_BUILD_TYPE=RELEASE .. && make && ./src/simple-renderer/test_renderer skull

Vikusya
() автор топика

храните пиксели в квадродереве. Но вообще говоря пикселей же мало, так что в первом приближении можно не париться

AIv ★★★★★
()
Ответ на: комментарий от Vikusya
$ valgrind ./test_renderer skull
==21674== Memcheck, a memory error detector
==21674== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==21674== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==21674== Command: ./test_renderer skull
==21674== 
This is my simple renderer version 0.5
Building tree (1194419 voxels, 6 depth) took 26.013870
Tree balanceness 0.857143
==21674== 
==21674== Process terminating with default action of signal 5 (SIGTRAP)
==21674==    at 0x7FEFFFDA5: ???
==21674==    by 0x530A2D2: msort_with_tmp.part.0 (msort.c:105)
==21674==    by 0x530A5AB: qsort_r (msort.c:45)
==21674==    by 0x50CC699: vox_ray_tree_intersection (in /tmp/voxvision-master/build/src/voxtrees/libvoxtrees.so)
==21674==    by 0x50CC70F: vox_ray_tree_intersection (in /tmp/voxvision-master/build/src/voxtrees/libvoxtrees.so)
==21674==    by 0x50CC70F: vox_ray_tree_intersection (in /tmp/voxvision-master/build/src/voxtrees/libvoxtrees.so)
==21674==    by 0x50CC70F: vox_ray_tree_intersection (in /tmp/voxvision-master/build/src/voxtrees/libvoxtrees.so)
==21674==    by 0x50CC70F: vox_ray_tree_intersection (in /tmp/voxvision-master/build/src/voxtrees/libvoxtrees.so)
==21674==    by 0x4014DF: render (in /tmp/voxvision-master/build/src/simple-renderer/test_renderer)
==21674==    by 0x400F9C: main (in /tmp/voxvision-master/build/src/simple-renderer/test_renderer)
==21674== 
==21674== HEAP SUMMARY:
==21674==     in use at exit: 80,449,114 bytes in 712,290 blocks
==21674==   total heap usage: 724,856 allocs, 12,566 frees, 82,451,039 bytes allocated
==21674== 
==21674== LEAK SUMMARY:
==21674==    definitely lost: 16 bytes in 1 blocks
==21674==    indirectly lost: 176 bytes in 4 blocks
==21674==      possibly lost: 0 bytes in 0 blocks
==21674==    still reachable: 80,448,922 bytes in 712,285 blocks
==21674==         suppressed: 0 bytes in 0 blocks
==21674== Rerun with --leak-check=full to see details of leaked memory
==21674== 
==21674== For counts of detected and suppressed errors, rerun with: -v
==21674== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
Ловушка трассировки/останова
anonymous
()
Ответ на: комментарий от anonymous

Building tree (1194419 voxels, 6 depth) took 26.013870

Это фантастика! У меня дерево за полсекунды строится. У тебя что, Pentium Pro?

Vikusya
() автор топика
Ответ на: комментарий от anonymous

У меня нет сегфолта. Пока ты один такой, кто собрал, так что подтверждений нет.

Дак ты идёшь в мою школу скилла?

Я ж говорю: «Конечно, иду».

Vikusya
() автор топика
Ответ на: комментарий от anonymous

Сюрприз. Мой man таки:

     void
     qsort_r(void *base, size_t nmemb, size_t size, void *thunk,
	 int (*compar)(void *, const void *, const void *));

Прототип ясен, да? А в линуксе так что ли:

  void qsort_r(void *base, size_t nmemb, size_t size,
                  int (*compar)(const void *, const void *, void *),
                  void *arg);

Слушай, спасибо, от тебя есть польза :) Дай поцелую, зайка!

Vikusya
() автор топика
Ответ на: комментарий от Vikusya

Ну дак давай - вводи меня в свою тему, объясняй что и как тебе надо, как работает твоё непотребство и прочее.

Потом я тебе объясню как это можно норм запилить.

Твои мемкопи на 12байт, твои 10форов на 5строк кода меня пичалят.

anonymous
()
Ответ на: комментарий от anonymous

Твои мемкопи на 12байт

А ты не знал, что компилятор всё равно их разворачивает с фиксированным размером?

твои 10форов на 5строк кода меня пичалят.

Ну нет там такого

Vikusya
() автор топика
Ответ на: комментарий от anonymous

Твои мемкопи на 12байт

Если не знал, то твой уровень низковат.

Vikusya
() автор топика
Ответ на: комментарий от Vikusya

А ты не знал, что компилятор всё равно их разворачивает с фиксированным размером?

Это делается совершенно не так. Юзай структурку. Да и свап захреначит не попацански?

typedef float vox_dot[4] __attribute__ ((aligned (16)));
#define vox_dot_copy(d1, d2) _mm_store_ps ((d1), _mm_load_ps ((d2)))

Хотябы что-то, но один хрен говно.

Ну нет там такого

Есть, там всё на 99% состоит из форов и ущербанской скобочки, а так же тотальной избыточностию.

Если впилить туда норм форич, свап, выкинуть лишние tmp и прочее - будет строк меньше, чем кол-во форов.

anonymous
()
Ответ на: комментарий от anonymous

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

Vikusya
() автор топика
Ответ на: комментарий от anonymous

Добавил фикс, теперь должно работать искаропки

Vikusya
() автор топика
Ответ на: комментарий от Vikusya

Твой браток AIv этого не понял, да и кинул меня. Он обещал меня учить и делать из меня человека, ибо я даже пообещал ему вести себя нормально и слушать его. И не кукарекать тоже.

Я ради него сознался, что бы неправ и обещал не обижать вменяемых людей. Всё ждал, когда мы с ним начнём делать крутые вещи - переварачивать мир. Как он поведёт меня в мир ваших знаний, но он меня кинул.

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

Поэтому ты не делай так же и не кидай меня.

anonymous
()
Ответ на: комментарий от anonymous

И да, ты на это сообщение ответь, чтобы я был уверен, что ты прочел. А то хрен знает, что этим админам/модерам на ум придет

anonymous
()
Ответ на: комментарий от Vikusya

Давай я тебе ещё раз объясню, авось непонятно.

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

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

Я конечно могу переписать твой код, но из этого особо много не выйдет, ибо я не шарю в теме.

anonymous
()
Ответ на: комментарий от anonymous

ОК, ты прочел. Пиши, я всё объясню. А ща я спать

anonymous
()
Ответ на: комментарий от anonymous

superhackprokiller1997 на гмыле. Пиши.

anonymous
()
Ответ на: комментарий от CLU

Нет, это строго наоборот. Забаненный не понимает, что его забанили, и ему кажется, что его просто все игнорируют.

P. S. И завязываю оффтопить.

olegd ★★★
()
Последнее исправление: olegd (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.