3 ms·
If it is indeed faster, my gut is that it wasn't generic, it was "generic" hah. Ie runtime reflection was used instead of true compile-time generics. Runtime re
by lijogdfljk 5y ago
If it is indeed faster, my gut is that it wasn't generic, it was "generic" hah. Ie runtime reflection was used instead of true compile-time generics. Runtime reflection has a cost, and is (was!) one the strongest arguments against Go. All powerful "generic" code you'd write in Go heavily relied on reflection over interfaces that caused memory behavior commonly associated with worse performance.
Compile-time generics can often perform similar behavior but with a far better memory layout resulting in better performance.
Purely speculation though about `chan`, i have no clue.
- dfawcus 5y agoHave a look at the runtime, on my system the code is in /usr/local/go/src/runtime/chan.go There are some reflection calls in there, together with mutex lock/unlock and calls to 'typedmemmove' which seems to involve the use of memory barriers (mbarrier.go in the same directory).