Hooray, my IPv6 parser is mostly working, and only missing the final cursed case.

It's done. By god, it's done.

I mean, parseIPv6 is also awful and embarassing and much worse than the stdlib implementation right now. But is it at least faster than the stdlib?
Ope never mind, other tests are failing still. Bah.
lol, fuck. Not only is it 50% slower than the stdlib's parser, it's also not alloc-free.
oh, it's because it's benchmarking parsing a zone, and we have to intern the zone... I think.
Yess. For IPs without a zone, my parser is faster and alloc-free. Not hugely faster mind you.
I guess if you squint, it's about as good as the IPv4 parser. It has to touch 4x more bytes, so just under 4x slower isn't that bad.
That said, I'm pretty sure my code is a branch predictor's nightmare right now, not to mention it's entirely unreadable even by my low standards. Needs another round of improving, now that it passes tests.
I think it's time to checkpoint and play Elite Dangerous tonight, but the plan for tomorrow is to see if I can't turn this into a more explicit state machine, so that the code is considering fewer possibilities at any one time.
In general, I think all IPv6s parse in 4 stages:
- Hex before ellipsis
- Hex after ellipsis
- Embedded IPv4
- Zone suffix

All but the first are optional, and the conditionals to decide which new state to transition to is a bit ugly...
... But I think within each state the "happy loop" condition is simple and should keep the CPU and branch predictors pretty happy.
Current WIP, as I pack in for tonight to go play Elite: https://t.co/acwEFavxQi

WARNING: side-effects may include eye bleeding and stomach ulcers.
It also still has a bunch of debugging code in it, the comments may not match the code any more, and I haven't yet iterated on the benchmarks and SSA to see what hand-inlining was actually productive vs. harmful. So it's all hand-inlined, in the worst possible way.
The code's definitely not getting submitted like this, but that's my hacking process I guess :)

More from Internet

Many conversations happening on #WhatsApp (WA) groups about new #WhatsAppPrivacyPolicy .
This thread has arguments to help ditch WA & move to @signalapp:
https://t.co/En4fe9VxUN
Share, use, copy-paste, modify with understanding as you deem fit on any platform in whole or part
1/n

Note: No affiliations, conflict of interest
Info presented with NO bias, prejudice, malice or indemnity.
Open to corrections: individual tweets may be deleted, tweets added to thread or corrected as replies.
Points that are unclear or uncertain are marked with "(?)".
2/n

CONTENT OF WA MESSAGES SHALL REMAIN ENCRYPTED END TO END.
BUT, there's data: contacts, group affiliations, co-affiliations, locations (live?), frequency of contacts, *tags* generated when we send or forward a message or file to contacts or groups, links, clicks on links, etc.
3/n

It is unclear whether this data is anonymized.
NOTHING in latest policy *prevents* the collection, retention, sharing or sale by FaceBook (FB: owner of WA) of this data in part or whole whether with identifying information or anonymized.
Meme source:
https://t.co/nMDTUlb0rl
4/n


Companies need to make money & generate profits:
To create software, install & maintain infrastructure.
Google, FB, Insta, Amazon etc sell data created from our content & data generated from our interactions (searches, clicks, purchases etc).
This makes many uncomfortable.
5/n

You May Also Like