Checking in everything. Yes this is a mess.
Some things aren't used. Lots of things are from older test runs from 6 months ago.

I built Lua 5.1.5 and 5.2.1 with clang O3. I told 5.1.5 to build with DLOPEN instead of DYLD.
I built as static libraries.
I built LuaHashMap also as a static library with O3.

clang++ -O3  src/stl_unordered_map.cc -o build/stl_unordered_map
clang++ -O3 src/stl_unordered_map_string.cc -o build/stl_unordered_map_string
clang -O3  -I/System/Library/Frameworks/Python.framework/Headers src/python_dict.c -o build/python_dict -framework Python
clang -O3 -I/System/Library/Frameworks/Ruby.framework/Headers -framework Ruby src/ruby_hash.c -o build/ruby_hash
clang  -O3 -lm `perl -MExtUtils::Embed -e ccopts` src/perl_hash.c -o build/perl_hash `perl -MExtUtils::Embed -e ldopts`
clang -O3 -framework Tcl src/tcl_hash.c -o build/tcl_hash
clang -O3 -I/usr/local/include/lua52 -lLuaHashMap52 -llua52 src/LuaHashMap.c -o build/LuaHashMap52
clang -O3 -I/usr/local/include/lua51 -lLuaHashMap51 -llua51 src/LuaHashMap.c -o build/LuaHashMap51

The Ruby test is very suspicious. I had some test code to assert the hash values and I think they failed. Also, the string test crashes around 3500 entries for me. Also, I think the Perl test is failing some of my asserts so that is a little suspicious too.

I ran using the nomalloc variation of the benchmark I wrote.

LuaJIT doesn't actually work. My original test numbers were borked. LuaJIT crashes after about 1GB of memory.

This test run is called output_first_*
The console output is console_output_first_all (which contains the Ruby crashes and a few suspect Perl lines).

It is run on an iMac i3 3.2GHz with 16GB of RAM.

I'm manually copy/pasting/splitting the results to split the int and str tests because of the Ruby crash.
Modified LuaHashMap benchmark to pre size hash to avoid resizing to see how the performance would change.
Working on access benchmarks (get for int, string) for exists, doesn't exists.
Ruby string test crashes.
Did quick check on string internalization option  for Lua and it shows large gains. Now I'm interested in string length optimizations.
Finished running the get tests.
Added Set tests to suite.
copied set template over access template because they are virtually identical, just with more stuff. I decided it's not worth optimizing the set test and forking because the automation scripts aren't cut out for it.
fixed stray character
Ran final data set.
All the get and set charts. Going to clean up the initial charts.
Re-did vaseline graphs (including size hint).
- reordered implementations so the colors would be more consistent with the later graphs
- Added the random memory profile. Delete profile wouldn't load in my browser so I gave up.
- Removed redundant const char*/std::string in integer tests (they don't use either)
Manually edited the legends to remove the std::string in the integer tests.
Manually edited the Lua size hint tests to denote size hint in use.
Added CFDictionary because I was curious. It won't make my published benchmarks.

It has a bad problem for benchmarks because I'm creating two dictionaries with a pre-size (because it supports it). This will eat twice as much memory as it should in the benchmarks.

A casual spot test run for the get good test with 30000000 (my system was doing other stuff so not a clean number), has the string test at 41.410724 (slightly slower than Perl speed) and the int test at 8.152435 (which beats STL unordered map). For the string test, like all the other tests, the string impedance mismatch rears its ugly head again, this time in the conversion from const char* to CFStringRef.