LINUX.ORG.RU

Школоподелие + почему SBCL УГ

 


0

3

Здравствуйте, тут, я знаю, любят выкладывать свои поделия на всеобщее обозрение (для получения неоценимых советов, например).

Вот хочу представить поделие, которое на множестве выровненных по оси кубоидов строит октодерево (статическое) (#'voxel-octrees:make-tree), а потом с помощью него предоставляет способ быстро искать пересечение заданного луча с этим множеством (#'voxel-octrees:ray-tree-intersection). Стороны вокселя хранятся в voxel-octrees:*voxel*.

https://github.com/shamazmazum/voxel-octrees

Раньше находил такое вот:

http://www.cliki.net/spatial-trees

но даже не знаю, решает ли оно мою задачу.

А теперь про то, почему SBCL УГ. А дело в том, что для сложения/умножения целых чисел он не применяет SSE2. Ололо, дискасс.

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

Надо будет проверить.

HNO-Arzt_ ()
Ответ на: комментарий от lazyklimm

Ты считаешь, что я не знал про эти вопы? Это писец, я считаю, что SSE2 есть уже так давно, что пора бы сделать это из коробки. Да и была бы нормальная документация по ним.

HNO-Arzt_ ()
Ответ на: комментарий от lazyklimm

Тем более инструкции все давно уже там

;; integer arithmetic
  (define-regular-sse-inst paddb #x66 #xfc)
  (define-regular-sse-inst paddw #x66 #xfd)
  (define-regular-sse-inst paddd #x66 #xfe)
  (define-regular-sse-inst paddq #x66 #xd4)
  (define-regular-sse-inst paddsb #x66 #xec)
  (define-regular-sse-inst paddsw #x66 #xed)
  (define-regular-sse-inst paddusb #x66 #xdc)
  (define-regular-sse-inst paddusw #x66 #xdd)
  (define-regular-sse-inst pavgb #x66 #xe0)
  (define-regular-sse-inst pavgw #x66 #xe3)
  (define-regular-sse-inst pmaddwd #x66 #xf5)
  (define-regular-sse-inst pmulhuw #x66 #xe4)
  (define-regular-sse-inst pmulhw #x66 #xe5)
  (define-regular-sse-inst pmullw #x66 #xd5)
  (define-regular-sse-inst pmuludq #x66 #xf4)
  (define-regular-sse-inst psadbw #x66 #xf6)
  (define-regular-sse-inst psllw #x66 #xf1)
  (define-regular-sse-inst pslld #x66 #xf2)
  (define-regular-sse-inst psllq #x66 #xf3)
  (define-regular-sse-inst psraw #x66 #xe1)
  (define-regular-sse-inst psrad #x66 #xe2)
  (define-regular-sse-inst psrlw #x66 #xd1)
  (define-regular-sse-inst psrld #x66 #xd2)
  (define-regular-sse-inst psrlq #x66 #xd3)
  (define-regular-sse-inst psubb #x66 #xf8)
  (define-regular-sse-inst psubw #x66 #xf9)
  (define-regular-sse-inst psubd #x66 #xfa)
  (define-regular-sse-inst psubq #x66 #xfb)
  (define-regular-sse-inst psubsb #x66 #xe8)
  (define-regular-sse-inst psubsw #x66 #xe9)
  (define-regular-sse-inst psubusb #x66 #xd8)
  (define-regular-sse-inst psubusw #x66 #xd9)
HNO-Arzt_ ()
Ответ на: комментарий от lazyklimm

Ты прям такой крутой хацкер SBCL, да. Я не такой. И желания в нём копаться нет никакого.

Одно дело написать vop, другое - как-то дать понять компилятору, что он должен его использовать. В случае SSE2 и целых чисел, я даже не знаю, какой storage class использовать.

HNO-Arzt_ ()
Ответ на: комментарий от lazyklimm

Вот, кстати, я и хотел спросить, ты разбираешься в том, что говоришь? Если да, давай обсудим реализацию такой фичи как целочисленная арифметика с SSE2. Если нет - то что просто так говорить-то?

HNO-Arzt_ ()
Ответ на: комментарий от HNO-Arzt_

Ты прям такой крутой хацкер SBCL, да

вовсе нет

мне просто кажется, ЛОР - не лучшее место для фичреквестов SBCL, вот и всё

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

Я не реквестирую, я просто ною:)

А mailing list у них тоже - УГ. Такое впечатление, что им насрать, что кто-то что-то сделал для их прожекта. И на вопросы отвечают очень неохотно

HNO-Arzt_ ()

А теперь про то, почему SBCL УГ. А дело в том, что для сложения/умножения целых чисел он не применяет SSE2.

http://repo.or.cz/w/sbcl/llvm.git

Допилишь - будет тебе векторизация

annulen ★★★★★ ()
Ответ на: комментарий от HNO-Arzt_

а не проще сразу на ассемблере писать, тут извращение какое-то

Harald ★★★★★ ()
Ответ на: комментарий от HNO-Arzt_

Это ты про поддержку какой-то там вариации bsd? Да по-моему у них есть поважнее дела. Вон, apple вечно что-то меняет в своей реализации os x, что в рассылках sbcl и clozure cl вечно вспоминают их недобрым словом. Что интересно, lw работает как часы, во всяком случае, на винде точно, в отличие от.

dave ★★★★★ ()
Ответ на: комментарий от Harald

Зойчем? Посмотри мой код. Там вроде достаточно высокоуровнево (на самом деле с изрядной примесью императивщины) написано (кроме таких вещей как hit-box и hit-plane, которые лучше всего было бы написать на C). Только сейчас он работает с floating-point, а мне кажется, что для моего рендерера правильнее и быстрее было бы на целых числах. Проблема в том, что SBCL для floating-point генерирует код с использованием SSE, а для целых чисел - нет.

На ассемблере ты такой код писал бы всю жизнь

HNO-Arzt_ ()
Ответ на: комментарий от dave

Ну я же им уже готовый патч прислал! Без многопоточности, правда

HNO-Arzt_ ()
Ответ на: комментарий от HNO-Arzt_

На новом компьютере у меня нет той части переписки. Я уже не помню, на чем вы там остановились, но вроде бы они чего-то хотели от тебя? Или ошибаюсь?

dave ★★★★★ ()

Картинки я вроде уже показывал:

http://imageshack.us/a/img836/1183/y5n2.png

Тут точек немного, всего полмиллиона, но так как детей у узла в дереве восемь, то в скорости разница небольшая, что 500000 вокселей, что 5000000

HNO-Arzt_ ()
Ответ на: комментарий от dave

Да ну их, там какой-то Кристофер придираться начал типа «прикрепи патч к письму, а не на pastebin закинь». Но я их порядки не знаю, сделал как он просил, потом тупо молчание

HNO-Arzt_ ()
Ответ на: комментарий от dave

Я фигею, но от рассылки этого DragonFlyBSD пользы было больше.

А с многопоточностью я нашел место, которое вызывало ошибку - os_invalidate в thread_postmortem, но что поделать с этим не знаю. Может у них unmap не thread-safe (может же наверное быть такое?)

HNO-Arzt_ ()
Ответ на: комментарий от HNO-Arzt_

Ну, вот, мне и показалось, что ты как-то неуверенно подал свой патч (косяки с языком можно простить). А что касается Кристофа, то по-моему он вполне полит-корректен. У них, вообще, там в sbcl довольно дружная компания. Как и в рассылках clozure cl и lw. Надо бы найти такое еще для allegro cl до кучи :)

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

что ты как-то неуверенно подал свой патч

Да, есть немного (я сначала просто как-то невнимательно прочитал). Но это отбило охоту слать им что-то в будущем (тем более свою репу форкнул)

HNO-Arzt_ ()

Охренеть, ребята! Вот это ЛОР! Уже и по этому вполне нормальному нефлеймогонному треду прошелся вахтер в ночи

HNO-Arzt_ ()
Ответ на: комментарий от HNO-Arzt_

Давай обсудим: Не надо костылять @ используй SSE

anonymous ()

а на код так никто и не посмотрел?

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

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

antares0 ★★★ ()

Каким образом SSE2 может ускорить целочисленные вычисления?

anonymous ()

А что ты ожидаешь от невекторизованных целочисленных вычислений, выполненных на SSE2? Хотелось бы конкретики, а не подсчёта количества использованных инструкций и последующих далекоидущих выводов об оптимальности кода.

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

Ладно, чтобы не утруждать мосх ТС поиском ненужной информации, сообщаю ему, что у мейнстримовых процов арифметику на обычных регистрах умеют делать 3 порта, а на векторных - всего лишь 2.

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

Да мне плевать на такты. Ну расскажи, зачем надо SSE2. По-моему, для моей задачи (различные операции с точками в пространстве, лежащими в массиве) оно было бы кстати. Если нет - то расскажи, для чего оно тогда надо.

HNO-Arzt_ ()

Однако, кому интересно, SBCL умеет упакованные данные через какую-то хитрую жопу:

http://www.pvk.ca/Blog/2013/06/05/fresh-in-sbcl-1-dot-1-8-sse-intrinsics/

Вот кем надо быть, чтобы это использовать ТАКИМ ОБРАЗОМ? Кто гарантирует, что это не отвалится в следующем же релизе?

HNO-Arzt_ ()
Ответ на: комментарий от mv

К тому же вот с этими вкусными инструкциями pabs* я бы как раз смог написать функцию подсчета метрики. Что, всё ещё будешь говорить, что не нужно?

HNO-Arzt_ ()
Ответ на: комментарий от HNO-Arzt_

Если плевать на такты, то зачем тебе SSE?

mv ★★★★★ ()
Ответ на: комментарий от HNO-Arzt_

К тому же вот с этими вкусными инструкциями pabs* я бы как раз смог написать функцию подсчета метрики. Что, всё ещё будешь говорить, что не нужно?

Инструкции x86 - это инструкции x86, причём здесь кроссплатформенный SBCL?

mv ★★★★★ ()
Ответ на: комментарий от bga_

ах все. вижу.

продолжение MMX работает с целыми. В SSE2 регистры по сравнению с MMX удвоились (64 бита -> 128 битов). Т.к. скорость выполнения инструкций не изменилась, при оптимизации под SSE2

bga_ ★★ ()
Ответ на: комментарий от mv

У вас шо, x86 фобия?

И да, кроссплатформенный - это CLISP, а не этот ваш SBCL, работающей с этой архитектурой, с той и ещё на 85% с третьей

HNO-Arzt_ ()
Ответ на: комментарий от mv

Я вас шо-то не понимаю. Вот вы пишете:

последующих далекоидущих выводов об оптимальности

Ну вот мне что-то кажется, что раз есть там такие сложные инструкции типа сумма абсолютного значения разности упакованных чисел из двух регистров, то оно там не спроста. Мне плевать, если код будет исполнятся на два такта короче, но если к примеру вместо 200 секунд он будет исполняться 100 секунд, то из этого прямо таки да, можно сделать «далеко идущие выводы».

Не, вы не стесняйтесь, а расскажите, каким вы видите использование SSE, очень интересно

HNO-Arzt_ ()
Ответ на: комментарий от mv

Инструкции x86 - это инструкции x86

Ага, ну обычный add в x86 - это add именно в x86, может и его выкинуть?

HNO-Arzt_ ()
Ответ на: комментарий от HNO-Arzt_

Целочисленный + есть везде, и нужен везде, ибо это базовая операция АЛУ. SSE2 есть только на x86 (со времён появления x86-64 ). Компилятор нормальную векторную оптимизацию делать не умеет, и если она нужна, то придётся делать руками. Руками - это торчащие наружу платформозависимые интринсики. Возможность сделать такое в SBCL есть, кому надо - делайте.

Мысль понятна?

mv ★★★★★ ()
Ответ на: комментарий от HNO-Arzt_

Ну вот мне что-то кажется

Мне кажется, что язык выбран некорректно, если от него требуется максимальная скорость работы конечного кода.

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

Абсолютно верно, но и на CL порой получаются неплохие результаты и супирь-пупирь быстрота

HNO-Arzt_ ()
Ответ на: комментарий от mv

Целочисленный + есть везде, и нужен везде, ибо это базовая операция АЛУ.

Что такое целочисленный плюс? Я не знаю, как кодируются инструкции в x86, но в том же avr, например, есть куча инструкций, отвечающих «целочисленному +»: сложение восьмибитных регистров, сложение их с учетом флага переноса, сложение 16 битных чисел в паре регистров (вроде такое и в i8080 было), сложение с константой итд итп.

Отличие от x86 хотя бы в том, что коду, выделяющему регистры, надо не тратить пары попусту, а выделять их именно для инструкций, работающих с парами.

Вроде всё верно сказал. Если нет - скажи своё слово. Ты ведь такой спец, что аж закачаешься.

HNO-Arzt_ ()
Ответ на: комментарий от HNO-Arzt_

Абсолютно верно, но и на CL порой получаются неплохие результаты и супирь-пупирь быстрота

Ну вот, круто же. А говоришь, будто SBCL — УГ.

BooBoo ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.