LINUX.ORG.RU

Метапрограммирование - проблемы и пути их решения.

 , ,


12

6

Пичал я тут на днях токенайзел для C++-кода, но всё это меня добило я решил поделится.

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

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

Чтобы не быть голословным пишем что-то типа

constexpr uint64_t f(uint64_t a, uint64_t b) {
  return a + b; 
}
Всё ок, но пишем что-то сложнее, аля:

uint64_t m[] = {0, 1, 2, 3, 4};
constexpr uint64_t f(uint64_t a, uint64_t b) {
  return m[a] + m[b]; 
}

Бида( или это моё неосиляторство плюсов?), дак зачем они запилили эту фичу, если она может лишь галимую примитивщину? Шаблоны ещё ущербней. В чем приемущество? Зачем?

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

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

У меня есть 3 пути: терпеть, пилить свой язык и конпелятор самому( что долго и нудно) и ваш совет.

Ответ на: комментарий от drBatty

Ладно, дам подсказку: если при уровне 1м скорость воды 1л/с, то при уровне x метров, скорость x литров в секунду

Насколько я понимаю идею местного вундеркинда, предлагается считать в нанолитрах, нанометракх, наносекундак (или пико-). Точности int64_t всё равно хватит для всех практических задач.

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

Насколько я понимаю идею местного вундеркинда, предлагается считать в нанолитрах, нанометракх, наносекундак (или пико-). Точности int64_t всё равно хватит для всех практических задач.

Да, но там есть одна тонкость: чем меньше воды в баке, тем меньше её напор, и антипереполнение на последних итерациях (даже если у него их будет >5) ему гарантировано. И то, это только при грамотном и внимательном кодировании. Можно конечно нагуглить решение диф. уравнения, но это ему явно не осилить, а даже если он и осилит, я буду удивлён, если он напишет вычисление exp(x) для своих uint64 ☺

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

Твоё жалкое балабольство не знает границ. Твой мозгопроцесс слишком примитивен и жалок.

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

Т.е. расчёт твоей задачи с напором менее даже литра в минуту не имеет смысла, ибо он не возможен в реальном мире.

Это показыват жалкость и узость мышления мышления горестудентов и ущербность матмодели относительно реального мира.

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

а даже если он и осилит, я буду удивлён, если он напишет вычисление exp(x) для своих uint64 ☺

после того, как ТС с треском сольется, это напишу я (да, на инт64) — ниче сложного там нет

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

Особенно для астрономических.

Полагаю, астрономические задачи списаны как неинтересные практически. Ну или int128_t, ага.

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

Я полагаю, что для прикладной астрономии (т.е. тела, летающие в пределах Солнечной системы), расчетов в нано{секундах,метрах,граммах} хватит :) Астрофизика же практической ценностью не имеет, это очевидно.

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

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

Астрофизика (та что солнцем занимается) очевидно тоже весьма практична.

Сама астрономия - астронавигационные системы навскидку из практики. Ну и наконец надо бы слетать на альфа-центавру, ознакомиться с проектом строительства гиперпространственной развязки;-)

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

Ну я даже графики рисовал, глядел, считал, википедию курил - я хороший.

Я придумал стопицот способов, но так и не придумал чего-то, что требудет менее 1умножения на разряд.

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

Давай придумаем с тобой на 10тактов.

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

Если тебе 64бит не хватит, то тебе и дабла не хватит. А если им не хватит 64бит, то запилить что-то больше не особо проблемно и даже будет не особо тормазнее.

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

Давай придумаем с тобой на 10тактов.

Без меня. Фихед пойнт мне неинтересен.

Если тебе 64бит не хватит, то тебе и дабла не хватит.

Неправда. Вы до сих пор не поняли что есть точность. Например на флоатинг пойнт:

10+1 - относительная ошибка почти не меняется
10-9 - относительная ошибка возрастает в десять раз
10*1 - относительная ошибка почти не меняется
10/1 - относительная ошибка почти не меняется

На фихед пойнт (считаем в нанопопугаях):

10+1 - относительная ошибка почти не меняется
10-9 - относительная ошибка возрастает в десять раз
10*1 - относительная ошибка возрастает в десять раз
10/1 - относительная ошибка возрастает в десять раз

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

ДЖаст фор фан подобные извращения м.б. интересны (мне нет), но практического смысла очевидно не имеют. Эта тема была раскрыта целиком и полностью более 30ти лет назад, когда компьютеры были большими.

Хочете интересную задачу на битиках, приносящую пользу - попробуйте сделать вот это [C/C++] перетасовка бит в целом числе

Мы в итоге остановились на реализации через числа Мортона http://stackoverflow.com/questions/1024754/how-to-compute-a-3d-morton-number-...

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

Нет, я не про фикседпоинт - будем юзать даблы, если хотите.

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

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

Ничего небыло раскрыто - на эту тему просто забили.

Погляжу.

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

Я прозрел,

Ну чего, круто если так! Раз за Вас, без всякого сарказма...

Ничего небыло раскрыто - на эту тему просто забили.

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

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

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

Ну чего, круто если так! Раз за Вас, без всякого сарказма...

Я никогда не против был делать так, как вы хотите. Юзать то, что вы хотите и т.п. Я просто считаю, что некоторые вещи не правильны и не более.

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

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

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

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

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

Флоатинг пойнт таки оптимально подходит для большей части задач, а поскольку современное железо дешево именно из за своей массовости, никто не будет делать какие то узкозаточенные вещи для тех задач где флоатинг пойнт не совсем оптимален - там профит от перехода на фихед ИМНО не так уж и велик. Хотя вон же приводили пример бульдозера.

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

Кстати, в формате seg-Y (международный стандарт для сейсмических данных) в описании есть один флоатинг пойнт ИБМ и 3 что ли варианта фихед пойнтов... а сейчас все данные в этом формате всегда ходят в ИЕЕЕ флоатинг пойнт;-)

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

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

Возможно.

Да, я говорю про «фпга», а вернее про редизайн всей архитектуры, а о как таковой замене флоата на фиксед для ваших расчётов я не говорю. Я лишь говорил, что для вас флоат не обязателен и всё можно запилить без него, но да, на дефаулт архитектуре это будет примерно так же быстро, а зачем оно тогда надо?

