Хотя вот сейас подумал, технически же память можно инициализировать не в момент выделения, а "на всякий случай" занулять в момент удаления/сборки мусора.
Хотя это кажется контр-продуктивным, поскольку это лишние операции записи, но, кажется, конкретно в данном случае это можно бы сработать.
Кажется, на пейдж фолты можно полагаться только при первом выделении памяти, далее же если рантайм не отказывается от переиспользования памяти или не переизобретает виртуальную память внутри себя(ни того, ни другого голанг не делает, насколько я знаю), то переиспользуемую память придется занулять.
Как это сделать без слоя виртульной памяти, лениво, по мере работы, я, признаться, не очень предствляю, потому что состояние занятости каждой ячейки все равно надо где-то трекать, если мы не можем положиться на то, что там будет либо ноль либо указатель.
В общем, я могу что-то упускать, но у меня есть большие сомнения в том, что в голанге есть гарантированные O(1) вместо O(тоже-N-но-не-такое-большое-как-с-полным-разовым-перехешированием).
Именно async/await практически нивелирует сложность для рядового разработчика, так как по сути, код выглядит и ведёт себя как синхронный,
Ну, а в жаве с гринтредами этот же код теперь выглядит и ведет себя точно так же как синхронный. Разработчику не надо знать о том, что там где "асинхронное", а что нет, рантайм скрывает это.
По сути это как раз async/await костыль. Да, лучше иметь async/await, чем не иметь ничего, но гринтреды(по крайней мере в том виде, в котором они реализованы в жаве и голанге) мощнее, чем async/await.
Хотя вот сейас подумал, технически же память можно инициализировать не в момент выделения, а "на всякий случай" занулять в момент удаления/сборки мусора.
Хотя это кажется контр-продуктивным, поскольку это лишние операции записи, но, кажется, конкретно в данном случае это можно бы сработать.
Кажется, на пейдж фолты можно полагаться только при первом выделении памяти, далее же если рантайм не отказывается от переиспользования памяти или не переизобретает виртуальную память внутри себя(ни того, ни другого голанг не делает, насколько я знаю), то переиспользуемую память придется занулять.
Как это сделать без слоя виртульной памяти, лениво, по мере работы, я, признаться, не очень предствляю, потому что состояние занятости каждой ячейки все равно надо где-то трекать, если мы не можем положиться на то, что там будет либо ноль либо указатель.
В общем, я могу что-то упускать, но у меня есть большие сомнения в том, что в голанге есть гарантированные O(1) вместо O(тоже-N-но-не-такое-большое-как-с-полным-разовым-перехешированием).
Как оно может быть O(1), если новый массив размера N все равно кто-то должен занулить?
Это O(n), если массив не какой-то фиксированной длины.
Ну, а в жаве с гринтредами этот же код теперь выглядит и ведет себя точно так же как синхронный. Разработчику не надо знать о том, что там где "асинхронное", а что нет, рантайм скрывает это.
По сути это как раз async/await костыль. Да, лучше иметь async/await, чем не иметь ничего, но гринтреды(по крайней мере в том виде, в котором они реализованы в жаве и голанге) мощнее, чем async/await.