LINUX.ORG.RU

Задачка на подумать (диагональный сдвиг по Z-кривой Мортона)

 


4

3

Есть такая замечательная штука как Z-кривая Мортона, очень удобна для всяких рекурсий и многомерных массивов с хорошей локальностью данных.

Нужно зная сдвиг ячейки от начала D-мерного массива найти сдвиг ее ближайшего соседа по диагонали (вперед-вверх).

Я знаю только такое решение

const uint64_t zmasks[16]={
  0xffffffffffffffff, 0x5555555555555555, 0x9249249249249249, 0x1111111111111111,
  0x1084210842108421, 0x1041041041041041, 0x8102040810204081, 0x0101010101010101,
  0x8040201008040201, 0x1004010040100401, 0x0080100200400801, 0x1001001001001001,
  0x0010008004002001, 0x0100040010004001, 0x1000200040008001, 0x0001000100010001 
};

template <int D, typename T> T zoff_diag_shift(T offset){  
  for(int i=0; i<D; i++){
    T omask = zmasks[D-1]<<i, imask = ~omask, fix = offset&imask;
    offset = (((offset|imask)+1)&omask)|fix;
  }
  return offset;
}

т.е. берем и тупо двигаем последовательно на единичку по каждой из координат. Может кто то может предложить более эффективный вариант с меньшим числом операций, ситуация то выделенная?

★★★★★

Последнее исправление: AntonI (всего исправлений: 3)
Ответ на: комментарий от AntonI

Можно глянуть выхлоп -S

clang-9 все три варианта zoff_diag_shift (оригинальный, 2 и 7) считает эквивалентными. Как он раскрутил оригинальный offset = непонятная_магия(offset) до хорошо параллелизуемых 2 и 7?!

gcc-9.3 - генерит 3 разных варианта.

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

У меня сейчас тоже пятый, что будет в 20й бубунте пока не знаю.

Ну я видимо пока возьму версию с циклом (аналогично можно переписать еще всякие операции), и попозже покумекаю над векторизацией.

Спасибо!

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

Тоже что ли попробовать этот clang… и правда непонятно че они туда напихали, внушает.

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

Я знаю как мин. два применения

Хочу поправить.

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

На самом деле, если касаться вычислений на компьютере, то расположение байтов расположено линейно от 0 до количества вставленной оперативной памяти.

N мерные масcивы очень просто обрабатывать оптимально. Для примера возьму 2-х мерный.

Например массив пикселей в битмапе. Пиксел можно к стати рассмотреть как третье измерение.

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

Но суть не в этом. Суть в том, что оптимизация доступа к пикселям на современных компьютерах осуществляется именно построчной обработкой пикселей. Тоесть оптимальнее обработать все пиксели в строке а не, например, пиксели по столбцам. Это задаётся тем что есть такое понятие (точнее реально физически существующая реализация) как кеш в процессорах, доступ к которому обычно многократно быстрее чем к общей памяти. При считывании какого-то (даже одного) байта в кеш «утягивается» целая строка последовательных байт. Например в старых i486 процессорах минимальная трока была 16 байт.

Поэтому при обработке изображения стоит строить циклы так, чтобы внутренний цикл обрабатывал элементы в строке, а внешний уже крутил сам массив строк.

Так же и с любыми N мерными массивами. Например массив int m[x][y][z][p]. чем правее находиться измерение при объявлении массива тем ближе оно по расположению в памяти.

Поэтому не стоит городить лишние вычисления которые будут «жрать» как вычислительные ресурсы так и выдавливать собой из кеша полезные данные (которые туда уже были ранее подгружены автоматически) нужные для целевой обработки.

Думаю второй пункт тоже можно притянуть к моему объяснению выше.

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

Поэтому при обработке изображения стоит строить циклы так, чтобы внутренний цикл обрабатывал элементы в строке, а внешний уже крутил сам массив строк.

Фишка сабжа как раз в том, что соседи по любому измерению (почти) равноудалены, итерирование по любым измерениям одинаково локально.

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

Фишка сабжа оторвана от реальности.

Реальность - когда измерения равнозначны, а твоя реальность - измерения неравнозначны.

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

