2 ms·
Of course it is. In many languages that don't have microthreads baked in, this is not straightforward. You either have to use OS threads, which have a way hig
by the_duke 10y ago
Of course it is.
In many languages that don't have microthreads baked in, this is not straightforward.
You either have to use OS threads, which have a way higher overhead in memory and context switching costs and are not trivial to get right. Or you use some async IO framework with callbacks or the event based OS apis directly, which is also FAR from trivial to get right.
Do you really want to think about memory fences and context switching when writing concurrent code? I don't. Of course you should be aware of how it works underneath though.
- gvb 10y agoThe problem with the article is Amdahl's law: he is speeding up the part of the code that takes a small fraction of the time and handwaving the bottleneck that takes most of the time. "Currently the bottleneck is writing to the file system..." (and then the rest of the paragraph makes no sense at all). "We cannot do writing to disk from several threads for the following reasons..." - so his threading speeds up everything except the bottleneck that takes all the time.
- the_duke 10y agoI highly doubt that the disk writes were the original bottleneck. It probably is the new bottleneck, after parallelizing the data fetching and database IO. I agree that the article has some flaws, though.