Суть не в том, что это ваукакаяштука, а суть в том «почему это не юзают?». Придумать проще, чем найти( особенно в наш век), а уж найти инфу про то почему эта штука не взлетела, причемо бъективную с шансом почти 0 искать не смысла.

Про задание - я пока ничего лучше не придумал, чем 2^(x*lb(e)). Я думал, что 2 в степени n посчитать будет удобней, но тут всякие не целые числа с которыми тысячи мороки.

Сейчас пытаюсь как-то опсилить это.

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

Ну я даже графики рисовал, глядел, считал, википедию курил - я хороший.

чувак, среди *нормальных* взрослых людей хорошим считается не тот человек, который маму слушается или начальника, а тот, который достигает результата

так что если ты накачаешься наркотой и получишь 20 тактов на требуемой точности, то я скажу «победителя не судят»... правда почему-то я все-таки существенно больше верю в чтение википедии и пейперов, чем в наркоту

ну и еще — в сам знаешь какой рашке бывают, по рассказам, конторы, где от программиста главное — не код, а дресс-код (около газпрома, по рассказам)

Я придумал стопицот способов, но так и не придумал чего-то, что требудет менее 1умножения на разряд.

подскажу — тейлор, но с дополнительными хитростями, обеспечивает — у меня на 30 (или даже 35, я точно не считал) двоичных разряда точности используется 16 умножений и 5 сложений

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

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

Есть D-мерный массив, который эмулируется на основе одномерного. Т.е. пусть у нас (x,y) координаты элемента, а i - смещение от начала одномерного массива. Обычно i выглядит так:

0  1    2 ... Nx-1
Nx Nx+1 ..... 2*Nx-1
...

Надо делать так:

0  1  4  5   16 ...
2  3  6  7
8  9  12 13
10 11 14 15
...

Соответственно нужно быстро переводить i->(x,y), (x,y)->i, и вычислять смещения до ближайшего соседа от (x,y) в любую сторону.

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

В природе не существует никаких многомерныых массивов.

В ущербанском матане есть такая абстракция, аля [n][n]. Как это выглядит вр еальном мире 0 ... n*n.

#define N 4
uint8_t mas[N][N][N];
typedef struct {
  uint8_t a, b, c;
} for_shit_t;

inline for_shit_t i_to_shit(uint64_t t) {
  for_shit_t ret;
  ret.a = (t & (N - 1));
  ret.b = ((t >> (__builtin_ctzll(N))) & (N - 1));
  ret.c = ((t >> (__builtin_ctzll(N) << 1)) & (N - 1));
  return ret;
}

inline uint64_t shit_to_i(uint8_t a, uint64_t b, uint64_t c) {
  uint8_t * ret = &mas[a][b][c]; 
  return (uint64_t)ret - (uint64_t)mas;
}

Это?

Гцц сделал щит_то_ай примерно так же, как я - я выпилил свой код. А писать для ай_то_щит в адресной арифметике дольше, чем в моей.

Это быстрее твой той байды из поста( я даже не понял, что ты хочешь сделать даже).

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

В природе не существует никаких многомерныых массивов

Скажите об этом людям, работающим в екселе например;-)

я даже не понял, что ты хочешь сделать даже

А Вы попробуйте понять. Или погуглите «фрактал Лебега».

ЯННП в Вашем коде.

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

i_to_shit() - переводит ай в индекс для трёхмерного массива.

shit_to_i() - переводит индекс 3-хмерного массива в ай.

Для 3-хмерных массивов с ребром в степень двойки - вычисляет это за 1-2такта.

А Вы попробуйте понять. Или погуглите «фрактал Лебега».

Я понял, что ваша проблема заключается в том, что вы юзаете вместо mas[n][n][n] mas[n*n*n], и вам надо уметь переводить индекс для первого массива во второй и наоборот, аля:

mas[4][4][4];
mas[3][3][3] = 123;
type_of_mas_elem * ptr = mas;//теперь ptr[1] == mas[0][0][1], а ptr[63] == mas[3][3][3];

Либо я не понял, и я зафейлил, то объясните дебилушке подробней.

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

Я понял, что ваша проблема заключается в том, что вы юзаете вместо mas[n][n][n] mas[n*n*n], и вам надо уметь переводить индекс для первого массива во второй и наоборот

Да, это правильно. И еще искать соседей;-)

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

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

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

Какого размера(примерно) у вас массивы? Я придумаю пацанский обход для него с моей системой.

Ну и примерно опишите то, что вы делаете.

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

1024x1024x1024

Но бывают и двумерные случаи, тогда больше.

Ну вот решаем мы у-е теплопроводности, а данные лежат по фракталу лебега. Задачи я уже написал - i->(x,y,...), (x,y,...)->i и поиск соседа (известно i для (x,y) надо найти i для (x+-1,y,...), для (x,y+-1, ...) и т.д.).

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

Дак для 1024x1024x1024 мои функции дают результат за пару тактов.

У вас (х1, x2, x3), где:

x1 - это множитель для размерности 1024*1024. x2 - это множитель для размерности 1024. х3 - это единицы, который дабовляются тупо.

Т.е. елемент [1000][1000][1000] будет (1000*1024*1024)+(1000*1024)+1000.

Это делает за lea((1000*1024*1024), (1000*1024), 1000). Сдвиг и леа.

Обратно - это просто взять по маскe (1024-1) еденицы х3, потом сдвинуть это на 1024 и о5 взять по маске х2, а потом так же х1. Это чуть дольше, но тоже нереально быстро.

Я понял - вы ищете соседа в Nмерном пространстве и для этого вам нужен 3-хмерный индекс. И потом вы их разименовываете? Если это там мне жалко ваш кеш и тлбешечку.

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

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

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

Я понял - вот так не прокатит?:

inline uint64_t d3_to_i(uint64_t x, uint64_t y, uint64_t z) {
  uint64_t x_i = (x << 20);
  uint64_t y_i = (y << 10);
  return x_i + y_i + z;
}
Вычисляет i по координатам для 1024^3.

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

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

Это то тривиально и неинтересно. Интересно, когда данные лежат по z-кривой (фракталу лебега).

Я не очень понял, что Вам не понятно в описании задачи?

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

Интересно, когда данные лежат по z-кривой (фракталу лебега).

Зачем им лежать по z-кривой?

Я не очень понял, что Вам не понятно в описании задачи?

