молниеносный бамп

Бам-Бам

Не дайте утонуть, не можете ответить - бампайте :)

Я падаю всё ниже и ниже

>>127046850
Спасибо, друг

>Программисты, настало ваше время.
Моё время настало потому, что я за свою работу получаю зарплату в долларах от западных заказчиков, и могу себе позволить практически всё, что захочу. А уебаны вроде тебя, ОП, не получив в ВУЗе никаких знаний, бывают выпизжены оттуда и потом в 30 лет создают треды на дваче о том, как хуёво жить с мамкой. А жизнь-то уже проёбана.

Если спросите почему я так тороплюсь - время поджимает, и если вдруг окажется, что вычислять ну вообще не вариант - мне придется писать класс интерфейса 6Д матрицы для доступа к этой псевдо 2Д матрице. А я этого не хочу

>>127046926
Спасибо, друг

>>127046641 (OP)
Ты, умник, опиши нормально задачу. Может там можно использовать какую-нибудь хитрую свертку - тогда нужно курить математику.

>>127047110
Это для решения некорректной системы линейных уравнений. Эта матрица по сути - Оператор шестимерный, для которого нужно будет потом искать сопряженный и тэдэ

>>127047110
Тут уже ничего не свернешь, по крайней мере я и так уже все как мог сжал и заоптимизировал. Пока там задачи были одномерные или двумерные - хранил в памяти без особых проблем. А тут новый день - новые возможности и надо писать для 3Д

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

Капитан, мы тонем

Неужели тут только пхп-макаки с 300кк в секунду? А простых работяг клавиатуры и монитора нет?

Короче пока от вас нет ответа буду ебашить тест на своей машине. Сколько занимает чтение из памяти этого объёма, сколько занимает запись, сколько занимают вычисления. Но если тред за это время утонет - вы виноваты.

Вместо того, чтобы написать 10 строк кода, ты засираешь мой /б.

Bump

>>127047728
Уж лучше так, чем ты своей анимой ебучей

А говорят программистам математика не нужна

>>127046641 (OP)
Допустим, мы решили хранить матрицу в памяти. Возникает вопрос, как это сделать наиболее оптимально? Поправьте меня, если ошибаюсь, но STL или Boost не вариант, поскольку аллокация/деаллокация при добавлении элементов и т.п. Остается использовать арифметику указателей.
Поскольку храним float, можем вычислить сдвиг и обращаться к участку памяти напрямую.

>>127048284
не, никаких библиотек сторонних, буст я вообще терпеть не могу. Только через указатели, но проблема в том, что доступ к каждому конкретному элементу осуществляется не 2, а 6 координатами, каждый раз это делать ручками - ошибусь и концов не найду. Так что если придется - буду писать интерфейс.

Cчитай на GPU.
Даже на встроенном залетает.
Тупой кернел который запускаешь на следующую пачку элементов, пока обсчитывающий текущий.

>>127048885
Процесс копирования в ГПУ тоже достаточно много времени занимает. Он у меня используется на следующих этапах, где один раз скопировать и много считать. Плюс CUDA в нынешнем своём виде хуёво работает даже с двумерными массивами, и всю эту поеботу нужно разворачивать в одну полосу вообще

>>127048885
Хотя скорее всего буду стремится к похожему варианту. Но отработать сам алгоритм хочется как можно проще. Чтоб потом было с чем результат сравнивать

>>127046641 (OP)
>Дано - матрица содержащая примерно 3ккк элементов (флоаты), которая в процессе дальнейших вычислений используется 3 раза.

Одномерная?

>При вычислении любого из элементов не используется никакой другой из элементов этой матрицы.

Если элемент самостоятелен, то куда тогда она, вся эта матрица потом идет? В файл?

>Вопрос, сильно ли медленнее будет работать вариант, в котором я буду каждый из этих элементов каждый раз вычислять при необходимости? Вычисление элемента включает в себя три операции деления, три экспоненты и два умножения.

Попробуй

>Оперативки это сэкономит немеряно, а т.к. планируется это использовать не на мощных станциях а на рядовых ПК - достаточно важный аспект.

Винде допизды наши маняфантазии, если ты на винде

>Примерная конфигурация среднестатистического компа - i7, 16gb ddr3

>Не подведите меня, докажите, что вы элита.
sad

>>127049304
Копирование надо заранее запускать. Оно у тебя вообще процессор не занимает. Другое дело, что тут надо будет потом настраивать размер блока.
Это если на дискретной.
На встроенных уже сто лет как zero-copy есть.
Делаешь SVM буфер и вперед.
Вообще в таких задачках - быра что то посчитать и получить результат встроенные как минимум не хуже.

>>127049397
Вообще, раз говоришь, что матрица используется как оператор, может она имеет какой-то специальный вид (много нулей и т.п.)? Тогда имеет смысл оценить сколько элементов матрицы реально используется и сравнить скорость доступа к памяти через указатель и скорость вычисления элемента.

>>127049304
https://software.intel.com/sites/default/files/managed/9d/6d/TutorialSVMBasic.pdf

пример от интела

>>127049684
Касательно того, какого размера матрица. В "реальности" эта матрица шестимерная, но для неё нужно будет искать сопряженную потом. Поэтому для "удобства" её представляю в виде двумерной просто сильно растянутой. И тогда сопряженная матрица будет совпадать с транспонированной.

