-
Notifications
You must be signed in to change notification settings - Fork 307
ForkedHashedBeaconState helpers #7903
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: unstable
Are you sure you want to change the base?
Conversation
Using `func` avoids a template expansion at every usage site and just looks nicer .. unlike earlier nim versions, good code is generated for `lent`. An additional benefit is that mutability semantics are preserved and the resulting value is immutable even when being accessed indirectly (unlike `addr`+`[]` which results in a `var`). No matter what, when iterating over validators we continue to be affected by: * nim-lang/Nim#25470 * nim-lang/Nim#25469
|
One nice aspect of the slight ugliness of nimbus-eth2/beacon_chain/spec/forks.nim Lines 987 to 1020 in f896feb
i.e. being a kind of explicit call helps discourage a bunch of |
yeah I thought about this but I think it's negligible - specially given the fact that all fields are at the same offset meaning that effectively, the case should go away, or almost at least. If there was any significant computation involved, I'd certainly agree. |
|
also, we don't use Forked* in tight loops anyway, typically .. ie everywhere where performance matters, we go |
Using
funcavoids a template expansion at every usage site and just looks nicer .. unlike earlier nim versions, good code is generated forlent.An additional benefit is that mutability semantics are preserved and the resulting value is immutable even when being accessed indirectly (unlike
addr+[]which results in avar).No matter what, when iterating over validators we continue to be affected by:
lentnot respected withforloop andarrayvalues nim-lang/Nim#25470forforces a copy of underlying instance nim-lang/Nim#25469