А теперь представьте что в каждой ячейке 2D массива что то вычисляется на основе 4х соседей (слева/справа/сверху/снизу). Соседи слева/справа по памяти лежат рядом и уже закэшированы, а вот соседи сверху/снизу при обычной реализации описанной Вами лежат по памяти далеко и их придется кэшировать отдельно. Есть и более сложные ситуации.

Поэтому не стоит городить лишние вычисления

Вот чего точно не стоит делать так это бегать по моим темам и писать там что то если Вам нечего написать по делу.

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

ну и нафига ты ту тему от анонимусов огородил? интересная тема же

вот эту тему ?

мне есть что сказать по этой теме:

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

Соответственно вопрос - есть ли сейчаc такие утилиты? Я бы такую хотел (для плюсов).

doxygen, например, умеет генерировать UML диаграммы. если произвольная нотация – см. ниже

  1. Программа максимум - именно программирование. То есть мы берем структуру данных (точнее ее фрагмент) и мышкой перебрасываем стрелочки.

в целом: те же UML средства моделирования. здесь нужно смотреть в сторону расширяемых плагинами, желательно скриптами. например, Xtend/Xtext позволяет написать свой DSL. на базе Eclipse есть umldesigner, ЕМНИП. в какой-то из бесплатных сред моделирования UML на подобном Xtend/Xtext DSL-е можно было написать свой шаблонизатор, чтобы из диаграмм рисовать в другой язык программирования (настравиемо этими шаблонами)

в целом, смотри в сторону:

а) языков моделирования данных, например STEP EXPRESS ISO 10303. и графического Express-G. есть например JSDAI (J=Java), в котором стандартный ORM (SDAI=SDAI из STEP) автогенерируется в соответствии с этой методологией. там есть видео, примеры, как это всё выглядит. довольно доступно и наглядно.

STEP это по сути ООБД расширение SQL-ного ER IDEF1x. для которого есть например ERwin как среда моделирования, либо нечто опенсорсное. собственно, STEP предлагает

  1. ООП АДТ модели с валидацией и верификацией, а не просто какие-то модели базы данных. то есть, модели параметрические, вычисляемые по функциям/правилам и предикатам, AND/OR деревьям решений для классификации и проверки валидации.

  2. Part21 как стандартный формат выгрузок

  3. EXPRESS-G как стандартный графический язык моделирования данных

  4. EXPRESS-M для конвертации

  5. SDAI как стандартный ORM.

  6. AP aka Application Protocols как стандартные интерфейсы поверх STEP.

  7. технологическую нейтральность от конкретных языков, сред, средств – если реализована поддержка инструментария.

б) конструкторов для графического моделирования. например, на питоне есть библиотека Gaphas, на которой построен Gaphor – средство моделирования UML но вообще можно расширить своими языками моделирования данных.

в) смотри в сторону «literate programming», например MkTechDocs, pandoc с плагинами, например plantUML. например, CDsoft: ABP, PP с примерами. или даже старого DDP, GPP

PP кстати поддерживает «literate programming», посмотри пример книжки, написанной в таком духе. там же у него есть книжка по малине – обрати внимание на свёрстанный PDF

книжка сама по себе свёрстана в самом таком PP, в духе «literate programming»

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

продолжение

в общем, если обобщить, как делал бы я такое средство, как ты примерно хочешь:

  1. PP + plantuml + pandoc + прочие препроцессоры для своего языка графического моделирования, в рамках единой среды для «literate programming» подхода

  2. расширить LitProg средство, чтобы оно могло писать не просто два потока документации «блоков документации» и кода «блоков кода» – простых шаблонов без параметров. а чтобы во-первых, таких параметров метапеременных блоков кода было несколько, с наследованием. во-вторых. ввести «блоки данных» для моделирования данных и метаданных. на каком-нибудь SDAI. не с кривым DOM, а с нормальной объектной моделью в духе CLOS и метаобъектного протокола с метаклассами.

  3. в идеале, нужно не pandoc + haskell а что-то лисповое, например skribilo на Guile с AST макросами и reader/writer макрами. чтобы эти блоки «документации/кода/данных и метаданных» прозрачно транслировались в такой AST. обрабатываемый AST макросами на skribilo.

хотя, если смотреть на ABP (хотя там немного сыровато по сравнению с PP). то это прообраз того как такой транслятор проходов обработки можно написать на haskell + ленивости и ADT а не skribilo/Guile/AST макросы на Scheme.

