Исправление www_linux_org_ru, (текущая версия) :
Я интересующую меня постановку задачи озвучил, гран. условия в нее не входят.
к.о. напоминает, что постановка задачи должна интересовать не только тебя — а иначе ее никто решать не будет
Именно потому, что при разумной организации по времени выполнения это доли процента, а сложность кода увеличивает кардинально.
вот это примерно я и хочу от тебя услышать, но тем не менее я не убежден до сих пор
именно, действительно ли счет граничных условий будет занимать доли % при ЛЮБОМ РАЗУМНОМ обходе памяти для счета не-граничной части?
дело в том, что *отдельный* проход по границам это очень дорого — порядка 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, :
Я интересующую меня постановку задачи озвучил, гран. условия в нее не входят.
к.о. напоминает, что постановка задачи должна интересовать не только тебя — а иначе ее никто решать не будет
Именно потому, что при разумной организации по времени выполнения это доли процента, а сложность кода увеличивает кардинально.
вот это примерно я и хочу от тебя услышать, но тем не менее я не убежден до сих пор
именно, действительно ли счет граничных условий будет занимать доли % при ЛЮБОМ РАЗУМНОМ обходе памяти для счета не-граничной части?
дело в том, что *отдельный* проход по границам это очень дорого — порядка 100 таков на каждый флоат
при кубической сетке 1К*1К*1К у нас будет границ 6М, т.е. 0.6% от внутренностей, и поэтому 100тактов*0.6%=0.6 такта оверхеда на каждый внутриграничный флоат; учитывая что, скорость прокачки памяти это ориентировочно 10 байтов на такт, т.е. 0.1 такт на байт, мы имеем оверхед вовсе не в доли процента, а в 600% на весь бенчмарк (который, по-твоему, как раз memory bandwidth bound)
при квадратной сетке 32К*32К границ будет 128К, т.е. грубо говоря в 50 раз меньше, и оверхед будет порядка 600%/50=12%, что хотя и немного, но вовсе не доли процента
Исправление www_linux_org_ru, :
Я интересующую меня постановку задачи озвучил, гран. условия в нее не входят.
к.о. напоминает, что постановка задачи должна интересовать не только тебя — а иначе ее никто решать не будет
Именно потому, что при разумной организации по времени выполнения это доли процента, а сложность кода увеличивает кардинально.
вот это примерно я и хочу от тебя услышать, но тем не менее я не убежден до сих пор
именно, действительно ли счет граничных условий будет занимать доли % при ЛЮБОМ РАЗУМНОМ обходе памяти для счета не-граничной части?
дело в том, что *отдельный* проход по границам это очень дорого — порядка 100 таков на каждый флоат
при кубической сетке 1К*1К*1К у нас будет границ 6М, т.е. 0.6% от внутренностей, и поэтому 100тактов*0.6%=0.6 такта оверхеда на каждый внутриграничный флоат; учитывая, что скорость прокачки памяти это ориентировочно 10 байтов на такт, т.е. 0.1 такт на байт, имеет оверхед вовсе не в доли процента, а в 600% на весь бенчмарк (который, по-твоему, как раз memory bandwidth bound)
при квадратной сетке 32К*32К границ будет 128К, т.е. грубо говоря в 50 раз меньше, и оверхед будет порядка 600%/50=12%, что хотя и немного, но вовсе не доли процента
Исходная версия www_linux_org_ru, :
Я интересующую меня постановку задачи озвучил, гран. условия в нее не входят.
к.о. напоминает, что постановка задачи должна интересовать не только тебя — а иначе ее никто решать не будет
Именно потому, что при разумной организации по времени выполнения это доли процента, а сложность кода увеличивает кардинально.
вот это примерно я и хочу от тебя услышать, но тем не менее я не убежден до сих пор
именно, действительно ли счет граничных условий будет занимать доли % при ЛЮБОМ РАЗУМНОМ обходе памяти для счета не-граничной части?
дело в том, что *отдельный* проход по границам это очень дорого — порядка 100 таков на каждый флоат
при кубической сетке 1К*1К*1К у нас будет границ 6М, т.е. 0.6% от внутренностей, и поэтому 100тактов*0.6%=0.6 такта оверхеда на каждый внутриграничный флоат; учитывая что, скорость прокачки памяти это ориентировочно 10 байтов на такт, т.е. 0.1 такт на байт, имеет оверхед вовсе не в доли процента, а в 600% на весь бенчмарк (который, по-твоему, как раз memory bandwidth bound)
при квадратной сетке 32К*32К границ будет 128К, т.е. грубо говоря в 50 раз меньше, и оверхед будет порядка 600%/50=12%, что хотя и немного, но вовсе не доли процента