Chris DiBona, previously an editor at Slashdot, now the Open Source Program Manager at Google, announced today that Google has launched its Google Code site, where it has placed some of its contributions back into the Open Source community at SourceForge!
The initial list consists of four projects:
- google-coredumper: CoreDumper — “The coredumper library can be compiled into applications to create core dumps of the running program, without termination. It supports both single- and multi-threaded core dumps, even if the kernel doesn’t natively support for multi-threaded core files.”
- google-sparsehash Sparse Hashtable — “This project contains several hash-map implementations in use at Google, similar in API to SGI’s hash_map class, but with different performance characteristics, including an implementation that optimizes for space and one that optimizes for speed.”
- google-goopy: Goopy/Functional — “Goopy Functional is a python library that brings functional programming aspects to python.”
- google-perftools: Perftools — “These tools are for use by developers so that they can create more robust applications. Especially of use to those developing multi-threaded applications in C++ with templates. Includes TCMalloc, heap-checker, heap-profiler and cpu-profiler.”
Three of the four are of interest to me: coredumper, sparsehash, and perftools.
For a long time, I’ve wanted better coredump capability in Linux, especially for multi-threaded applications such as AOLserver. Google’s contribution could “solve” that problem for me, which would be fantastic. Right now, it’s very difficult to troubleshoot a multi-threaded application on Linux because of this lack of capability, and gdb’s “gcore” just doesn’t cut it. Perhaps the Linux and GDB teams can integrate Google’s contribution back into their respective codebases; we’ll see.
Google’s sparse hashtable implementation could yield some performance improvement to Tcl which makes extensive use of hashtables. I’d like to see if I can use the Google sparsehash implementation as a drop-in replacement for the Tcl implementation and see what the benchmarks say. This could be big.
Google’s perftools is somewhat of a misnomer, since the big selling point is their improved memory allocator which is supposedly “[the] fastest malloc we’ve seen[, and] works particularly well with threads and STL.” This could displace the Tcl threaded memory allocator, if performance really is superior, or could be used by the Tcl threaded memory allocator for an additional performance boost. It should be fun experimenting and benchmarking it.
It’s nice to see Google publish some really valuable stuff back to the Open Source community instead of just lamely throwing us a bone like IBM. This is definitely consistent with Google’s “do no evil” philosophy.
Man, this is just awesome. It gives me a whole new range of toys to play with. It’s like Christmas in March!








November 19th, 2009 at 8:35 pm
xy: If you tell me what distribution and version you're interested in, I can try building x86_64 binaries.
November 19th, 2009 at 8:22 pm
Ash: You're right, that's the only actual meaningful measurement - one person's performance before and after. It makes sense that Dvorak ...
November 19th, 2009 at 11:35 am
Has anyone successfully created a x86_64 build of convcharcount.la and convcharcount.so? I'd love to use this plugin, but not ...
November 19th, 2009 at 4:01 am
[...] The original posting is from Dossy’s Blog: What is GIMP’s equivalent of Photoshop’s Median filter? [...]
November 19th, 2009 at 1:30 am
I think the only way to solve this argument is for as many people as possible to list their typing ...