nbsande

4 ms·

1.
by nbsande 10mo ago
> With more than 5 million downloads since its launch, the app has helped block more than 3.7 million stolen or lost mobile phones, while more than 30 million fraudulent connections have also been terminated. I might be reading this wron
2.
by nbsande 1y ago
While having the same code for sync and async sounds nice, monkey patching code at runtime seems hacky. Any library that wants to use a lower level implementation of network calls would need to handle the monkey patching themselves i assume
3.
by nbsande 2y ago
The idea is to map N tasks to M threads. This is useful more than just when you needd more threads than the OS can spin up. As you scale up the number of threads you increase context switching and cpu scheduling overhead. Being able to sche
4.
by nbsande 2y ago
Having too many threads all running at the same time can also cause a performance hit, and I don't mean hitting the OS limit on threads. The more threads you have running in parallel(remember this is considering a GIL-less setup) the m
5.
by nbsande 2y ago
The use case I wrote it in mind with is FastAPI. In that case, there wouldn't be any change to the Python code. You'd just use a different ASGI server that would use this sort of multithreaded event loop. So instead of running it
6.
by nbsande 2y ago
Hard agree. If you want resource efficiency and high performance you're probably better off looking to lower level languages most of the time. In my experience FastAPI usually gets used by teams that need a server done quickly and simp
7.
by nbsande 2y ago
Hmmm. That would indeed be better. Seems like an interesting experiment to try and implement virtual threads for python!
8.
by nbsande 2y ago
run_in_executor is pretty powerful for running sync code in async code, but my use case was more making async code utlize the cpu better. I think, just using run_in_executor would add a lot of complication and changes to how you use async a
9.
Show HN: Bringing multithreading to Python's async event loop(github.com)
82 points by nbsande 2y ago|46 comments
10.
by nbsande 2y ago
If I'm understanding your point correctly that wouldn't prevent them from offering higher ram specs for the lower storage eg. 512 gig macs. So it seems like it is just price gouging
11.
by nbsande 3y ago
The large(100k tokens) context window together with the fact that it can actually use the information in that context window. From personal experience other models including open ai fail to properly answer when provided large(more than 5k t
12.
by nbsande 5y ago
That's not strictly true. I'm sure thst GitHub contributed to the awareness of git among and less technically experienced especially in recent years, but use of version control systems has always been the norm in mid to large cod
13.
by nbsande 5y ago
Keeping support for near 20 year old consumer grade machines in the kernel seems ridiculous to me. Doing so would bloat the size of the kernel even more than it already is. The more code you have the easier it is for bugs and vulnerabiliti