Какой у вас массив, как вы его обоходите и зачем. ЧТо делаете и т.п.

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

Зачем им лежать по z-кривой?

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

Какой у вас массив, как вы его обоходите и зачем. ЧТо делаете и т.п.

Данные лежат по z-кривой. Массив структур обходится по z-кривой же, для каждого элемента берутся ближайшие соседи (слева-справ-сверху-внизу) и на их основе элемент модифицируется. И так много раз.

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

А вы не дадите ваш простенький код для обхода чего-то и то, что он считает.

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

Данные лежат по z-кривой.

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

и пусть тогда superhackkiller1997 сам придумывает хитрые укладки или пирамидки минковского

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

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

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

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

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

и пусть тогда superhackkiller1997 сам придумывает хитрые укладки или пирамидки минковского

АГа.

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

Последовательная.

Вообще не я не вижу смысла в его z-кривых, ибо при его 1024елементах - это при любом(кроме последней координаты) свиче меняется страничка.

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

Ну да, я скажу что не нужно и запилю так, как нужно.

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

а есть ли схемы расположения многомерного массива в памяти, для которых доказаны свойста оптимальности для определенного обхода и какой-либо модели «память+кэш»?

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

Я дам ТС-у (тока вот найду) код для i_to_shit и обратно. Весь код... ну он не «простенький» отнюдь, и вообще автоматом сгенерен.

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

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

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

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

А ещё код с твоим z-обходом тоже, что я понял почему ты просто не просвапал елементы.

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

Молодец, ты улучшил подход математиков-мразматиков, которые не ослили устройство х86 памяти, только я пока не понял зачем.

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

Да, речь идёт и о i_to_shit и о том, для чего этот ай_то_щит юзается.

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

речь идет о коде вроде такого:

double curr[N][N];
double next[N][N];

for(int i=1; i<N-1; ++i) {
  for(int j=1; j<N-1; ++j) {
    next[i][j]=curr[i][j]
      +(curr[i][j+1]-curr[i][j])*a
      +(curr[i][j-1]-curr[i][j])*a
      +(curr[i+1][j]-curr[i][j])*a
      +(curr[i-1][j]-curr[i][j])*a ;
    }
  // ну и на краях добавить
}
// и еще на краях


for(int i=0; i<N; ++i) {
  for(int j=0; j<N; ++j) {
    curr[i][j]=next[i][j];
  }
}
www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)
Ответ на: комментарий от AIv

Если просто обход без соседей, то любое расположение, надо просто идти вдоль. Если с обращением к соседями - то z-кривая.

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

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

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

перевожу на русский: «я понял, что у меня не получится это оптимизировать, и заранее начинаю придумывать отмазки»

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

оптимизирующий компилятор обладает таким абстрактным мышлением

если ты умеешь меньше, чем оптимизирующий компилятор, то вместо тебя и РНР кодер сгодится

вот, например, что оптимизирующий компилятор, что РНР кодер не скажут автору этого кода, например, «а тут надо брать N не степень двойки, а чуть-чуть меньше, и чуть-чуть перерасходовать память — если это не противоречит другим твоим замыслам»; если ты этого не скажешь, то можно обойтись РНР кодером

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

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

Это не очевидно даже при обычном послойном счете, а уж при LRnLA счете это заведомо не так.

Идея насчет референсного кода хороша, я сам хочу такой, и именно для теплопроводности (как для самой простой задачи). Но есть много нюансов - например при работе в один поток подсистема памяти будет заведомо успевать. А вот при работе в много потоков + SSE, для задач размером порядка РАМ точно успевать не будет. КРоме того, есть разница между 2D и 3D.

Вот ф-я «раздвигающая» биты:

	template<int D> inline long interleav_bits( int rank, int pos ){ long s = 0; for( int r = 0; r<rank; r++ ) s |= ( pos&(1<<r) )<<( D*r ); return s; }
	template<> inline long interleav_bits<1>( int rank, int pos ){ return pos; }
	template<> inline long interleav_bits<2>( int rank, int pos ){
		long x = pos;
		x = (x | (x << 16)) & 0x0000FFFF0000FFFF;
		x = (x | (x <<  8)) & 0x00FF00FF00FF00FF;
		x = (x | (x <<  4)) & 0x0F0F0F0F0F0F0F0F;
		x = (x | (x <<  2)) & 0x3333333333333333;
		x = (x | (x <<  1)) & 0x5555555555555555;
		return x;
	}
	template<> inline long interleav_bits<3>( int rank, int pos ){
		long x = pos;
		x = (x | (x << 16)) & 0x030000FF;
		x = (x | (x <<  8)) & 0x0300F00F;
		x = (x | (x <<  4)) & 0x030C30C3;
		x = (x | (x <<  2)) & 0x09249249;
		return x;
	}
D - размерность задачи, pos - что с-но раздвигаем. Дальше все просто, раздвигаем каждую из координат, и сливаем вместе через | с соотв. сдвигом - получаем смещение.

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

Я постараюсь за сутки-двое накропать «про многомерные массивы», там все будет разжевано.

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

перевожу на русский: «я понял, что у меня не получится это оптимизировать, и заранее начинаю придумывать отмазки»

Зачем мне оптимизировать изначально тупиковую идею? Я не трачу своё время на бесполезности.

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

Это очередная бредня, ибо что ты можешь оптимизировать?

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

Теперь у нас стоит вопрос, аля «зачем на зобход?».

оптимизирующий компилятор обладает таким абстрактным мышлением

Не обладает. Оптимизирующий компилятор лишь уберает лишнии сущности не более и кодазамена по паттернам.

если ты умеешь меньше, чем оптимизирующий компилятор, то вместо тебя и РНР кодер сгодится

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

вот, например, что оптимизирующий компилятор, что РНР кодер не скажут автору этого кода, например, «а тут надо брать N не степень двойки, а чуть-чуть меньше, и чуть-чуть перерасходовать память — если это не противоречит другим твоим замыслам»; если ты этого не скажешь, то можно обойтись РНР кодером

Что ты этим хотел сказать - я не понял.

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

Но есть много нюансов - например при работе в один поток подсистема памяти будет заведомо успевать.

да-да, я это понял, и у меня есть предложение: код должен запускаться как минимум на 4 ядрах, чтобы память тормозила, ну и без sse видимо не обойтись

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

Я постараюсь за сутки-двое накропать «про многомерные массивы», там все будет разжевано.

