Threadripper L3 CPUID Strangeness: Difference between revisions
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
I was updating copyrights upon my [[libtorque]], a project from 2010's [http://vuduc.org/cse6230/ CSE 6230] with Professor Richard Vuduc. libtorque was tremendous fun to work on, and resulted in me distilling [[Fast UNIX Servers|many thoughts]] that I'd been kicking around for a few years, but I consider it a research project and not an industrial-strength library. I don't touch it terribly often, though I do check for compiler warnings every few [[gcc]] releases. | I was updating copyrights upon my [[libtorque]], a project from 2010's [http://vuduc.org/cse6230/ CSE 6230] with Professor Richard Vuduc. libtorque was tremendous fun to work on, and resulted in me distilling [[Fast UNIX Servers|many thoughts]] that I'd been kicking around for a few years, but I consider it a research project and not an industrial-strength library. I don't touch it terribly often, though I do check for compiler warnings every few [[gcc]] releases. | ||
On my [[TRX40|AMD 3970X Threadripper]], the <tt>archdetect</tt> program included with libtorque failed out. I traced this down to the function <tt>decode_amd_l23cache()</tt> in my x86 hardware discovery. [[X86|Intel and AMD]] caches were at one time defined by a disordered | On my [[TRX40|AMD 3970X Threadripper]], the <tt>archdetect</tt> program included with libtorque failed out. I traced this down to the function <tt>decode_amd_l23cache()</tt> in my x86 hardware discovery. [[X86|Intel and AMD]] caches were at one time defined by a disordered map from integers to complete cache descriptions, as in each integer meant a completely different set of cache parameters, leading to horseshit ass-puckering code like: | ||
<tt> | <tt> | ||