опять же, «транслятор проходов обработки» должен работать с моделями и метамоделями. на уровне блоков «документации/кода/данных», а в идеале – с полноценными STEP EXPRESS моделями.

  1. смотри в сторону JSDAI как более-менее полноценной возможности работы со STEP EXPRESS, правда Java а не Scheme/Haskell

  2. смотри в сторону Gaphas как низкоуровневой библиотеки и Gaphor как высокоуровневой программы моделирования. моделей данных, в духе STEP EXPRESS. которая ещё не написана. в духе визуального средства для интерактивной разработки. а не UML как сейчас на Gaphor. хотя там можно навелосипедить плагины.

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

ещё для хаскеля есть Diagrams, который руки чешутся к какому-нибудь ABP прикрутить, в качестве прохода транслятора.

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

хотя по степени проработанности нужно смотреть в сторону того же STEP EXPRESS и JSDAI какого-нибудь.

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

Спасибо. МНого букв, я позже (к завтрому наверное) отвечу.

Не все анонимусы к сожалению вменяемы;-(

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

в общем, я немного просмотрел тот тред. сформулируй тезисы.

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

так оно УЖЕ вполне себе существует. только некоторые моменты нужно собрать вместе, допилить и доработать напильником до кондиции.

например, ту же книжку от CDsoft, жаль, правда исходников не видно для наглядности (ну да, может напрямую с автором списаться) – ну да там всё и так более-менее очевидно, в духе Emacs org-mode babel и книжек в нём написанных. например, на сайте Rigidus блог в таком духе написан. см. на гитхабе исходники сайта, в org-mode. там же у него какой-то препроцессор org-mode блоков на elisp. он что-то с чем-то обрабатывает, и делает свой literate deployment презентация – вообще, самое, на мой взгляд, адекватное введение в ~литературное~ грамотное программирование, что я видел.

у CDsoft был проект про книжку про функциональные спецификации:

подход, метод, проект и презентация проекта

жаль, что он не собрал достаточно краудфаундингом. и книжку и проект по написанию книжки – зарезал.

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

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

Там действительно много нафлеймили, но все таки свои хотелки я в исходном посте КМК довольно внятно изложил. Я че то похожих вещей не знаю. Давайте именно о них говорить?;-) По п.1 - целевой ЯП плюсы.

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

то есть, ты хочешь из кода на плюсах генерировать визуальные модели данных? doxygen умеет генерировать class diagram например.

или из моделей данных на каком-то другом языке моделирования данных генерировать «конкретный» код на языке программирования (C++, Java через JSDAI, MUMPS, SQL и т.п.)?

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

то есть, первый шаг – связать модели данных на языке моделирования данных и конкретные реализации этих моделей на ЯП, например плюсах или java – успешно решается.

второй шаг – связать модели данных как текстовый DSL и визуальные представления этих диаграмм – решается например через plantuml и какую-то ‘literate programming’ среду в духе PP, или mkTechDocs (и там, и там – pandoc с постпроцессором).

примеры из PP: literate programming и про диаграммы

в другую сторону, то есть, из визуальных наглядных картинок в DSL, их порождающий – ну тут, как я понимаю пока решается «в лоб». если есть какое-то универсальное средство которое умеет произвольные shapes диаграмм рисовать самому и хранить всё в XML. например, та же Dia. или тот же Graphas/Graphor на питоне.

осталось интегрировать и связать всё это вместе, в какой-то единой визуально-интерактивно и литературно-скриптуемо-воспроизводимой (и всё это одновременно) среде.

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

как технология STEP EXPRESS по сути самый настоящий overkill. потому что технологическая нейтральность, от конкретных языков. средства метамоделирования. средства сохранения корректности моделей и версий, и автомагическая конвертация при переходе на новую версию моделей данных (описан процесс такого перехода в самой методике стандарта). стандартные ORM SDAI и Part21 как формат для переноса.

то есть, основные 10500 стандартных проблем сурового энтерпрайза (типа изменилась структура базы данных, теперь велосипедим ручные выгрузки и конвертации, отдельно для БД и отдельно для кода) – успешно там решена.

другое дело, что STEP SDK продают за деньги. из доступных OpenSource есть JSDAI для Java и нечто для Common Lisp.

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

