Quick'n dirty aarch64 benchmark: almost as fast as a CPU-accelerated sha2. Quite impressive!pic.twitter.com/UEoWOk0E1d
U tweetove putem weba ili aplikacija drugih proizvođača možete dodati podatke o lokaciji, kao što su grad ili točna lokacija. Povijest lokacija tweetova uvijek možete izbrisati. Saznajte više
Quick'n dirty aarch64 benchmark: almost as fast as a CPU-accelerated sha2. Quite impressive!pic.twitter.com/UEoWOk0E1d
And this is the portable compression function :) I expect the NEON implementation will eventually be a lot faster, but today it's not very well optimized. You can try it with --features=c_neon.
I am by no means an expert and I really want to learn more. As I recall from crypto classes, hash algorithms are typically not designed to be fast. Am I missing something?
Exactly what I thought, but I am more then welcome to someone educating me otherwise!
phew, finished porting the reference implementation to Go!https://github.com/lukechampine/blake3 …
Am I right in thinking it's faster because of the way it breaks up and processes the message. For instance, for short 1kb message, the graph indicates it's on par with Blake2b.
Yes, the main reason it's fast is that it's highly parallel, but for that parallelism to kick in it needs to have enough 1 KiB chunks to occupy your SIMD lanes and (if you enable multi-threading) CPU cores.
Have the algorithm been audited by independent security researchers?
Congrats! Is any information on performed security assessments available?
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.