Hacker News: skavi

New comment by skavi in "F.02 Decommission"

skavi — Sat, 03 Oct 2026 17:38:40 +0000

i think you mean a word that’s not craven

New comment by skavi in "Gemini 4 Argon"

skavi — Thu, 01 Oct 2026 22:27:12 +0000

Do you know what wasn’t successful?

New comment by skavi in "Gemini 4 Argon"

skavi — Thu, 01 Oct 2026 22:26:11 +0000

Fuchsia is the only OS that uses that kernel.

Also, that was an easily citable doc line, but I think a more comprehensive look at the work done in Fuchsia shows it has or had ambitions to run on personal computers.

e.g.: fancy graphics stack, Linux compatibility layer, ideas about OS integrated cloud syncing, the original work on the Xi text editor.

New comment by skavi in "Gemini 4 Argon"

skavi — Wed, 30 Sep 2026 23:15:51 +0000

I’m more interested in whether it’s still a thing people want to work on rather than something people are forced to maintain.

New comment by skavi in "Gemini 4 Argon"

skavi — Wed, 30 Sep 2026 23:11:16 +0000

It wasn’t actually. From the docs for Zircon (Fuchsia’s kernel) [0]:

> Zircon targets modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation.

Fuchsia also had a Linux compatibility layer similar to WSL1 at some point. Might still be there?

[0]: https://fuchsia.dev/fuchsia-src/concepts/kernel/zx_and_lk

New comment by skavi in "Gemini 4 Argon"

skavi — Wed, 30 Sep 2026 20:27:57 +0000

Interesting to see a mention of Fuchsia on a big Google announcement. Is the project still truly alive? Are the ambitions still as grand? Is the team as stacked as it used to be?

Also, a link to the rust root of Zircon in case anyone else was interested: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/z...

New comment by skavi in "Updated Google Maps shows destruction of the city of Rafah"

skavi — Tue, 29 Sep 2026 07:20:52 +0000

if you mean that all war is unjustified, consider stating that plainly. if that's not what you mean, then perhaps there is some nuance left out of your statement.

New comment by skavi in "Fearless SIMD v1.0"

skavi — Fri, 25 Sep 2026 00:39:17 +0000

Would anyone be able to compare this library's design to https://github.com/google/highway?

New comment by skavi in "Samsung is expected to more than double output of its HBM4 and HBM4E DRAM"

skavi — Sun, 20 Sep 2026 19:23:51 +0000

direct link: https://www.servethehome.com/micron-evolving-memory-architec...

New comment by skavi in "Jemalloc 5.4.0"

skavi — Sat, 19 Sep 2026 05:15:12 +0000

> Are you sure you don't just have an axe to grind? Because that is an exceedingly uncommon edge case. Typically you only have a few threads and you aren't inundating the allocator with requests thus it is unlikely to make any practical difference.

Totally fair, and I agree that you should only have a few threads (or TPC) and shouldn’t be inundating the allocator with requests. But I’m only grinding this axe because I’ve personally had to deal with a system that went against most of that guidance.

We ran far too many threads in a memory-constrained environment. Thread count was many multiples of core count.

I totally agree that this is “questionable territory”, but honestly, any application that’s outgrown the basic glibc malloc has made a few mistakes.

New comment by skavi in "Two parallel neural ectoderm progenitors contribute to the developing brain"

skavi — Sat, 19 Sep 2026 05:02:50 +0000

very naive question: does organ even have a strict enough definition for discussions like this to be worthwhile?

New comment by skavi in "Jemalloc 5.4.0"

skavi — Sat, 19 Sep 2026 01:47:42 +0000

> seems likely to be a wash at absolute best

maybe i give it too much weight, but:

> massive oversubscription of physical CPU cores (ie tens of thousands of threads) where TLS becomes utterly wasteful while also thrashing the cache

seems worth solving to me

New comment by skavi in "Comparison of Malloc() Algorithms"

skavi — Fri, 18 Sep 2026 17:41:25 +0000

yeah that’s a common mistake when evaluating tcmalloc. gperftools tcmalloc diverged quite a while ago. doesn’t have a lot of the fancier features of modern tcmalloc [0].

[0]: https://github.com/google/tcmalloc/blob/master/docs/gperftoo...

New comment by skavi in "Jemalloc 5.4.0"

skavi — Fri, 18 Sep 2026 17:28:41 +0000

my feeling is that the space efficiency gains are probably more significant than the reduction in core migration costs. many applications have far more threads than the system has cores.

New comment by skavi in "Jemalloc 5.4.0"

skavi — Fri, 18 Sep 2026 17:12:22 +0000

https://docs.kernel.org/userspace-api/rseq.html

cost for interruption in an rseq critical section is that the PC gets overwritten to the rseq abort entry point before the task is rescheduled. no management thread necessary.

should be fairly minimal cost, especially assuming interruptions in the critical section are rare.

New comment by skavi in "Jemalloc 5.4.0"

skavi — Fri, 18 Sep 2026 11:49:54 +0000

https://google.github.io/tcmalloc/rseq.html

i don’t believe rseq based cpu local caches require memory barriers on the fast path.

New comment by skavi in "Comparison of Malloc() Algorithms"

skavi — Fri, 18 Sep 2026 11:01:07 +0000

no article, sorry, grabbed the numbers from an old PR.

to confirm, you were using tcmalloc from https://github.com/google/tcmalloc and not from https://github.com/gperftools/gperftools, right?

the latter is a lot worse iiuc.

New comment by skavi in "Jemalloc 5.4.0"

skavi — Fri, 18 Sep 2026 10:45:55 +0000

i think we agree that per cpu caching seems superior. i’m looking for the other side of this. most allocators seem to have stuck with per thread.

New comment by skavi in "Jemalloc 5.4.0"

skavi — Fri, 18 Sep 2026 08:37:42 +0000

does anyone familiar with the art have thoughts on why only tcmalloc switched from thread caches to cpu caches? would it make linux behavior diverge too much from other platforms?

New comment by skavi in "Goose Programming Language"

skavi — Fri, 18 Sep 2026 08:13:07 +0000

https://github.com/aardappel/goose/blob/master/docs/tutorial...

this bit seems a bit messy.