ну я-то (вроде) понял в чем дело

я очень советую дать _*неоптимизированный*_ референсный код, тогда этому человеческому детенышу что-то станет понятно, да и я смогу подумать побольше

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

Давайте степ-бай-степ, начнем с одного ядра;-)

Вообще будет интересно. Мыло aivanov(злая собака)keldysh(жирная точка)ru. Щас тока цейтнот небольшой...

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

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

ты, главное, не пропадай с лора — тут клоунов не хватает :-)

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

Вообще будет интересно. Мыло aivanov(злая собака)keldysh(жирная точка)ru. Щас тока цейтнот небольшой...

аудитория вдохновляет, а заодно этот чувак веселит изрядно, так что предлагаю продолжить общение здесь, *без спешки*

Давайте степ-бай-степ, начнем с одного ядра;-)

я предлагаю, как временный костыль, одноядерный бенч гонять параллельно на нескольких ядрах, чтобы просадить memory bw

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

Надо давать не только код, а и описание того, что ты этим кодом делаешь, аля я считаю вот это для того-то из вот этого в этом и почему ты именно из «вот этого» считаешь, а так же почему именно «вот в этом» ты считаешь.

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

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

Причем описание не уровня вашей задачки деффузии, а именно то, что вы конкретно решаете этой задачкой.

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

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

Где и как применяются эти подходы написано например по той ссылке на LOR-wiki. Ну или вот http://cfmaxwell.com/j/ - очень актуальная задача, с теорией и проч., и можно даже боевой код скачать и посмотреть.

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

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

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

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

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

аудитория вдохновляет, а заодно этот чувак веселит изрядно, так что предлагаю продолжить общение здесь, *без спешки*

плюсую, вас очень интересно читать

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

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

Вот смотрите. Вы решаете задачку диффузии, но вы НЕ РЕШАЕТЕ ЗАДАЧУ ДИФФУЗИИ. Вы реализуете реализуцию стандартных( либо выших уникальный) методов решения ДФУ( в данном случае).

Мой вопрос: Зачем? Зачем брать абстрактную задачу - возьми реальный расчёт той же диффузии для чего-то( вы можете придумать это) и уже этот конкретный расчёт мы будем реализовывать.

Объясню на примере конктекста - парсинг кода исходного. Мы можем взять абстрактный код и мы получим очередной flex, только сложнее. Нам надо будет учитывать тысячи хрений, который не нужны в 95% ЯП, но мы ОБЯЗАНЫ их учитывать.

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

Я считаю 1-й подход бессмысленный, а 2-й подход вменяемым.

Где и как применяются эти подходы написано например по той ссылке на LOR-wiki. Ну или вот http://cfmaxwell.com/j/ - очень актуальная задача, с теорией и проч., и можно даже боевой код скачать и посмотреть.

Спасибо.

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

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

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

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

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

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

Бить чучело - это совсем не то, на битье чучел учаться писать код, не более.

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

возьмите деффузию не как дфу, а как расчёт для чего-то реального

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

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

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

Никто не говорит, что брать там суперсложную задачу, а взять не сложную, но с похожим принципом. Её запилить не сложнее, чем абстракное дфу, но у вас будет профит, ибо:

Вы будите знать сколько у вас данных.

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

Вы будите точно знать какое соотношение вычислений и месения памяти вам нужно. При 100арифм. операциях на 1 обращение к памяти один подход, к 2операциями на 1обращение к памяти совершенно другой.

Как вы будите знать какой подход лучше? Суть не в определение идеального подхода для ВСЕХ задач, а определение идеального подхода к конкретной задаче.

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

И мы вернулись к тому, с чего мы начали наши дискусси - нереально определить предел того, что ты можешь выжать из машины без учёта ВСЕХ АСПЕКТОВ твоей реализации. На уровне детсада да, ты посчитать можешь, но шанс фейла и погрешность у тебя такая, что быть уверенным в этих подсчётах глупо.

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

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

Бить чучело - это совсем не то, на битье чучел учаться писать код, не более.

Я не выдержал. Я просто обязан выразить тебе своё восхищение. Чувак, ты гениален! Я такого давно не видел.

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

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

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

Автор того боевого кода не я а наш недавно защитившийся аспирант. Хочу отметить, что у нас тут вообще нету проф. программистов.

На сегодняшний день это самый быстрый в мире код для моделирования у-й Максвелла.

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

Т.е. этот аспирант понтовый? Ну это вызов, не менее. Вот мы и нашли объект для батла.

Как жешь я люблю такое, «мы не профф программисты», но поспорить со мною мы любим. Доказывать мне что-то об уровне программистов мы любим, а вот «мы не профф программисты».

Передайте аспиранту, что сорцы линукса не для прикладухи, без ядерных експортов.

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

Я ему ничего передавать не буду, и никакого батла не будет. Мы то не «проф. программисты», но Вы то пока вообще никак не показали что хоть какой то программист. А в данной области я крайне сомневаюсь, что Вы сможете предложить что то разумное - это ИМНО невозможно без хоть какого то минимального знания теории.

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

Я живу в дыре - тут на каждом шагу 100мбит, а так спасибо.

Я возможно убью 3 зайца - пойму ваш стиль мышления, заработаю авторитет и подучу ваш язык.

Ну я понял, что вы имели ввиду под з-кривой. Да, деление на квадратики и обход зигзагами пришел мне в голову вторым, после копирования квадратиков друг за другом( аля устранение взаимозависимостей копированием), но я посчитал это не «пофеншую» для вас, хотя я бы так и сделал.

Буду читать, буду понимать, спасибо.

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

Всегда пожалуйста;-)

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

копирования квадратиков друг за другом( аля устранение взаимозависимостей копированием)

Этого я не понял, можно подробнее?

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

Этого я не понял, можно подробнее?

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

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

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

Надо давать не только код, а и описание того, что ты этим кодом делаешь, аля я считаю вот это для того-то из вот этого в этом и почему ты именно из «вот этого» считаешь, а так же почему именно «вот в этом» ты считаешь.

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

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

и тут ты заводишь свою обычную песенку:

ты: а зачем вообще вы тут обсуждаете, как сверлить отверстия? это не нужно, вы сами себе усложнили жизнь, а теперь героически пытаетесь ее упростить! надо смотреть шире, что ты этим отверстием сделаешь, аля я считаю вот это для того-то из вот этого в этом и почему ты именно к «вот этому» прикрепляешь, а так же почему именно «вот в этом» ты сверлишь.

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

