@Jacob Christian Munch-Andersen
Programmer, mathematician, cryptographer, game developer.
Relays (1)
- wss://relay.ditto.pub – read & write
Recent Notes
In case someone feels the itch to buy new gaming equipment, but can't because everything is expensive:
Have you considered getting a new monitor?
Prices have dropped like crazy, a basic 27" 2560x1440 180Hz model start out at $120 US.
Have you considered getting a new monitor?
Prices have dropped like crazy, a basic 27" 2560x1440 180Hz model start out at $120 US.
nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqq2q3v2cfmwnz8nhmv3wvva5vgmmkdty0gd5kd7mpn9smkplzjuusts26t9 nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqpu3ryltaaqjym9gj5fpcv623edtfh2v...
@nprofile1q... @nprofile1q... I don't want to draw the conclusion too broadly, it is most certainly complicated, with a lot of "depends". I don't recall all that much about Go, but doesn't it allow you to make a simple array of structs? (Probably called something different.) That would have the same effect on garbage collection.
Of course struct-of-arrays can be faster regardless of language if your access pattern happens to favour that paradigm.
Of course struct-of-arrays can be faster regardless of language if your access pattern happens to favour that paradigm.
@nprofile1q... @nprofile1q... That is probably mostly an artefact of coding around the garbage collector. An array of 1M objects with 10 simple values each is 1000001 objects, whereas 10 arrays of 1M simple values each is 10 objects.
You have effectively broken garbage collection, but you have also reduced the number of objects that the collector has to consider so much that even a quite badly coded collector can't do much performance damage.
You have effectively broken garbage collection, but you have also reduced the number of objects that the collector has to consider so much that even a quite badly coded collector can't do much performance damage.
1
So, I was just casually checking my Gmail spam box, and i found an email from Google. Of course you would just think that this is some scammer impersonating Google, but everything checks out. It is from the google.com domain, SPF, DKIM and DMARC all pass.
The content of the email is telling me that "because EU" I get to configure whether or not particular Google services are linked.
I wonder how that made it to the spam folder.
#google #gmail #eu #regulation #antitrust
The content of the email is telling me that "because EU" I get to configure whether or not particular Google services are linked.
I wonder how that made it to the spam folder.
#google #gmail #eu #regulation #antitrust
@nprofile1q... I read your old post on key sizes, unfortunately still relevant: https://blog.cr.yp.to/20151120-batchattacks.html
I noted two points that it probably should mention, but doesn't:
1. That the issue also apply to random number generators, all cryptographic algorithms are vulnerable if their key stems from an RNG with 128 bits of state.
2. That mitigation is free. For most symmetric algorithms a change that increases key/state size does not have to increase computation.
I noted two points that it probably should mention, but doesn't:
1. That the issue also apply to random number generators, all cryptographic algorithms are vulnerable if their key stems from an RNG with 128 bits of state.
2. That mitigation is free. For most symmetric algorithms a change that increases key/state size does not have to increase computation.
@nprofile1q... No, it is the other way round, you literally limit yourself to the same value range as int24. 2^30 possible values go in, 2^24 possible values come out.
Floats already do exactly the thing you would want, and you get virtually unlimited range on top, you just have to not make the wrong type of transformation.
Look at it this way, you have already got a value that fits into the float buffer, there is no way you can get more precision by transforming that value.
Floats already do exactly the thing you would want, and you get virtually unlimited range on top, you just have to not make the wrong type of transformation.
Look at it this way, you have already got a value that fits into the float buffer, there is no way you can get more precision by transforming that value.
@nprofile1q... No, you have got plenty precision everywhere. Yes, a lot of it is too close to the camera to be of real benefit, but that is no more an issue than everywhere else you use floats and skip most of the possible value space. You have got a value in the range 0 to 1, so 2^30 different possibilities. If you reverse that then everything below ½ gets mapped to above ½, where there are only 2^23 possibilities. So you are left with only 2^24 possible states.
@nprofile1q... @nprofile1q... Ah, ok, that is what you mean. I'm still not quite sure why you would do that though. Maybe I don't understand exactly what you mean, but that sounds like a way of breaking floating point precision. If you map 0->1 to 1->0 that breaks the extra floating point accuracy near zero, which is crucial to the no-clip-plane thing we just discussed.
nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqykddq7nmfd8cd0hupl8fnsmmuhtg55zusm6de4fjecmrhsx4x97qx8hm63 nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpq76n3v8texjdy3l4dqr0527cxh7l255g...
@nprofile1q... @nprofile1q... The actual reason to prefer inverse Z is that when you interpolate Z values for a triangle, using linear Z values makes the interpolated values wrong in 3D space. But if you interpolate the reciprocals, it just works. I don't have an intuitive explanation for why it works, but it is really convenient.
@nprofile1q... @nprofile1q... You'd certainly use reverse Z with integer Z buffers. AFAIK that is what pretty much every game of the time does.
The internet is littered with the tale that the reason to reverse is to distribute the sparse precision of the Z buffer in a more useful way. It certainly distributes it in a different way when using integer Z buffers, but it is not so obvious that this way is more useful. If this was the only reason to use inverse Z I would probably be inclined to prefer linear Z.
The internet is littered with the tale that the reason to reverse is to distribute the sparse precision of the Z buffer in a more useful way. It certainly distributes it in a different way when using integer Z buffers, but it is not so obvious that this way is more useful. If this was the only reason to use inverse Z I would probably be inclined to prefer linear Z.
1