{"push_id":789387705,"size":2,"distinct_size":2,"ref":"refs/heads/master","head":"fb1ace20b58acef3d82cede7632d3b9e86683bc8","before":"3f304871d1d79548a9a9b69efb71481fb710bd60","commits":[{"sha":"9ad212a99b66d7bc54abe769b46ecaeafdd0c8c2","author":{"email":"64b2b6d12bfe4baae7dad3d018f8cbf6b0e7a044@kheafield.com","name":"Kenneth Heafield"},"message":"Allow lowercase k for kilobytes","distinct":true,"url":"https://api.github.com/repos/kpu/kenlm/commits/9ad212a99b66d7bc54abe769b46ecaeafdd0c8c2"},{"sha":"fb1ace20b58acef3d82cede7632d3b9e86683bc8","author":{"email":"64b2b6d12bfe4baae7dad3d018f8cbf6b0e7a044@kheafield.com","name":"Kenneth Heafield"},"message":"Go crazy about memory managment.\n\nTransparent huge pages is nice, but to really shine one needs to align memory to the huge page size then call madvise with MADV_HUGEPAGE\nbefore accessing the memory.\n\nEmpirically, the probing hash table is 1.5 faster for large tables.  Timing on skaol with depth 8 prefetching.\n\n2 32 0 1.24008e-08\n10 128 0 1.76011e-08\n42 512 0 2.04013e-08\n170 2048 0 2.28015e-08\n682 8192 0 2.20013e-08\n2730 32768 0 2.20014e-08\n10922 131072 0 2.28014e-08\n43690 524288 0 2.40015e-08\n174762 2097152 1.37341e-07 2.54016e-08\n699050 8388608 1.71676e-08 2.62016e-08\n2796202 33554432 2.43201e-08 3.82024e-08\n11184811 134217728 3.61226e-08 4.42027e-08\n44739244 536870912 4.08616e-08 4.68029e-08\n178956976 2147483648 5.08757e-08 5.70035e-08\n715827904 8589934592 7.12283e-08 7.18045e-08\n2863311616 34359738368 8.54407e-08 8.30052e-08\n\n2 32 0 1.00006e-08\n10 128 0 1.84011e-08\n42 512 0 2.58016e-08\n170 2048 0 2.64016e-08\n682 8192 0 2.30014e-08\n2730 32768 1.4652e-06 2.22014e-08\n10922 131072 0 2.36015e-08\n43690 524288 0 2.46015e-08\n174762 2097152 0 2.52016e-08\n699050 8388608 5.72348e-09 2.58016e-08\n2796202 33554432 2.57506e-08 3.80024e-08\n11184811 134217728 3.29038e-08 4.42028e-08\n44739244 536870912 3.02214e-08 4.62029e-08\n178956976 2147483648 3.02661e-08 4.66029e-08\n715827904 8589934592 3.27809e-08 4.7203e-08\n2863311616 34359738368 4.05276e-08 5.32033e-08\n\nposix_memalign will produce such aligned memory.  However, it has two infelicities:\n\n1. The memory is not guaranteed to be zeroed, even though most of the time it's calling mmap.  That means a noticeable amount of CPU spent\nzeroing pages.  This code provides the option to have zero-initialized or not.  In most cases (all of the large ones) the zero\ninitialization has no extra cost.\n2. The implementation is allocating size + alignment + page_size, finding a boundary, and leaving the rest of the mapping hanging.  I am\nsimilarly guilty (there doesn't seem to be a way around this), but at least munmap the extra cruft afterwards.\n\nPoint 2 increases VmPeak without reflecting actual model size.  Suppose RSSMax is the way to go for benchmarking.\n\nLMs created on the fly from ARPA or with READ will use HugeMalloc and be on huge pages if they're big enough.\n\nAutoProbing also uses huge pages when it's big enough (TODO: some way to align to 1 GB boundaries automatically?)\n\nThese changes should only impact Linux performance.","distinct":true,"url":"https://api.github.com/repos/kpu/kenlm/commits/fb1ace20b58acef3d82cede7632d3b9e86683bc8"}]}