ты: шире надо смотреть! рассказывай задачу целиком и более конкретно — может сверлить вовсе и не надо, а можно скотчем примотать, на веревочке подвесить, на присоске, или вообще соплями приклеить

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

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

Надо давать не только код, а и описание того, что ты этим кодом делаешь, аля я считаю вот это для того-то

там считается уравнение теплопроводности, curr это текущая температура, а next это следующая

т.е. имеем решетку из N на N атомов (хотя они ведут себя не совсем как атомы, но пофиг), и каждый проход цикла это 1 скажем наносекунда времени, за которую соседние атомы обмениваются температурой

пусть для начала у каждого атома только 1 сосед; если скажем у одного атома температура 20 градусов, а у соседа 100, то после 1 нс они температуру вовсе не сравняют, а только приблизят к друг другу, но на какую величину приблизят? этим управляет парамер а; если а=0.25, то новые температуры будут 20+(100-20)*0.25=40 и у соседа 100+(20-100)*0.25=80

на самом деле соседей обычно 4 штуки, и таким образом каждая из 4 строчек, начинающаяся с «+», показывает, что температура next[ i ][ j ] изменяется в зависимости от температуры соседей

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

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

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

манекеном в данном случае является именно то, что ты назвал контекстом юза

и этого манекена ты вначале испугался, сказав че-то про кишки

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

как у туташних пациентов, аля sse в 4раза быстрее фпу для флоатов, когда это бред сивой кобылы.

а на самом деле во сколько? с какой степенью параллельности могут выполняться int, float, целочисленные sse и плавучие sse команды на современных процах?

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

Теперь я тебе расскажу правильную аналогию.

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

Я же вам говорю: Зачем вы это считаете? Что вам это даст? Сверлить нужно только тогда, в том материале в котором от сверления есть мысл.

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

И да, возможно сверлить и не надо, а можно запилить более просто, крепче, надёжней, красивей. Но для этого надо знать КОНТЕКСТ.

Вы мне: Ты лох, ты не осилил. Иди в вуз, мы смеёмся над тобой и т.п. Ты не понимаешь, бла-бла.

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

И да, возможно сверлить и не надо, а можно запилить более просто, крепче, надёжней, красивей. Но для этого надо знать КОНТЕКСТ.

Вы мне: Ты лох, ты не осилил. Иди в вуз, мы смеёмся над тобой и т.п. Ты не понимаешь, бла-бла.

гы-гы

именно для того, чтобы знать «КОНТЕКСТ», необходимо сходить в вуз или осилить *несколько* учебников самостоятельно

так что мы логичны

другое дело, что я могу *быстренько* изложить тебе __*часть*__ контекста, доступную твоему пониманию, и полезную при реализации, но это *не сделает* тебя способным «запилить более просто», т.к. для этого надо знать *весь* контекст, а весь контекст — это скажем половина тех самых учебников

способность работать без значительной части контекста является частью того, что называют абстрактным мышлением, и без этой способности ты так и останешься (быдло?)кодером

короче: ты сильно недооцениваешь необходимый КОНТЕКСТ, или переоцениваешь свои знания и/или способности

это типичная детская особенность

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

Я назвал кишками твою реализацию, которая выглядит как уродство.

а на самом деле во сколько? с какой степенью параллельности могут выполняться int, float, целочисленные sse и плавучие sse команды на современных процах?

Тут дело не в параллельности. Да и вообще никакой паралелньсти тут нет, с чего вы её постоянно сюда приплетаете.

Это зависит от тысяч факторов, ссеинструкции это не аналоги фпушных, а иные, которые имеют сови особенности и тупо сравнивать их глупо.

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

Нет, конекст задачи - это реальный мир, обощеннный матаппарат - это иной мир.

Контекст реально мира - это «у нас есть такой-то материал», «нам надо сделать то-то». Всё.

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

Вон тебе пример в соседнем топике. Я со своим подходом пишу три строчки - ты со своим подходом пишешь скулайт, а на выходе у тебя получается какаха, ибо ты «абстрактный мыслитель».

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

Я назвал кишками твою реализацию, которая выглядит как уродство.

бугага

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

жду не уродскую реализацию

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

афайк R1=R1+R2 и R3=R3+R4 могут исполняться параллельно на обычных регистрах (а вот на ссе — не знаю; т.е. понятно что 2 64-битных сложения могут исполняться параллельно на 1 ссе регистре, но могут ли исполняться параллельно 2 128-битных сложения?)

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

Нет, конекст задачи - это реальный мир, обощеннный матаппарат - это иной мир.

это еще один пример твоего детского прагматизма (как я буду называть твою философию), и тут ты снова не прав

а еще может быть, что это отрыжка пещерного материализма

контекстом задачи, как тебе это не странно, может является не реальный мир, а математический; приведу пример, хотя и чуть неточный, но отражающий суть:

в быту и промышленности нет реальной необходимости в напряжении 500 000 вольт, тем не менее это напряжение создается *исключительно* с целью его потом (после передачи по лэп) *преобразовать обратно*

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

потому, кстати, плавучка и нужна, а целые неудобны — наши данные могут передаваться от модели к модели, а не только от модели к реальному миру

у тебя в голове детсад и сплошной «реальный мир»

а твои рассуждения про ненужность плавучки похожи на рассуждения «500 000 не нужно, так как его негде применить в быту и промышленности»

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

а на выходе у тебя получается какаха, ибо ты «абстрактный мыслитель».

бугага

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

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

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

  uint64_t acc = 0;
  uint32_t r1 = 12, r2 = 13;
  acc = (((uint64_t)r1 << 32) | r2); //загрузка
  acc += ((2lu << 32) | 2);//типа ссе сложение
  r1 = acc >> 32, r2 = acc;//выгрузка

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

Это не выполнение паралельно каких-то мистичских 4-х add'ов.

Поэтому выполенение ссе умножение не равно обычному 32битному умножению + там всякие непонятных с загрузкой и т.п.

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

Мастер аналогий. Ты немного приукрасил действительность 500000 вольт - это реальный мир. Потерь меньше, сечение меньше - передовать мегаваты на 250вольтах там блин кабель будет метра 3 в ширину.

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

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

