движок , ибо заманала аллокация на параллельных вычислениях, но есть подозрения-что Hopac тоже аллоцирует. Ты вроде опытный гопаковед-может выскажешь экспертное мнение? Упарываться в low latency конвеер собственного производства из HFT-стрельба из пушки по воробьям, он точился под low latency и zero allocation, а не эффективную утилизацию CPU
Сорян. Тут я не помощник. Мы гопак юзаем не для скорости, а для управления сложностью. И каждый раз, когда мы начинаем упираться в производительность, я генерирую ещё более сложное решение с использованием того же гопака. Т.е. это чем-то олимпиадное программирование напоминает, когда вместо тупово задрачивания на байты (которое часто не работает) ты собираешь структуру данных строго под конкретную задачу. А в ситуациях вида "Извините, данная задачка только для C/C++/Delphi, потому что остальные умирают на чтении данных", я передаю задачу кому-нибудь другому, желательно не своему. Не знаю как у вас, но у мя в провинции универы преимущественно готовят байтоёбов, как наиболее дешёвый и практически самозарождающийся юнит. За ними даже следить особо не надо, загнал в PBT-стойло, пусть мастерит себе что хочет на своём ассемблере. Если тесты проходит - решение можно пускать в прод, читать я его не буду. У меня куда больше проблем с поиском соразмерного жонглёра. Гопак с Garnet я скрещивал. Для моих недоигр и заковыристых UI хватает более чем. Просадки по перфу я не замечал, но опять же, я ECS юзаю не для скорости, а всё для того же жонглирования и создания вау/киллер-фич. Самая медленная часть моих приложений - это всё ещё пользователь, чем быстрее я дотащу до него необходимую информацию в нужной проекции, тем быстрее он выполнит свою задачу. Так что про аллокации тут лучше спрашивать у тех, кто хотя бы использует это слово в своей речи.
Обсуждают сегодня