если нужно что-то гораздо более простое – Stratego/XT и Spoofax, там были примеры про WebDSL для веб-приложений с транзакциями и многозвёнкой, из своего DSL в своей среде разработанного. на полноценных ERwin IDEF1x подобных моделях данных.

или тот же PicoLisp со статьей про «Rapid Application Development in PicoLisp». где ООП прототипное, интегрированное со своей базой данных на BTree с моделями данных, демоном отношений, с лисповым DSL интегрированными в HTML для описания всего этого. с интегрированным прологом на лиспе для запросов к такой ООБД.

в общем, вопросы интеграции моделей данных с автогенерируемым ORM слоем – успешно решаются в означенных технологиях.

с той или иной степенью громозкости и всеобъемлеюмощести языка моделирования моделей данных (и метаданных).

да например. под тот же Emacs был Memacs. в org-mode хранились заметки которые по сути хранились в вики в Zope OODB базе данных на питоне. и из плюсов такого вот хранилища приводилось за то, что можно моделировать в вики-подобной среде какую-то простую модель данных и онтологию, которой уже будет достаточно.

потом те же smart wiki. где хранится исполняемый на стороне сервера код, документы по шаблонам и плагинам, автогенерируются связью с БД. например, Gwiki на Java. или какой-то Semantic Media Wiki.

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

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

то есть, ты хочешь из кода на плюсах генерировать визуальные модели данных? doxygen умеет генерировать class diagram например.

Я в курсе, но этого я не хочу. Я хочу в рантайме увидеть объекты в виде квадратиков и пойнтеры (в т.ч. косвенные) в виде стрелочек. Причем желательно что бы это было интерактивно, то есть что бы можно было схлопывать части графа, смотреть как граф меняется в процессе работы и пр.

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

Да, про это в той теме много писали, но я пока его не асилил.

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

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

Ничем описанный случай не выходит из предложенного мной метода оптимизации вложенности циклов обхода массива данных.

Всё отлично вкладывается в концепцию. Будут кешироваться строки например 3апример три строки и эти сроки будут очень хорошо обрабатываться последовательно пробегая по элементам этих строк.

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

Есть и более сложные ситуации.

Конечно есть. И всё же обычно всё равно можно найти места, которые можно обойти в цикле так, чтобы выдавливать из кеша минимум нужных для локальных вычислений данных. И это тоже прекрасно вкладывается в предложенный мной метод оптимизации при прохождении элементов массивов.

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

Почитайте пожалуйста например вот это https://habr.com/en/company/intel/blog/277407/

Если на пальцах, в Вашем случае вычислительная интенсивность будет втрое хуже чем в случае Z-кривой (для двумерной задачи, для трехмерной задачи в пять раз хуже). Дальше смотрим на roofline и понимаем что в некоторых случаях это может приводить превращению задачи из compute bound в memory bound и кратному падению производительности.

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

в Вашем случае вычислительная интенсивность будет втрое хуже чем в случае Z-кривой (для двумерной задачи, для трехмерной задачи в пять раз хуже).

Это голословное утверждение, как пальцем в небо.

Вот ради интереса. Давай возьмём какую нибудь конкретную задачу, не очень сложную, в которой нужно будет обрабатывать эллементы многомерного массива. Я сделаю обычную, общепринятую, оптимизацию с перераспределением вложенности циклов и оптимизацию обращения к переменным. А ты сделаешь свою Zet оптимизацию. Можем пока даже без оптимизации с распределением на потоки. В один поток (чтобы проще). Потом сравним эффективность вычислений.

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

Это голословное утверждение, как пальцем в небо.

Это констатация факта, известного специалистам по HPC уже лет дцать как. Одну из статей и ключевые слова я привел, дальше сами.

Вот ради интереса. Давай возьмём…

Не возьмем. Мне неинтересно этим заниматься (это пройденный этап), особенно с Вами - Вы не умеете воспринимать аргументы собеседника. Еще раз прошу Вас больше не писать в моих темах, создайте свою тему про резонанс в S&E и там поговорим.

AntonI ★★★★★
() автор топика
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от HIS

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

Я по прежнему жду от Вас тему про резонанс в S&E.

AntonI ★★★★★
() автор топика
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

Моя описка в применении термина меркнет перед тем, что ты считаешь фактом то что Земля - круг. Плоскоземельщики и наука не совместимые вещи. Но ты продолжай! Наяривай! Это забавно наблюдать.

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