Ты слишком высокомерен и примитивно мыслишь об моих выводах.

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

Ну вот, дети пилят реактивные решения на 3строчки, а дяди взрослые черепашьи решения на 3кк строк.

Я думаю, что не плохо быть ребёнком, если это даёт профит.

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

Ты слишком высокомерен и примитивно мыслишь об моих выводах.

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

Ты немного приукрасил действительность 500000 вольт - это реальный мир. Потерь меньше, сечение меньше - передовать мегаваты на 250вольтах там блин кабель будет метра 3 в ширину.

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

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

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

Ну вот, дети пилят реактивные решения на 3строчки, а дяди взрослые черепашьи решения на 3кк строк.

Я думаю, что не плохо быть ребёнком, если это даёт профит.

ну и где твое решение с экспонентой, с точностью 32 бита? если у тебя будет по 2 такта на умножение, то это 64 такта против моих 38 (напомню — однопоточных одноядерных без-sse), а ведь тебе еще и хотя бы 32 (f)cmov-а нужно

давай ребенок, продемонстрируй профит

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

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

вопрос «какой из миров — математический или реальный — первичен, а какой является всего лишь следствием» совсем не так однозначен, как тебе кажется

«избыточность есть тормаза» это твоя выдумка, и в руках умелого математика бывает ровно наоборот — модель, далеко выходящая за реальный мир, позволяет считать намного быстрее и сильно экономит реальные такты процессора

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

Я уже писал:

Про задание - я пока ничего лучше не придумал, чем 2^(x*lb(e)). Я думал, что 2 в степени n посчитать будет удобней, но тут всякие не целые числа с которыми тысячи мороки.

И что такое точность 32бита?

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

Я уже писал: Про задание - я пока ничего лучше не придумал, чем 2^(x*lb(e)). Я думал, что 2 в степени n посчитать будет удобней, но тут всякие не целые числа с которыми тысячи мороки.

и где тут про такты? где тут про время бенча?

int main() {
  double res=0;
  const double step=double(1)/1000/1000/50;
  for( double x=-10; x<=10; x+=step ) {
    res += superhackkiller1997_super_fail(x);
  }
  std::cout << std::setprecision(20) << res << ' ' << superhackkiller1997_super_fail(10) ;
  std::cout << " iterations=" << 20/step;
  return 0;
}

у меня это 13.5 секунд на одном ядре проца 2.8 ГГц; при этом заменять суммирование res += ... на известный заранее результат нельзя — оптимизировать можно только код superhackkiller1997_super_fail

И что такое точность 32бита?

это значит, что распечатав superhackkiller1997_super_fail(любое плавучее число от -10 до 10) ты должен получить 10 верных десятичных цифр, ну или 9 с хвостиком

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

А ну да, а ну да. Нука приведи пример.

осиль сначала бенч

хотя, с другой стороны, я тебе давно обещал 2 задачи на оптимизацию — так вот одна из них похожа на то, что дал тебе aiv, а вот вторую я попробую модифицировать так, что тебе нужно будет сделать «избыточную» (гы-гы) модель, в результате которой получится экономия тактов процессора

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

Ну ок, так уж быть я до вечера, как вребя будет, попробую реализовать свою табличную идею на 5-6умножений + табличка менее полукилобайта на 10знаков, ибо там в хламину сложная реализация.

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

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

Шоу маст гоу он!

Итак, референсный код. Я выкинул все лишнее, область считаем квадратной, проверка только на сумму (можно конечно сравниться с аналитическим решением, но мне лень).

//diffuz2D.cpp
#include <math.h>
#include <omp.h>
#include <stdio.h>
#include <stdlib.h>

const double D = 1.; // коэффициент диффузии
const double h = 1e-4; // шаг по времени
const double A = 1-4*D*h, B = D*h;

struct Cell{ float u, tmp_u; };

int main(int argc, const char** argv){
	if(argc!=3){ printf("usage ./diffuz2D Nspace Ndrops\n"); return 1; }
	int N = atoi(argv[1]), Ndrops = atoi(argv[2]); // размер области и число больших шагов по времени 
	Cell* data = new Cell[N*N];
	for(int iy=0; iy<N; iy++)  // начальные условия
		for(int ix=0; ix<N; ix++) 
			data[ix+iy*N].u = (ix==.5*N && iy==.5*N) ? 1. : 0.;
	double start = omp_get_wtime();
	for(int it=0; it<Ndrops*N; it++){
		for(int iy=1; iy<N-1; iy++)
			for(int ix=1; ix<N-1; ix++){ 
				long offset = ix+iy*N;
				data[offset].tmp_u = A*data[offset].u + 
					B*( data[offset-1].u + data[offset+1].u + data[offset-N].u + data[offset+N].u );
			}
		for(int iy=1; iy<N-1; iy++)
			for(int ix=1; ix<N-1; ix++) data[ix+iy*N].u = data[ix+iy*N].tmp_u;
	}
	double finish = omp_get_wtime(), ch_sum = 0.;
	for(long i=0; i<(long)N*N; i++) ch_sum += data[i].u;	
	printf("%i %i %f %f\n", N, N*Ndrops, finish-start, ch_sum);
	delete []data; 
	return 0;
}
собирать командой
g++ -o diffuz2D -O3 diffuz2D.cpp -lgomp
У меня на стареньком коре 2 дуо 19 тактов на ячейку на шаг. Можно сделать такой же 3D.

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

о да, сразу вспоминаю неудобство сишки, от которого я плевался — невозможность создать двумерный динамический массив и необходимость писАть ix+iy*N

кажись у меня макрос был, типа

#define data(i,j) data[i+j*N]

ну и вообще чуток надо названия подправить и т.п.

а по сути — че на границах-то происходит? тепло девается?

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

У меня на стареньком коре 2 дуо 19 тактов на ячейку на шаг.

при каком N?

ну и вообще надо задать референсное значение N, потому что при малых N это поместится в кэш и начнет шустрить сверх меры

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

оно ж там const судя по коду

я тоже самое сказал, только другим словами

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

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

можно конечно сравниться с аналитическим решением, но мне лень

наличие аналитического решения нужно исключить, т.к. это чит

давай сделаем какие-нибудь заковыристые начальные условия

и еще, возможно, сделать чтобы тепло не терялось

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

