HackerTrans
热门最新趋势评论往期问答秀出招聘

ibraheemdev

no profile record

提交

Astral 加入 OpenAI

astral.sh
1,489 分·作者 ibraheemdev·4个月前·901 评论

Cuckoo hashing improves SIMD hash tables (and other hash table tradeoffs)

reiner.org
79 分·作者 ibraheemdev·9个月前·1 评论

评论

ibraheemdev
·3个月前·讨论
Not the runtime per se, but cooperative scheduling has the advantage that tasks do not yield at adverse code points, e.g., right before giving up a lock, or performing an I/O request. Of course the lack of preemption has it's own downsides, but with thread-per-request you tend to run into tail latency issues much earlier than context switching overhead.
ibraheemdev
·3个月前·讨论
> OS threads are expensive: an operating system thread typically reserves a megabyte of stack space

Why is reserving a megabyte of stack space "expensive"?

> and takes roughly a millisecond to create

I'm not sure where this number is from, it seems off by a few orders of magnitude. On Linux, thread creation is closer to 10 microseconds.
ibraheemdev
·10个月前·讨论
It does make a difference of course if you're running fetch_max from multiple threads, adding a load fast-path introduces a race condition.
ibraheemdev
·10个月前·讨论
pip, PDM, and uv already support PEP751 [0] and were involved in the design process.

[0]: https://discuss.python.org/t/community-adoption-of-pylock-to...
ibraheemdev
·去年·讨论
> The message has some weird mentions in (alloc565), but the actual useful information is there: a pointer is dangling.

The allocation ID is actually very useful for debugging. You can actually use the flags `-Zmiri-track-alloc-id=alloc565 -Zmiri-track-alloc-accesses` to track the allocation, deallocation, and any reads/writes to/from this location.