sgeisenh (u/sgeisenh)

sgeisenh commented on Fun with uv and PEP 723 cottongeeks.com/articles/... · Posted by u/deepakjois

AstroJetson · 2 months ago

> uv is an extremely fast Python package and project manager, written in Rust.

Is there a version of uv written in Python? It's weird (to me) to have an entire ecosystem for a language and a highly recommended tool to make your system work is written in another language.

sgeisenh · 2 months ago

Similar to ruff, uv mostly gathers ideas from other tools (with strong opinions and a handful of thoughtful additions and adjustments) and implements them in Rust for speed improvements.

Interestingly, the speed is the main differentiator from existing package and project management tools. Even if you are using it as a drop-in replacement for pip, it is just so much faster.

sgeisenh commented on TPU Deep Dive henryhmko.github.io/posts... · Posted by u/transpute

barrkel · 3 months ago

LLMs are generally deterministic. The token sampling step is usually randomized to some degree because it gets better results (creativity) and helps avoid loops, but you can turn that off (temp zero for simple samplers).

sgeisenh · 3 months ago

This is an oversimplification. When distributed, the nondeterministic order of additions during reductions can produce nondeterministic results due to floating point error.

It’s nitpicking for sure, but it causes real challenges for reproducibility, especially during model training.

sgeisenh commented on Things Zig comptime won't do matklad.github.io/2025/04... · Posted by u/JadedBlueEyes

the__alchemist · 5 months ago

Maybe this is a bad place to ask, but: Those experienced in manual-memory langs: What in particular do you find cumbersome about the borrow system? I've hit some annoyances like when splitting up struct fields into params where more than one is mutable, but that's the only friction point that comes to mind.

I ask because I am obvious blind to other cases - that's what I'm curious about! I generally find the &s to be a net help even without mem safety ... They make it easier to reason about structure, and when things mutate.

sgeisenh · 5 months ago

Lifetime annotations can be burdensome when trying to avoid extraneous copies and they feel contagious (when you add a lifetime annotation to a frequently used type, it bubbles out to anything that uses that type unless you're willing to use unsafe to extend lifetimes). The solutions to this problem (tracking indices instead of references) lose a lot of benefits that the borrow checker provides.

The aliasing rules in Rust are also pretty strict. There are plenty of single-threaded programs where I want to be able to occasionally read a piece of information through an immutable reference, but that information can be modified by a different piece of code. This usually indicates a design issue in your program but sometimes you just want to throw together some code to solve an immediate problem. The extra friction from the borrow checker makes it less attractive to use Rust for these kinds of programs.

sgeisenh commented on Levels of configuration languages beza1e1.tuxen.de/config_l... · Posted by u/kaycebasques

sgeisenh · 5 months ago

> Don't waste time on discussions within a level.

I disagree with this. YAML has too many footguns (boolean conversions being the first among them) not to mention it is a superset of JSON. Plain old JSON or TOML are much simpler.

sgeisenh commented on A write-ahead log is not a universal part of durability notes.eatonphil.com/2024-... · Posted by u/todsacerdoti

eatonphil · a year ago

Good catch! That was a think-o. I've swapped it around so that semaphores are signalled after the fsync.

sgeisenh · a year ago

Thanks for the quick response, and for the nice write up. I thoroughly enjoy the python-like pseudocode, it was the main reason I was able to pick that out reasonably quickly!

sgeisenh commented on A write-ahead log is not a universal part of durability notes.eatonphil.com/2024-... · Posted by u/todsacerdoti

sgeisenh · a year ago

In the pseudocode snippet that introduces a WAL, the semaphores are signaled before the fsync occurs. This seems like a mistake but maybe there’s a good reason to do this that I am missing?

Edit: it looks like this is the case in the first batched fsync example, as well.

sgeisenh commented on From bare metal to a 70B model: infrastructure set-up and scripts imbue.com/research/70b-in... · Posted by u/bblcla

bblcla · a year ago

This part in particular caught my eye:

> Step 2: Diagnosing broken machines

> As is typical in setting up large GPU clusters, we found that about 10% of the machines failed to boot, mostly due to physical issues with the servers. Some issues we encountered included: unconnected or miswired Ethernet cables, hardware issues in iDRAC, broken power supply units, bad NVME (nonvolatile memory express) drives, missing internal wires, and network cards or GPUs failing to show up.

This is a crazy high failure rate. Is this standard for traditional data centers too?

sgeisenh · a year ago

I did some of the work in the post (though mostly post-setup).

Speaking in generalities: the initial failure rates of these units are much higher than those of traditional non-GPU machines.

In general, the failure rates decline significantly during the operating life of hardware. So you deal with a bunch of issues up front that you try to resolve to reach a much more stable state.

There was a recent Meta engineering blog post that echoed some of our own experiences wrangling GPUs and high performance networks: https://engineering.fb.com/2024/06/12/data-infrastructure/tr...

sgeisenh commented on Use Rails jmduke.com/posts/microblo... · Posted by u/mscccc

cushychicken · a year ago

This article is just as valid if you ran :%s/Rails/Django/g.

I use Django to run both www.fpgajobs.com and www.firmwarejobs.com and love it.

sgeisenh · a year ago

You may want to add some moderation features or otherwise increase friction for adding job postings for www.firmwarejobs.com because the very first listing that I see when I load the page is "Doing your mom".

sgeisenh commented on We need to talk about parentheses (2020) andreyor.st/posts/2020-12... · Posted by u/precompute

kleiba · 2 years ago

> This code does exactly the same thing as Rust code

Except it doesn't - because after the final parenthesis of the Lisp snippet, the let-binding is finished, i.e., the introduced variables are no longer in scope. That is not the case after the end of the last line in the Rust example.

The whole point of parentheses is to mark where something starts and where it ends. Here, it is where the scope of the let-defined variables starts and ends. Without some sort of "parenthesizing", there might be a start, but it's much harder to mark where something ends.

sgeisenh · 2 years ago

I think it's more subtle than that. Rust has a notion of non-lexical lifetimes (https://rust-lang.github.io/rfcs/2094-nll.html) and the compiler often completely avoids the use of the stack for small, trivially droppable values, regardless of their lexical scope. In some ways, `let` in Rust is a more C-like variant of the `let ... in ... end` construct from OCaml.

Not to mention that you can always introduce a new lexical scope with `{ ... }` in Rust code.