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

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

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

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

https://news.ycombinator.com/item?id=378581

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

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

;; 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)

Онаний, это ты?

Да

Делай, кто мешает?

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

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

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

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

вовсе нет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SSE2

УГ. Только AVX2, только хардкор!

Ну это они точно никогда не впилят

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

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

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

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

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

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

CCL, емнип, умел SSE2

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

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

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

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

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

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

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

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

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

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

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

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

А warcraft ты дописал?

Да не золотце это

целые это по части mmx

ах все. вижу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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