Вы несколько комментариев подряд с пеной у рта утверждали что энергия это вектор, не надо ля-ля про «описки».

Словосочетание «Земля круглая» является устоявшимся термином.

Зато Ваши обещания создать тему про резонанс в S&E так и остались пустой болтовней.

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

AntonI ★★★★★
() автор топика
Последнее исправление: AntonI (всего исправлений: 2)
Ответ на: комментарий от AntonI

Я тебе написал как оптимизировать в современных компьютерах доступ к данным при работе с многомерными массивами.

Разберись в вопросе в начале. Я 30 лет программированием занимаюсь на практике. Приношу тебе разжёванное на ложечке ответы на твои вопросы по теме, а ты опять хрен знает куда всё ведёшь.

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

Словосочетание «Земля круглая» является устоявшимся термином.

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

Как других так ловишь на оговорках, а сам например даже тут развёл псевдо знание про Зет распределение многомерных массивов в кеше процессора.

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

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

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

оставь надежду всяк сюда входящий - жираф большой - ему видней!

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

Во первых я предлагаю для начала определить задачу и входные даннын самому ТС-у (чтобы небыло подоплёки будто я под себя придумал задачу удобную для стандартных оптимизаций).

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

Поэтому пусть свои теории ТС сам применит к памяти в компьютерах, а я применю то, что я знаю про организацию кешей в своих алгоритмах.

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

Слушай, ты мне прямо к делу подкинул эту кривую. Только я думал, как мне в многомерных массивах от многомерности уйти и локальность хоть как-то получить, а тут такое.

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

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

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

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

Есть еще кривая Гильберта, у нее локальность еще лучше - но делать ее это адЪ. Если хочешь, кину в почту хидер на плюсах где всяко разно для Z-кривой (переход к i,j,k и обратно, поиск соседей и пр.).

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

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

Если оптимизировать (и порядок обхода пикселей в окне неважен), то окно будет состоять из нескольких фрагментов расположенных в памяти подряд.

Я вот прямо для такого алгоритм/интерфейс не делал. Это интересно, можно подумать, такая штука перекликается с некоторыми моими задачами.

AntonI ★★★★★
() автор топика
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от peregrine

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

Вот даже взять обход по Zet кривой из топика. Если знать в самом начале что именно требуется в задаче и вдруг очевидным решением показалось обход по этой методике. То вполне будет логично расположить сразу вводные данные в памяти в линейном виде растянув Z кривую в прямую, что в принципе очень удобно делается массивом и так без особых ухищрений. просто взять квадраты (или кубы и ли что там нужно будет по задаче) и рассовать их нужным образом по измерениям массива изначально перед вычислением.

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

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

будет логично расположить сразу вводные данные в памяти в линейном виде растянув Z кривую в прямую

А на третий день обсуждения на ЛОРе @HIS Соколиный Глаз заметил что у нашей тюремной камеры нет одной стены(с)

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

Не передёргивай опять.

Я тебе доношу, что никаких «магических» сверх вычислений не нужно делать. Оно и так всё будет хорошо если правильно сделать вложения циклов. И об этом я тебе сказал сразу: Задачка на подумать (диагональный сдвиг по Z-кривой Мортона) (комментарий)

Именно правильное вложение циклов и делает выравнивание твоей «магической» кривой в нормальный вид при использовании правильных вложений циклов.

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

Пользуйся теперь на здоровье без лишних вычислений надуманных диагоналей. Это бесплатные знания.

HIS
()
Ответ на: продолжение от anonymous

Он не хочет язык графического моделирования. Он хочет по обычному языку строить графический.

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

По таким 8ми при обычном обходе не хуже чем по 4м (верхняя и нижняя строки уже в кэше). А вот по таким 8ми

  o
  o
ooxoo
  o
  o

нужно ещё 2 строки и локальность уже в пять раз хуже чем у Z-кривой.

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

Ну там вообще трындец. Да и операций многовато… это как то к редукции свести нельзя? Ну есть всякие фишки, что фильтрация в скользящем прямоугольном окне сводится к прибавления значения слева окна и отниманию значения справа от окна. В 2D чуть сложнее

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

Ты не испраавим

Тебе уже объяснили ранее всё.

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

Обычно просто гоняют там, где не особо надо (просто ходят везде).

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