I didn't see a big change in going from toci=1 to toci=64. I don't dispute your results, but I am curious about why it made a difference for you but not for me. My sysbench test had:
* 8 tables, partitioning not used
* 8 copies of the sysbench process (1 per table), running a different host from mysqld
* mysqld on host with 12 real CPUs and 24 vCPUs after HT was enabled
* jemalloc
* my table names were test.sbtestX (for X in 1 .. 8)
The common hash function in MySQL is lousy for a small number of buckets --
http://bugs.mysql.com/bug.php?id=66473. Part of the problem is that it isn't put all of my tables into one bucket given the naming pattern above when there were 8 buckets. What were you table names? I also use table-definition-cache=1000 and table-open-cache=2000 to guarantee that once the table caches are large enough once populated. Did you do the same?
The workaround for my problem with the hash function was to use metadata_locks_hash_instances=256 with 5.6.10.
If you are comparing 5.6.10 versus MariaDB 5.5+XtraDB on XFS, then a big win should be to compare innodb_flush_method=O_DIRECT. AFAIK, XtraDB & the Facebook patch have changes to not fsync after O_DIRECT writes unless the ibd file has grown. 5.6.10 has O_DIRECT_NO_FSYNC, but it doesn't fsync after a file-extending write so it shouldn't be used with XFS.
So test on XFS and this should be an advantage for XtraDB.
I also used HW checksums when possible (innodb_checksum_algorithm=CRC32 for 5.6.10, not sure how XtraDB enables that). That makes a difference with fast storage, maybe it doesn't matter if you are using SAS/SATA disk.