AkshitGarg's comments

AkshitGarg | 1 year ago | on: How much memory do you need in 2024 to run 1M concurrent tasks?

I feel this benchmark compares apples to oranges in some cases.

For example, for node, the author puts a million promises into the runtime event loop and uses `Promise.all` to wait for them all.

This is very different from, say, the Go version where the author creates a million goroutines and puts `waitgroup.Done` as a defer call.

While this might be the idiomatic way of concurrency in the respective languages, it does not account for how goroutines are fundamentally different from promises, and how the runtime does things differently. For JS, there's a single event loop. Counting the JS execution threads, the event loop thread and whatever else the runtime uses for async I/O, the execution model is fundamentally different from Go. Go (if not using `GOMAXPROCS`) spawns an OS thread for every physical thread that your machine has, and then uses a userspace scheduler to distribute goroutines to those threads. It may spawn more OS threads to account for OS threads sleeping on syscalls. Although I don't think the runtime will spawn extra threads in this case.

It also depends on what the "concurrent tasks" (I know, concurrency != parallelism) are. Tasks such as reading a file or doing a network call are better done with something like promises, but CPU-bound tasks are better done with goroutines or Node worker_threads. It would be interesting to see how the memory usage changes when doing async I/O vs CPU-bound tasks concurrently in different languages.

AkshitGarg | 4 years ago | on: CPython's main branch running in the browser with WebAssembly

Yep you need to specify the maximum memory amount up-front. Its defined as "webassembly memory pages". Each page is 64kb. You need to specify an initial and a maximum amount. The webassembly module can call memory.grow() to grow it by a page until it reaches the maximum. Though you can't "un-grow" or decrease the amount of allocated memory.

AkshitGarg | 4 years ago | on: Tree Sitter and the Complications of Parsing Languages

I grew up with fully fledged syntax highlighting, but I still prefer to use really minimal themes as I find them to reduce cognitive overhead and eye strain.

It was hard for the first few hours, but then I eventually got used to it, and now I can't use anything else.

I know this is not quite as extreme as working without syntax highlighting :)

AkshitGarg | 4 years ago | on: Tree Sitter and the Complications of Parsing Languages

While I don't fully disable syntax highlighting, I use a minimal theme [0,1] that only has highlighting for comments, strings and globals. It reduces eye strain for me, and I never find myself relying on highlighting to navigate through code.

LSPs provide an "outline" which can be very useful to navigate through code. I find "jump to symbol" function in my text editor to be faster than scanning all of the code to find the line.

Also most themes dim the comments, but IMO if something in the code needed an explanation, it should be brighter, not dimmer.

[0]: https://github.com/tonsky/sublime-scheme-alabaster

[1]: https://github.com/gargakshit/vscode-theme-alabaster-dark

page 1