1. >> Для поля потенциалов это не имеет смысла.
2. >> А вот где усложнение формы имеет смысл — это для алгоритма отталкивания.
Ещё как имеет смысл — перекрытие юнитов в «спокойной» обстановке режет глаз.
Но основное — А почему бы эти алгоритмы не совместить?
1. Потенциалы:
Конструируете поле максимальной интенсивности по периметру объекта. Потом, по тем же правилам что и для окружности, рассчитываем потенциал поля (можно закэшировать пред-рассчёты для разных углов поворота).
2. Отталкивание:
В качестве отталкивания выбираем вектор, идущий в сторону максимального ослабления поля потенциалов.
>> Каждое динамическое препятствие (юнит) записывает в сетку в своём положении окружность с меняющимся значением от 1 до 0…
А вы пробовали записывать не окружность, а «визуальную проекцию» объекта?
Выглядит так, что вычислений у вас и так достаточно, но можно было бы приблизить физ.движок к его графическому отображению.
Выглядит так, что Rust не какая-нибудь «заумная фигня», а язык, решающий те же актуальные вопросы, что и С++ за zero-cost (разумеется несколько по-другому, это же не D / C++++, а другой язык).
С одной стороны интересно, с другой стороны размер rust book говорит, что на rust надо будет десятки часов потратить…
Подскажите ещё момент: а в Rust для трэйтов есть имплементации-функций по умолчанию (как в Haskell для тайпклассов)?
Т.е. двусвязный список на Rust можно реализовать или неоптимально или через Unsafe, так?
А на сколько это будет неоптимально, в сравнении с условным C, разумеется примерно, в 1.5 \ 3 \ 10 раз?
(я просто сначала подумал, что варианта «немного неоптимально» нет, и есть только вариант «через unsafe»)
А почему та же техника не подойдёт для двусвязного списка:
— прямая дуга, та которая next — владение (или Rc ссылка) на элемент.
— обратная дуга, та которая prev — Weak ссылка?
Следует ли вас понимать так, что описанных вами проблем в Rust на односвязном списке возникнуть не может (разумеется если не использовать unsafe и ф-ии его экспортирующие)?
ПС
А что позволит Rust «запретить» утечку памяти, связанную с забыванием удаления элемента при самописаном листе и сигнатуре:
fn extract_from_list(list: tlist, key: int8) -> &mut tlist
//извините не знаю Rust, но смысл в том, что удаляемый элемент будем возвращать из ф-ии по ссылке и тогда автоудаления при выходе из scoupe не произойдёт.
Но ведь все те же самые доводы применимы к тезису «односвязный список вещь небезопасная».
Но ведь односвязный список, если я правильно понимаю, в Rust реализуется.
И тогда получается странное:
двусвязный список реализовать нельзя, потому, что он опасен, тем что проблемы№1,2,3…
в односвязном списке те же проблемы №1,2,3… но его реализовать можно.
А как на Rust реализуется граф?
Пусть для определённости будет Control Flow Graph IR программы (сильно разряженный, направленный граф с циклами, без необходимости многопоточного использования)?
Всё-таки структуры данный с циклическими ссылками вещь весьма частая в использовании и весьма эффективная при реализации «в лоб» на указателях.
В «микро» вы правы. Но в «макро»: DCE работает с константами времени компиляции.
А за описанную вами оптимизацию отвечает Constant propagation (вероятно в gcc называется также, но не уверен).
Это я, возвращаясь к нашим баранам, к тому, что конкретно удаление мёртвого кода мало что говорит о качестве оптимизирующего компилятора.
Ну справедливости ради конекретно этот аргумент «выкидывание целых модулей и компонент» — так себе.
Т.к. функционально это близкий аналог DCE (dead code elimination) в gcc. Что является достаточно быстрой фазой, т.к. требует однократного прохода по коду программы (разумеется в специальном представлении: IR).
Ну вот у меня было (когда в качестве начального этапа освоения языка решил олимпиадные задачки пописать), что построение обычного бинарного дерева на Haskell работало раз в 50 медленнее, чем на С.
Ну и я по времени не укладывался.
ПС
Отдельно хочу заметить, что даже не представляю как в этом случае профилировать программу на Haskell.
А как вообще будет выглядеть 2 монадических поведения?
Из самого очевидного (я не настоящий Хаскелист, просто действительно не очень понимаю насколько Хаскелл даже для небольших утилит подходит): логирование (чтобы можно было разобраться что случилось) и maybe (чтобы не писать всю логику «не получилось»).
Позвольте один насущный вопрос: а как сделать, логирование в функциональном ЯП (прогидывать IO(...) в сигнатуру всех ф-ий — я бы не назвал нормальным решением задачи)?
Это зависит от реализации:
— (L1 хранит вирт.адрес + тэг(и) не устарела ли адресация
— L2 хранит физ-адрес (а значит нужна поддержка разадресации, вложенных каталогов адресов, TLB — вот это всё).
Т.е. это моменты хоть и очень важные — но технические.
И можно сказать, что более детальные, по сравнению с общей направленностью статьи.
1. У вас на картинке есть L0_instruction_cache. Это что?
2. ЕМНИП в статье What any programmer should know about memory было утверждение, что время поиска данных в кэше пропорционально размеру кэша (в кэш-лайнах или в бакэтах, не помню).
Собственно есть два варианта:
— вычислить и обосновать какую-то «справедливую функцию» (тут вот прям выше чуть не нейросетки и ген.алгоритмы советуют).
— устроить аукцион (разумеется правила, гарантирующие «честность» аукциона также следует прописать).
Мне видится, что вариант с аукционом более предпочтительным по двум причинам:
— априорная формула — это «демократия сверху», что вообще не очень хороший вариант
— аукцион более устойчив (т.к. имеет отрицательные обратные связи) к попыткам его «взломать / проабузить KPI» и т.д.
Меня, если честно, очень удивило, что люди критикуют пункт о нестандартной внешности.
В частной жизни розовые волосы естественно не означают, я очень на это надеюсь, какое-то предвзятое отношение к человеку (хотя есть другие «стоп-моменты», поверьте они всегда есть, например неприятный запах, мешающая на рабочем месте музыка и т.д.)
Но традиции делового оборота, они пока другие. И не предполагают на менеджерском уровне «розовых волос».
И как эти «розовые волосы» считываются людьми (естественно не всеми, но значительной частью)?
«Он нарушает неписанные неписанные правила ради розовых волос (разумеется это не важный пункт), что ещё он завтра нарушит? Наверное к нему стоит повнимательнее присмотреться, прежде чем давать ему бОльшую, менеджерскую, ответственность».
2. >> А вот где усложнение формы имеет смысл — это для алгоритма отталкивания.
Ещё как имеет смысл — перекрытие юнитов в «спокойной» обстановке режет глаз.
Но основное — А почему бы эти алгоритмы не совместить?
1. Потенциалы:
Конструируете поле максимальной интенсивности по периметру объекта. Потом, по тем же правилам что и для окружности, рассчитываем потенциал поля (можно закэшировать пред-рассчёты для разных углов поворота).
2. Отталкивание:
В качестве отталкивания выбираем вектор, идущий в сторону максимального ослабления поля потенциалов.
А вы пробовали записывать не окружность, а «визуальную проекцию» объекта?
Выглядит так, что вычислений у вас и так достаточно, но можно было бы приблизить физ.движок к его графическому отображению.
Выглядит так, что Rust не какая-нибудь «заумная фигня», а язык, решающий те же актуальные вопросы, что и С++ за zero-cost (разумеется несколько по-другому, это же не D / C++++, а другой язык).
С одной стороны интересно, с другой стороны размер rust book говорит, что на rust надо будет десятки часов потратить…
Подскажите ещё момент: а в Rust для трэйтов есть имплементации-функций по умолчанию (как в Haskell для тайпклассов)?
А на сколько это будет неоптимально, в сравнении с условным C, разумеется примерно, в 1.5 \ 3 \ 10 раз?
(я просто сначала подумал, что варианта «немного неоптимально» нет, и есть только вариант «через unsafe»)
— прямая дуга, та которая next — владение (или Rc ссылка) на элемент.
— обратная дуга, та которая prev — Weak ссылка?
П
ПС
А что позволит Rust «запретить» утечку памяти, связанную с забыванием удаления элемента при самописаном листе и сигнатуре:
fn extract_from_list(list: tlist, key: int8) -> &mut tlist
//извините не знаю Rust, но смысл в том, что удаляемый элемент будем возвращать из ф-ии по ссылке и тогда автоудаления при выходе из scoupe не произойдёт.
Но ведь односвязный список, если я правильно понимаю, в Rust реализуется.
И тогда получается странное:
двусвязный список реализовать нельзя, потому, что он опасен, тем что проблемы№1,2,3…
в односвязном списке те же проблемы №1,2,3… но его реализовать можно.
Пусть для определённости будет Control Flow Graph IR программы (сильно разряженный, направленный граф с циклами, без необходимости многопоточного использования)?
Всё-таки структуры данный с циклическими ссылками вещь весьма частая в использовании и весьма эффективная при реализации «в лоб» на указателях.
Аналоги неотличимые по качеству (правда по чужим словам — я брал именно эрготрон, хороших аналогов в тот момент ещё не было) стоят от 6к рублей.
Поэтому выставлять на показ качество подставки под дорогой монитор — просто непрофессионально, уж извините.
А за описанную вами оптимизацию отвечает Constant propagation (вероятно в gcc называется также, но не уверен).
Это я, возвращаясь к нашим баранам, к тому, что конкретно удаление мёртвого кода мало что говорит о качестве оптимизирующего компилятора.
Т.к. функционально это близкий аналог DCE (dead code elimination) в gcc. Что является достаточно быстрой фазой, т.к. требует однократного прохода по коду программы (разумеется в специальном представлении: IR).
Как вы его переведёте?
Ну и я по времени не укладывался.
ПС
Отдельно хочу заметить, что даже не представляю как в этом случае профилировать программу на Haskell.
А как вообще будет выглядеть 2 монадических поведения?
Из самого очевидного (я не настоящий Хаскелист, просто действительно не очень понимаю насколько Хаскелл даже для небольших утилит подходит): логирование (чтобы можно было разобраться что случилось) и maybe (чтобы не писать всю логику «не получилось»).
— (L1 хранит вирт.адрес + тэг(и) не устарела ли адресация
— L2 хранит физ-адрес (а значит нужна поддержка разадресации, вложенных каталогов адресов, TLB — вот это всё).
Т.е. это моменты хоть и очень важные — но технические.
И можно сказать, что более детальные, по сравнению с общей направленностью статьи.
Но есть ряд вопросов:
1. У вас на картинке есть L0_instruction_cache. Это что?
2. ЕМНИП в статье What any programmer should know about memory было утверждение, что время поиска данных в кэше пропорционально размеру кэша (в кэш-лайнах или в бакэтах, не помню).
Как современные L1 кэши делают поиск быстрее?
— вычислить и обосновать какую-то «справедливую функцию» (тут вот прям выше чуть не нейросетки и ген.алгоритмы советуют).
— устроить аукцион (разумеется правила, гарантирующие «честность» аукциона также следует прописать).
Мне видится, что вариант с аукционом более предпочтительным по двум причинам:
— априорная формула — это «демократия сверху», что вообще не очень хороший вариант
— аукцион более устойчив (т.к. имеет отрицательные обратные связи) к попыткам его «взломать / проабузить KPI» и т.д.
А при работе из дома этой вот широкой ниши «обо всём около-рабочем и около-технологическом» сильно не хватает.
В частной жизни розовые волосы естественно не означают, я очень на это надеюсь, какое-то предвзятое отношение к человеку (хотя есть другие «стоп-моменты», поверьте они всегда есть, например неприятный запах, мешающая на рабочем месте музыка и т.д.)
Но традиции делового оборота, они пока другие. И не предполагают на менеджерском уровне «розовых волос».
И как эти «розовые волосы» считываются людьми (естественно не всеми, но значительной частью)?
«Он нарушает неписанные неписанные правила ради розовых волос (разумеется это не важный пункт), что ещё он завтра нарушит? Наверное к нему стоит повнимательнее присмотреться, прежде чем давать ему бОльшую, менеджерскую, ответственность».