3 ms·
It continues to amaze me how many workloads can be dominated by malloc() performance. In particular, last summer we at Joyent found that a production node.js l
by bcantrill 13y ago
It continues to amaze me how many workloads can be dominated by malloc() performance. In particular, last summer we at Joyent found that a production node.js load was surprisingly dominated by small object malloc()/free() performance -- and achieving maximum performance ultimately required not just adding a per-thread cache, but cycle bumming the hell out of it.[1] Point is: malloc() still very much matters, despite (or maybe because of) modern interpreted environments.
[1] http://dtrace.org/blogs/rm/2012/07/16/per-thread-caching-in-libumem/ http://dtrace.org/blogs/rm/2012/07/16/per-thread-caching-in-...
- seanmcdirmid 13y agoI am sort of horrified by a garbage collected VM that uses small malloc/free calls to manage memory. I also can't believe the linked article doesn't mention what VM the node.js code was running on. Edit: reading more of the linked articles, these benchmarks seem to be running on V8? Which seems to be the only platform that node.js runs on...facepalm. Still confused why V8 would be using standard malloc/free calls.
- akkartik 13y agomalloc doesn't have to suck: http://www.cs.umass.edu/%7Eemery/pubs/berger-oopsla2002.pdf http://www.cs.umass.edu/%7Eemery/pubs/berger-oopsla2002.pdf
- JoachimSchipper 13y agoIf you mean "lea malloc is pretty fast", ok; but going to regions, while an enormous win in some cases, is moving the goalpoints. (Still, thanks for posting the paper - the reaps concept is very nice. I did expect regions to win by more than they did, though. Oh well.)