я если честно не понял физический смысл того, что там происходит, мне кажется, что там накапливается вещество...

А вообще спор с пациентом весьма забавен, но я уже не могу его воспринимать, особенно после треда про БД :/

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

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

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

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

N 512, но надо строить график зависимоти от эн ес-но.

И вообще надо код где нить выкладывать, тут не дело конечно.

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

там тепло рассеивается, вещество диффундирует... ох уж эти специалисты по симплектическим структурам;-)

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

С аналитикой сравниваться в принципе надо.

зачем?!

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

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

моя вина, не заметил коэффициент A перед data[offset].u. =) Сижу и туплю.

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

N=512

тоже никуда не годится, если мы действительно хотим, чтобы было тесно в memory bw

(4+4)*512*512=2М поместится в кэш

надо брать хотя бы N=8192, это даст 4(оптимизация)*8К*8К=256М и 512М в неоптимизированном случае

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

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

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

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

Да, у ТС-а есть такая идея фикс. Но он неправ;-)

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

Я не боюсь что ТС возьмет анатику и выдаст за свой код - это ж сразу видно по исходникам:-)

а обо мне ты подумал? :-)

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

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

к слову а тут о чем спор, то том, что FixedPoint целочисленные вычиления уделывают floating point?

тут вроде (для тех, кто не проповедует FixedPoint) речь идет об оптимальном расположении в памяти — всякие там зет-кривые, конуса минковского и прочее

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

ну ты же покажешь исходники, а иначе низачОт;-)

Насчет разме^ра согласен, я вообще предлагаю ограничится N=1<<R.

Насчет разделения на два массива по полям - не думаю что это даст профит, скорей наоборот. Для ЦПУ во всяком случае.

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

при нетрадиционных порядках обхода и пр. очень легко навалять

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

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

да ни разу не усложнят, просто фигачим закон сохранения энергии на краях и все

лишних 5-6 строк наверно — правда если нам а. решение не обязательно

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

ну ты же покажешь исходники, а иначе низачОт;-)

конечно покажу

но *как* по ним будет решаться, это честная оптимизация, или чит?

Насчет разделения на два массива по полям - не думаю что это даст профит, скорей наоборот. Для ЦПУ во всяком случае.

вот и посмотрим

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

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

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

Насчет разме^ра согласен, я вообще предлагаю ограничится N=1<<R.

вот тут не обязательно, может мне для оптимизации захочется взять N=8180 скажем?

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

если делать хорошо, то 5-6 строчек не хватит, поверь;-) У квадрата доп четыре ребра и четыре вершины - их надо обрабатывать отедльно. У куба 6 граней, 12 ребер и 8 вершин. Давай пока огранимся центральной областью.

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

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

если делать хорошо, то 5-6 строчек не хватит, поверь;-)

не поверю:

data(0,0).tmp_u= /// 1-я
data(0,N-1).tmp_u= /// 2-я
for(int iy=1; iy<N-1; iy++) {
	data(0,iy).tmp_u= /// 3-я
	for(int ix=1; ix<N-1; ix++){ 
		long offset = ix+iy*N;
		data[offset].tmp_u = A*data[offset].u + 
			B*( data[offset-1].u + data[offset+1].u + data[offset-N].u + data[offset+N].u );
	}
	data(N-1,iy).tmp_u= /// 4-я
}
data(N-1,0).tmp_u= /// 5-я
data(N-1,N-1).tmp_u= /// 6-я

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

Да и с чего бы тебе таких странностей захотелось?;-)

швы продублировать

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

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

как-то мне это непонятно, тесно и не нравится — все это очень не в моем стиле

я признаю только условия вида «все знаки (или часть знаков) должны совпадать»

бег в мешках какой-то

фу короче

хотя над порядком обхода все же и интересно подумать

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

ну, два ребра ты уже потерял. А теперь подумай что будет для куба;-) Гранусловия роли не играют, надо брать самые простые.

Я че то непойму, ты с ТС-ом что ли по упертости соревнуешься?;-)

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

ну, два ребра ты уже потерял

да, действительно

но все равно не поверю:

  for(int it=0; it<Ndrops*N; it++) {
    for(int iy=0; iy<N; iy++) {
      memcpy( &data(0,-1), &data(0,  0), N*sizeof(data(0,0)) );
      memcpy( &data(0, N), &data(0,N-1), N*sizeof(data(0,0)) );

      data(   0,iy).tmp_u = A*data(  0,iy).u + B*sum_of_data_u( (   0,iy),(   1,iy),(  0,iy-1),(  0,iy+1) );
      for(int ix=1; ix<N-1; ix++) {
        data(ix,iy).tmp_u = A*data( ix,iy).u + B*sum_of_data_u( (ix-1,iy),(ix+1,iy),( ix,iy-1),( ix,iy+1) );
      }
      data( N-1,iy).tmp_u = A*data(N-1,iy).u + B*sum_of_data_u( ( N-2,iy),( N-1,iy),(N-1,iy-1),(N-1,iy+1) );
    }
    for(int iy=0; iy<N; iy++) {
      for(int ix=0; ix<N; ix++) {
        data(ix,iy).u = data(ix,iy).tmp_u;
      }
    }
  }

в 5 строк если с макросом, и в 4 если развернуть (и размер массива д.б. N*(N+2))

А теперь подумай что будет для куба

подумаю (навскидку — то же самое, оверхед в районе 0.1%)

Я че то непойму, ты с ТС-ом что ли по упертости соревнуешься?

бугага!

совсем вкратце: мое поведение обоснованно

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

поэтому наличие инварианта в референсе — очень желательная вещь, даже несмотря на то, что инвариант может усложнить схему прохода по памяти (а он действительно может сильно усложнить, хотя и записан в 4 строки)

что же касается соревнования с ТС (слегка в другом аспекте — в вычислении экспоненты), то это традиция старого лор-а, и кроме того, ТС-у иначе хрен объяснишь что-то

добавлю, что твои отсылки к утверждениям типа «эти вопросы были исследованы 30-40 лет назад» стоят очень дешево — может быть ровно настолько дешево, сколько требуется для того, чтобы сразу же спросить «ну и какие же доводы за/против 30-40 лет назад были получены?»

понятно, что для занятия практической деятельностью заявления «так делают 30-40 лет» имеет определенный вес, но вовсе не для спора на лоре

