Is there a way not to burn quithub's LFS quota on github actions?
I have a repo with GBs of LFS data, and it looks like the checkout action downloads the entire thing every time it's triggered.
This is not only is extremely wasteful, but also gets expensive very quickly!
@dotstdy@wolfpld@castano Oh, that works now? I could have sworn last time I looked into it, it was almost literally a "We have GitHub Actions at home" meme.
@wolfpld@castano It looks like Hetzner is a better deal on dedicated vCPU slices. CCX13 is $15 for 2 vCPUs, 8 GB RAM, 80 GB disk, 20 TB traffic. BuyVM seems like a better deal if you want a lot of storage for cheap and "unlimited" bandwidth (personally not a fan of unlimited anything, when companies do that it usually means they're going to start throttling aggressively or fire you as a customer). Do you have good experiences with BuyVM?
Idle thought: if you cache the min/max key bounds (in a pair of arrays) along the descending path when you do an ordered search tree descent, you can binary search a correlated query key against the nested bounds in O(log(log(n))) time to use as a local root/LCA. In practice binary search isn't necessary for any realistic n, fast linear search is better if you can use SIMD. There are no chained data dependencies for the search, unlike restarting the tree descent from the top.
Mostly just found this amusing because it's rare to see log log complexity outside of vEB trees, x-fast/y-fast tries, etc, and there the nested logarithm is also because you're binary searching on the depth of a log-depth tree although in their case it's O(log(log(u)) where u is the size of the universe, not the number of keys in the tree.
Every once in a while there's a bug on YouTube where I get the comments for the wrong video and it's never not hilarious. Anyone else see this occasionally?
In this case I got the comments from a J Dilla track applied to a technical podcast. Sample comments:
"I listened to this on mushrooms, closed my eyes, and laid back on the couch."
"I recently found out that a vinyl can be made out of your ashes."
"His shit really have me ballin like a lil girl."
Must be one hell of a tech podcast to elicit those responses.
Work is both performance and liability^Wcorrectness oriented, and I noticed a common pattern is that we'll generate commands with a fully deterministic program (i.e., a function), reify the command stream, and act on the commands.The IO monad is real!
@pkhuong When I've looked at the release notes for different versions of io_uring I can see he's trying to put in some stuff for dependencies and I wonder if and when there's going to be something more general. Last I checked (which isn't that recently) your only option was to make one command dependent on the previous command with a flag bit. But that doesn't seem sufficient for e.g. A->B, A->C where you don't want C to have a false dependency on B just to depend on A.
@pkhuong It just seems like the story for every kind of "decoupled" command list API that you eventually want or need some more general way of expressing graph dependencies.
@zwarich@pkhuong It's funny to consider all the things people use on GPUs for things that could broadly be classed as "monadic actions". Most of them are not really monadic (although I think CUDA has some newer features where tasks can spawn tasks dynamically) in the traditional sense but they're essentially round-based: round 1 can emit commands to a command buffer which are executed in round 2, etc. You can do this with draw commands via indirect draw buffers.
@zwarich@pkhuong On consoles you could also just issue unified memory writes directly from shaders and patch jump targets in the middle of command buffers that were already queued for execution, etc.
@pkhuong Do you mean because the dependency graph does not expose pipelinining? Or it's the only way to achieve pipelining? You definitely want the graph API to support pipelining. If you use index-based back references to earlier commands it's no problem to execute in a pipelined manner, i.e. you require a pre-topologically-sorted graph so you can issue commands as they arrive if their dependencies are already satisfied.
@pkhuong Or was that problem with Azure just that their scheduler wasn't properly designed/implemented? On top of the topological sorting requirement, I think it would also be reasonable to only offer a specific sliding issue window so that the API user is responsible for some basic level of static scheduling so that you don't gunk up your dynamic scheduler's scoreboard with an unbounded pile of crap that won't be scheduled for an eternity.
@pkhuong I.e. it's not the scheduler's job to notice that after 199K serially dependent tasks at the start of the command list, you have 1K independent commands at the end of the list that could start early. If you want those to start early, the user must make sure they're sorted near the start of the list. Basically like an out-of-order CPU core.
@pkhuong Right, I guess that gets into a conversation we've had in the past about why schedulers need to be concerned with the right notion of forward progress, which is not really about individual tasks but something closer to user-level requests. And for dynamic scheduling where you can't do omniscient critical path scheduling of tasks even if you wanted to, focusing on a higher-level notion of requests/job progress can also help the user guide the scheduler towards the critical path, I guess?