RaisingSpear

16 ms·

1.
by RaisingSpear 2y ago
From memory, the SpacemiT K1 doesn't support extensions like Zvkt? EDIT: okay, looks like the official documentation lists it, but many places I looked didn't. Maybe it wasn't being detected in cpuinfo?
2.
by RaisingSpear 2y ago
If you scale up the multipliers, you should be able to eliminate the variable shift, which would reduce the lookup table to 512 bytes.
3.
by RaisingSpear 2y ago
For CPUs that support AVX-512 VBMI, there's a faster reciprocal-based approach: https://avereniect.github.io/2023/04/29/uint8_division_using... A VBMI2 example implementation can be found in the function
4.
by RaisingSpear 2y ago
I suspect Intel uses 32x32b multipliers instead of his theorised 16x16b, just that it only has one every second lane. It lines up more closely with VPMULLQ, and it seems odd that PMULUDQ would be one uOp vs PMULLD's two. PMULLD is pr
5.
by RaisingSpear 2y ago
> Does every dev need to write the same line now? Yes. > Or should your one-liner be a library? Definitely not. Particularly if I can write the one-liner faster than it takes one to search, check, include and install the library.
6.
by RaisingSpear 2y ago
Yeah, you can write it in less than a minute: const tryNew = (f, ...a) => { try { return new f(...a); } catch(x) { return undefined; } }; const myUrl = tryNew(URL, ' http://example.com/ ');
7.
by RaisingSpear 2y ago
Search engines: they scrape the web, but get narky when scraped themselves.
8.
by RaisingSpear 2y ago
Tangentially related, but I've had a case where GCC 9.4.0 shipped a broken arm_acle.h header [ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100985 ] - code which includes the header would always fail to compile. Sin
9.
by RaisingSpear 2y ago
I think we're talking past each other a bit here. If I were trying to phish someone, I wouldn't attack the public key crypto part, so how domains come into play during authentication doesn't matter. I'd just grab the &q
10.
by RaisingSpear 2y ago
From my understanding, FIDO isn't MFA though (the authenticator may present its own local challenge, but I don't think the remote party can mandate it). There's also the issue of how many sites actually use it, as well as how
11.
by RaisingSpear 2y ago
The phisher can just pass on whatever you sign, and capture the token the server sends back. Sure, you can probably come up with some non-HTTPS scheme that can address this, but I don't see any site actually doing this, so you're
12.
by RaisingSpear 2y ago
> That's why I qualified it with "certificate-based". The private key never leaves the device Except that phishing doesn't require the private key - it just needs to echo back the generated token. And even if that is
13.
by RaisingSpear 2y ago
> I don't think phishing is such an obscure scenario. For a typical person, maybe, but for a tech-minded individual who understands security, data entropy and what /dev/random is? And I don't see how MFA stops phishin
14.
by RaisingSpear 2y ago
But password managers typically don't send keyboard commands to fill in a password, so a physical device would be useless. > There are plenty of scenarios where MFA is more secure than just a strong password. And how realistic are t
15.
by RaisingSpear 3y ago
I don't quite understand what you're saying, but it should be possible to infer the length from the number of bytes received. Assuming n is an integer: * 5n bytes received = 4n bytes data * 5n+1 bytes received is [invalid]
16.
by RaisingSpear 3y ago
Padding is actually not really necessary in base64, as you can infer the length from the number of characters received. Unfortunately for Z85, they made the highly questionable decision to use big-endian, which means it can't take base
17.
by RaisingSpear 3y ago
> The four octets SHALL be treated as an unsigned 32-bit integer in network byte order (big endian). The five characters SHALL be output from most significant to least significant (big endian). Why oh why??! If it were little endian, you
18.
by RaisingSpear 3y ago
Did the challenge limit submissions to only using SSE2? Seems odd, given the prevalence of SSE4.2 support. PMULUDQ is in SSE2, though I haven't checked if that's usable for the problem here. There's also PMULLD in SSE4.1 if
19.
by RaisingSpear 3y ago
POPCNT doesn't exist in AVX prior to Icelake, so using other techniques there is sensible. Also, that's POPCNT, not LZCNT.
20.
by RaisingSpear 3y ago
> There are some times when you're doing these operations in large vector types (like AVX), in parallel, when falling back to the SWAR techniques can actually be faster because of limited bandwidth on the port for micro ops in popcn
21.
by RaisingSpear 3y ago
> if your computer ever gets compromised If that happens, nothing will save you. The malware can just grab your session tokens whenever you log in, then do whatever it pleases.
22.
by RaisingSpear 3y ago
> So far I couldn't exceed 1 GB/s/core [4], so more research is needed. If you have any ideas - I am all ears! I don't know much about the space you're working in, but some things I'd point out: * 32b and 64
23.
by RaisingSpear 3y ago
> Under no circumstances should FLAC level 5 decode be faster than FLAC level 0 decode. I don't know about FLAC, but from my knowledge of compression, this result seems sensible to me. Smaller file = less bits to process = faster.
24.
by RaisingSpear 3y ago
Certainly, if your aim is the simplest code with no regard to compression, you could achieve a PNG writer with a small amount of code. In such a case, you could also skip the PNG filtering as well (whilst for my case, you wouldn't want
25.
by RaisingSpear 3y ago
Many PNG compressors allow you to specify the zlib compression level, where 0 = no compression. This will effectively give you an uncompressed image, perhaps with some format overhead. Your math is a bit off - a 1024x1024 at 32bpp would be
26.
by RaisingSpear 3y ago
It's most definitely not free. It'd consume fetch bandwidth, decode/rename/scheduler slots, an execution port etc. The comparison here is: ((v ^ 0x303030) * 0x640a0100) >> (len << 3) against: table[(((v >
27.
by RaisingSpear 3y ago
Your description is oddly specific. Maybe it's exactly like that, or maybe there's some variation to it, but the problem here has been simplified to make it more approachable.
28.
by RaisingSpear 3y ago
Adding the length means another shift+or operation at minimum. I already think this is slower than the technique presented in the article, and this would make it worse. It's an interesting idea, but I don't see it being practical
29.
by RaisingSpear 3y ago
I can run current Linux distros on 15 year old hardware without issue. If the vendor wants to drop support earlier, that's up to them, but it's a reason why people want open drivers. Also, local stores around me still sell new GT
30.
by RaisingSpear 3y ago
The '& 0xfff' eliminates the highest byte, so it doesn't matter what it is. Your code doesn't handle the 'length' parameter, so the problem isn't the highest byte, it's bytes beyond 'length&#

More ›