так что не надейся на халяву — тут не начнут креститься на фразу «так делают 30-40 лет!!1111» как на икону

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

подумаю (навскидку — то же самое, оверхед в районе 0.1%)

По коду? Тогда подумай еще. Мемсп то тут нафига??? Тащем то там условие посложнее будет, надо выкидывать из суммы некоторые члены и менять соотв образом A. Ну или ставь периодические условия, но тогда в сумму надо другие члены на границах сувать.

твои отсылки к утверждениям типа «эти вопросы были исследованы 30-40 лет назад» стоят очень дешево

Я не википедия что бы объяснять (особенно существу типа ТС-а) какие то азбучные или не совсем азбучные истины. Я не учайствую в конкурсе «самый крутой спорщик ЛОР-а». Поэтому мне абсолютно пофигу, как мои отсылки выглядят. Хотите доказать что я не прав? Сделайте лучше, в чем проблема то;-)

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

наличие инварианта в референсе — очень желательная вещь

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

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

Мемсп то тут нафига???

догадайся с 3 раз

Тащем то там условие посложнее будет, надо выкидывать из суммы некоторые члены и менять соотв образом A. Ну или ставь периодические условия, но тогда в сумму надо другие члены на границах сувать.

если я конечно че-то не упустил, то у меня энергия сохраняется при условии бесконечно точного флоата (и да, я проверил это прогоном 1-ных значений в разных точках на границе)

посмотри внимательно

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

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

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

ну и как ты думаешь, у меня во всех тестовых прогонах были бы всегда нули на ребрах?

кроме того, даже на твоем решении видно, как чексумма немного падает при достаточно больших N

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

Я интересующую меня постановку задачи озвучил, гран. условия в нее не входят.

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

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

вот это примерно я и хочу от тебя услышать, но тем не менее я не убежден до сих пор

именно, действительно ли счет граничных условий будет занимать доли % при ЛЮБОМ РАЗУМНОМ обходе памяти для счета не-граничной части?

дело в том, что *отдельный* проход по границам это очень дорого — порядка 100 таков на каждый флоат

при кубической сетке 1К*1К*1К у нас будет границ 6М, т.е. 0.6% от внутренностей, и поэтому 100тактов*0.6%=0.6 такта оверхеда на каждый внутриграничный флоат; учитывая, что скорость прокачки памяти это ориентировочно 10 байтов на такт, т.е. 0.4 такта на флоат, мы имеем оверхед вовсе не в доли процента, а в 150% на весь бенчмарк (который, по-твоему, как раз прокачкой памяти и ограничен)

при квадратной сетке 32К*32К границ будет 128К, т.е. грубо говоря в 50 раз меньше, и оверхед будет порядка 150%/50=3%, что хотя и немного, но вовсе не доли процента

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

так вот, насчет сохранения тепла я до сих пор не уверен, как правильно, с ним или без него (а если ты *это* назовешь упертостью, то я порекомендую тебе сходить к доктору — проверить, не заболел ли ты сектанством от науки)

тут можно умыть руки и сделать 2 варианта на выбор того, кто будет проводить оптимизацию — вполне возможно, он выберет твой вариант, как более простой, да и я может быть тоже — но это не отменяет пользы разговора о границах :-)

да, еще надо сделать так, чтобы решение не было симметрично (иначе можно считать на 1/8 площади) например, разбросать по квадрату несколько источников

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

догадайся с 3 раз

Не асилю. -1 и N вообще невалидные значения индекса.

если я конечно че-то не упустил, то у меня энергия сохраняется при условии бесконечно точного флоата

Пппц.... коллеги, энергия сохраняется с машинной точностью ес-но. И, если мы фиксируем численную схему (а мы фиксируем схему) - то для данных н.у. и г.у. совпадают все знаки во всех точках при одном и том же моменте времени, вне зависимости от алгоритма (порядка обхода). Но! Хранить дампы для сравнения это бредовая идея (ИМНО) - они могут быть большие. Восстанавливать тем более. И главное, нафига этим заниматься если есть аналитическое решение то???

даже на твоем решении видно, как чексумма немного падает при достаточно больших N

На малых временах не должна. На больших временах - если все работает на малых, то на больших тоже работает;-)

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

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

дело в том, что *отдельный* проход по границам это очень дорого

Ес-но так не делают, г.у. обрабатываются в общем проходе.

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

это не отменяет пользы разговора о границах

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

да, еще надо сделать так, чтобы решение не было симметрично

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

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

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

возможно, я непонятно выразился, но смысл был в том, что аналитическая схема, если я где-то что-то не зевнул (как те 2 ребра), должна сохранять энергию; а на практическом прогоне естественно нет — энергия очень медленно шла наверх

Не асилю. -1 и N вообще невалидные значения индекса.

я же четко сказал, что массив N*(N+2), т.е. (очевидно) специально расширен под индексы -1 и N

могу вообще запостить полный код

но смысл в том, что добавляется 2 лишних ряда, температура которых каждую итерацию делается равной соседям как раз с помощью memcpy — в результате нет необходимости менять формулу расчета... если я опять че-нить не зевнул

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

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

мда... придется объяснять по аналогии

вот, например, люди бегают стометровку из спортивного интереса

а представь, что стометровку надо было бы бежать в несколько кругов диаметром 6 м — интерес бы явно поуменьшился

так и *полноценно* считать центрально-симметричную задачу *неинтересно*, нужна хотя бы некоторая иллюзия того, что там че-то более сложное

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

энергия очень медленно шла наверх

Если только ошибка округления?

я же четко сказал, что массив N*(N+2), т.е. (очевидно) специально расширен под индексы -1 и N

Тогда уже (N+2)*(N+2)?

так и *полноценно* считать центрально-симметричную задачу *неинтересно*, нужна хотя бы некоторая иллюзия того, что там че-то более сложное

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

ЗЫ понимаишь, вот мы новый код пишем - все обкатывается на очень простых, примитивных постановках. Пока все не вылизал - смылса че то боевое считать никакого, ХЗ откуда там кракозябры полезут - то ли это физика, то ли лирика, то ли ошибки в коде, то ли пятна на солнце...

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

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

на практическом прогоне естественно нет — энергия очень медленно шла наверх

тьфу на тя. Ты когда «энергию» бушь считать с такими г.у., края то не учитывай... и все будет стоять на месте.

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