[1] https://blogs.nvidia.com/blog/google-cloud-agentic-physical-...
3,479 karma · joined April 19, 2016
[1] https://blogs.nvidia.com/blog/google-cloud-agentic-physical-...
Then the only thing remaining is convincing a critical mass that development now happens over at `Jeffrey-Sardina/systemd` on GitHub.
class Foo:
__slots__ = ("a", "b")
a: int
b: float
there are multiple issues with Python that prevent optimizations:* a user can define subtype `class my_int(int)`, so you cannot optimize the layout of `class Foo`
* the builtin `int` and `float` are big-int like numbers, so operations on them are branchy and allocating.
and the fact that Foo is mutable and that `id(foo.a)` has to produce something complicates things further.
The rest is AI-fluff:
> This isn't about optimizing for humans. It's about infrastructure
> But the bottleneck was never creation. It was always verification.
> For software, the load-bearing interface isn't actually code. Code is implementation.
> It's not just the Elixir language design that's remarkable, it's the entire ecosystem.
> The 'hard' languages were never hard. They were just waiting for a mind that didn't need movies.
* Prefer an issue over a PR (after iterating on the issue, either you or the maintainer can use it as a prompt)
* Only open a PR if the review effort is less than the implementation effort.
Whether the latter is feasible depends on the project, but in one of the projects I'm involved in it's fairly obvious: it's a package manager where the work is typically verifying dependencies and constraints; links to upstream commits etc are a great shortcut for reviewers.
In Spack [1] we do one layer per package; it's appealing, but I never checked if besides the layer limit it's actually bad for performance when doing filesystem operations.
For that you need one prefix per installation, which is what Nix, Guix, and Spack do.
Looking back, I think the tooling Julia had from the start, combined with the REPL, made it actually really nice to fix these performance issues. Much better than compiling and linking a binary and running it through some heap profiler tool. You could simply do
julia> @time f()
x.y seconds (N allocations: M bytes)
and iteratively improve part of the code base instead of profiling the entire application.(To be fair: back then escape analysis was not implemented in the compiler, and it was hard to avoid silly allocations)
MS_dd "$0" $offset $s | eval "gzip -cd" | UnTAR t
Where MS_dd()
{
blocks=`expr $3 / 1024`
bytes=`expr $3 % 1024`
dd if="$1" ibs=$2 skip=1 obs=1024 conv=sync 2> /dev/null | \
{ test $blocks -gt 0 && dd ibs=1024 obs=1024 count=$blocks ; \
test $bytes -gt 0 && dd ibs=1 obs=1024 count=$bytes ; } 2> /dev/null
}
Edit: this is apparently packaged with Makeself, and various sources report issues with rust-coreutils. For example https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...