Вся инфа из этой матрицы будет идти в дальнейшие вычисления и они дадут в итоге матрицу меньшего размера и уже честно двумерную.

Попробовал. Лично на моей машине с запущеным мусором под 1ккк элементов места даже не нашлось, у меня 8гб.

>>127050031
за ссылку спасибо

>>127046641 (OP)
> Примерная конфигурация среднестатистического компа - i7, 16gb ddr3
лолд

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

>>127049931
Не, к сожалению нулевых элементов там в общем случае нет. И используются они все одинаково часто.

>>127046641 (OP)
Хуево ты конкретизировал.
1) Что известно про порядок, в котором будет осуществляться доступ к элементам? Скорость извлечения элементов из памяти будет выше если к ним будут обращаться в порядке близком к тому, в котором они лежат в памяти.
2) Насколько тебе важна точность? Нельзя ли использовать "быструю" экспоненту с точностью в несколько десятичных знаков, которая существенно быстрее?
3) Каково пространство этих твоих шестимерных координат? Нельзя для сохранить в памяти не полный результат арифметического действия, а частично, скажем, только экспоненты, или только результаты делений в двухмерном массиве и т.п. ?

Вообще опыт говорит мне, что арифметика скорее всего будет БЫСТРЕЕ чем массив, при грамотной реализации. Особенно шестимерный блять массив - дерефернс шести укакзателей это пиздец как долго.

Вообще мой опыт под

>>127050240
Лол. Собери это с максимальным уровнем оптимизаций, вангую, что выполнится мгновенно.

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

>>127050950
Плохо, кеш охуеет. Расположи данные в памяти похитрее: https://en.wikipedia.org/wiki/Z-order_curve

>>127050950
эммм размерность матрицы типа 50000х50000 ? как ты будешь такие матрицы перемножать?

>>127050723
Кстати да, есть возможность хранить заранее подсчитанные экспоненты. Там буде три матрицы по несколько тысяч (десятков тысяч) элементов. Точность важна. Использовал бы дабл, да памяти не хватает. Потом еще обратную матрицу искать, а она очень чувствительна к таким вещам

>>127051208
С трудом ёптель, очевидно же

>>127051205
за ссылку спасибо, гляну сейчас

>>127051320
ну может ты ниибаца быстрое умножение матрица вкурочишь... иначе оно будет не один час (или день?) считаться. ну хотя бы половину эл-тов можно не считать )

>>127051211
>еще обратную матрицу искать
Ты в жопе чувак, с такими-то размерностями.

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

>>127051780
* с вашими подсказками

>>127051611
Попробую сегодня вообще всё это перенести на видюху. Видюха специально под это дело покупалась год назад примерно. Заебусь только как сука наверняка

>>127051780
Вообще с такими размерностями посмотри в сторону viennacl той же или clBLAS
тем более что ты с флоатами работаешь.

>>127051975
Вот за это тоже спасибо. В эту сторону не копал еще.

>>127051205
Вот ненадо z-order.
Если его в лоб считать, то будет медленно. Там надо таблицу справочную лепить.

Если матрица 6-мерная, то будут аццкие ключи по 6х32 бита.
Если интересно у меня есть код который их считает для произвольной размерности.
Но щастья сортировать ключи недетского размера никакого нет.

Бля, мужики, у меня аж скупая слеза покатилась. Я писал сюда и не надеялся особо ни на что. А оказывается есть еще тут не те, которых тут не надо.

>>127051895
По GPU я не специалист, но уверен, что без хорошей библиотеке для линейки в твоем случае нет пути, типа тех же eigen или lapack. Там тебе и векторизация арифметики, и быстрые алгоритмы умножения/обращения, которые ты хуй сам реализуешь (а профит будет в виде ускорения на несколько порядков), и эффективное распараллеливание на cpu легким движением руки.

Еще, в свете того, что ты дальше собираешься делать нечто, имеющее отнюдь не квадратичную сложность, то наверняка частичным хешированием в каждом случае можно как-то сделать вычисление эл-тов матрицы далеко не основной проблемой. Удачи.

>>127053049
сорри пишу с калькулятора, под героином

>>127046641 (OP)
> в котором я буду каждый из этих элементов каждый раз вычислять при необходимости?
вычисляй один раз и складывай в кэш, потом при необходимости доставай оттуда

>>127046641 (OP)
>матрица содержащая примерно 3ккк элементов (флоаты)
Ёбу дал?

>>127054344
Ебу принял

>>127053762
А кэш хранить на жестком диске для экономии озу?

>>127054414
У меня от тебя stack overflow

>>127054477
я бы предложил ленту для надежности.
А то вдруг битики перепутаются.

>>127054936
Мне кажется, что на карьерном самосвале я мог бы передавать эти данные с достаточно высокой скоростью

ВЗЛОМЩИК БИТКОИНОВ В ТРЕДЕ ПОСОНЫ ВСЕ В САТОШИ

Чем теорией обосновывать, проверь на практике два варианта

КАК ПОЛУЧИТЬ 1000 БИТКОИНОВ БЕСПЛАТНО БЕЗ СМС С ПОМОЩЬЮ ДВУХ СПАРЕННЫХ ВИДЕОКАРТ 3DFX VOODOO BANSHEE ИТТ

>>127046641 (OP)
>12 GB
Lol

>>127047613
Хотел тебе ответить нормально, но после этого поста чёт обидно стало за пхп. Иди-ка ты нахуй.