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 пути: терпеть, пилить свой язык и конпелятор самому( что долго и нудно) и ваш совет.

Ответ на: комментарий от 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 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.