Comments 7
Go известен как быстрый и эффективный язык для бэкенда
obfs4proxy на роутерах съедает вообще всю память. https://github.com/openwrt/packages/issues/24880
Простите, а на cpu\gpu тоже так стенку можно приподнять? Есть игра Powder Toys, там не такие разрешения а тормозит даже на топовом железе если прям адово что-то взрывать. Игра как раз на частицах основана. Их там конечно, миллионы, но не такие бешеные как у вас. Или я ошибаюсь?
Не гоутист и сиё:
"Но если переписать вот так:
for i := job.startIndex; i < job.endIndex; i++ { p := &particles[i] p.x += p.dx}Получается заметный прирост. Логично:"
Не выглядит логичным. Как?
Грубо: Вв го обращение к слайсу по индексу - это синтаксический сахар с проверкой границ слайса. В исходном варианте - два обращения и две проверки.
В первом примере мы 2 раза обращаемся по индексу массива, во втором только один раз. Го в данном случае каждый раз совершает bounds-check для того, чтобы какая-то Go-рутина не изменила массив так, что i попадет за пределы массива. Обычно в стандартных библиотеках go это делается чуть иначе: используется паттерн _ = slice[i], но вариант с адресом тоже рабочий. Вообще было бы неплохо до цикла сделать проверку на то, что jobs.startIndex не выходит за пределы массива, если алгоритм позволяет
Только вчера была статья, как в C# можно массивы нарезать на подслайсы и итерироваться уже по ним. Компилятор понимал, что индекс всегда внутри границ, и полностью убирал проверки. Разве в го нет подобного?
например:
var jobParticles = particles[job.startIndex..job.endIndex]
for &p := jobParticles {
p.x += p.dx
}
Насколько быстр Go? Симуляция миллионов частиц на смарт-ТВ