cafxx

8 ms·

1.
Lowest, real-time On-Demand and Spot GPU prices across every cloud provider(gpu.atarimae.dev)
3 points by cafxx 2mo ago|0 comments
2.
by cafxx 9mo ago
Filed a CL for this, hopefully it gets merged ~soon. https://go-review.googlesource.com/c/go/+/729920
3.
by cafxx 9mo ago
That's not how it's implemented (it returns false if you're inside a Do() on a unsupported platform), although I agree the wording should be clearer.
4.
by cafxx 9mo ago
I find this example mildly infuriating/amusing: func Encrypt(message []byte) ([]byte, error) { var ciphertext []byte var encErr error secret.Do(func() { // ... })
5.
by cafxx 9mo ago
The point is that no-one is thinking to add knobs, or allow alternative GCs.
6.
by cafxx 9mo ago
> GOGC was introduced in Go 1.5 yes, that's quite literally what I meant by "GOGC has always been there". 1.5 was released 10 years ago, just 3 years after 1.0. So to summarize: there is one knob (that has been there from
7.
by cafxx 9mo ago
Your previous message was referring to Go "getting" knobs, but GOGC has always been there. The older GC algorithm won't stay, IIRC the plan is for it to be removed in 1.27 (it's kept for now just to give a fallback in ca
8.
by cafxx 9mo ago
I still would be wary, even in that case. Go does not guarantee that the address of an allocation won't change over the lifetime of the allocation (although current implementations do not make use of this). If you really store just ref
9.
by cafxx 9mo ago
Not sure what you are referring to. There are no knobs involved in the things I mentioned (aside from the one to enable the experiment, but that's just temporary until the experiment completes - one way or the other).
10.
by cafxx 9mo ago
> If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. A word of caution. If you do this and then you store pointers into that slice, the GC will likely not see them (
11.
by cafxx 9mo ago
There's a bunch of activity ongoing to make things better for memory allocation/collection in Go. GreenTeaGC is one that has already landed, but there are others like the RuntimeFree experiment that aims at progressively reduce th
12.
by cafxx 2y ago
I think that the idea of not initiating writeback immediately derives mostly from the days of spinning rust, where read latencies would be noticeably impacted if you initiated writeback too aggressively: reads, contrary to writes, are synch
13.
Show HN: Make your API cacheable and save millions: the new Mercari Master API(engineering.mercari.com)
1 points by cafxx 3y ago|0 comments
14.
Show HN: Mgo: build a single Go binary optimized for all GOAMD64 variants(github.com)
2 points by cafxx 3y ago|0 comments
15.
by cafxx 3y ago
Would be nice also if they fixed the ubiquitous "network errors" that happen approximately every single time...
16.
by cafxx 3y ago
Not to be the devil's advocate here, but almost certainly it can be the case that data was used to define heuristics (potentially using automated statistical methods) that a engineer then formalized as code. Without that data that spec
17.
by cafxx 3y ago
...or maybe Windows should just offer an API for marking a file for deletion once it's not in use anymore (I understand unlink semantics may not be possible, but that's not what my suggestion above is saying)
18.
by cafxx 3y ago
Or you could simply invoke a GC periodically (or every N times a key is removed from the map, or similar schemes). Another simple way, if we don't like the idea of triggering GCs manually,is to allocate the same buffer both off-heap an
19.
by cafxx 3y ago
Why not just allocating the blobs off-heap? (That is something you probably want to do anyway if it's cryptographic material, to avoid being at the mercy of the GC leaving copies around) ByteBuffer.allocateDirect should do that IIRC. T
20.
by cafxx 3y ago
'Oumuamua was closer to 8:1 https://en.wikipedia.org/wiki/%CA%BBOumuamua
21.
by cafxx 3y ago
In the example you linked it's comparing two threads reading from the same or separate cache lines, no? If so, that's not really the point I was referring to (as the two variables I mentioned as example are accessed by a single th
22.
by cafxx 3y ago
A point that AFAICT is not articulated in the article is why the two cached fields should be in their own dedicated cache line (e.g. why readIdxCached_ can not share the cache line with writeIdx_).
23.
Optimizing a Ring Buffer for Throughput(rigtorp.se)
3 points by cafxx 3y ago|0 comments
24.
by cafxx 3y ago
Yes, that's the whole point. I did not claim you can control every single module in the QR. I just said that you can get different QR codes for the same semantic content.
25.
by cafxx 3y ago
Yes, that's what I meant.
26.
by cafxx 3y ago
Sorry, yes, I should have clarified I meant "no-one has done it in the current batch of diffusion-based experiments". As you point out it has been done multiple times before, e.g. https://research.swtch.com/qart (
27.
by cafxx 3y ago
Sure, but as I mentioned it has absolutely nothing to do with the CRC calculation, that is what you claimed.
28.
by cafxx 3y ago
Also not sure the diffusion model has been taught yet that it could in some cases choose to deliberately ignore a (small) fraction of some of the elements/blocks, if it helps with composition. Or even better just wire up a QR decoder t
29.
by cafxx 3y ago
None of what I wrote impacts the CRC calculation.
30.
by cafxx 3y ago
The funny thing is that no-one AFAICT has realized that the same content can be encoded in different-looking QR codes. Beside the obvious (different error-correction levels), the content itself can be changed while maintaining its semantic

More ›