Private
Public Access
ed
c3a9978d03
Processed 38 URLs from the user's list. 1 was already in the corpus (2072194202851549432). 9 were duplicates within the new batch (same post IDs at different anchor URLs); removed those. This commit contains the 27 unique new threads. Content spans the Jul 2026 era and is mostly Lottes's Linux development environment bringup work: - 1674757854471806977: 'Nothing Oriented Programming' (NOP) philosophy - 1990260050485797063: reversed projection matrices - 2030722033286328426: STP conspiracy theory - 2058166883044516181: 'crap-o-grammers' C++ bloat-ware critique - 2060191401883619479: relevant timestamp article - 2060730425929080874: CPU clock code (TSC) - 2061123768429211767: no-debugger-debug + mmap log pre-history - 2061416116694442141: Windows thread priority - 2061933917137932437: mmap'd page file - 2061937134756380682: Windows HIGHEST_PRIORITY_CLASS - 2062031187023982879: back running 640x480 on VGA CRTs - 2064858927829745887: on Linux now (SteamOS) - 2065804972378243476: nanorc done + iPhone font issue - 2065832746757341482: cross compilation up - 2065872197147578751: @axelgneiting bypassing libc - 2066184005632786736: Linux mlockall - 2070337342854832468: why not pselect/ppoll/epoll_pwait2 - 2070734717825986566: deterrant to ALSA = parsing through snd_pcm_open - 2071415096304193820: aplay to actually play a wave file - 2071706805114216559: 'ALSA hell month continues' - 2071937360288235902: Linux thread priority code - 2072135292115427728: Linux doesn't allow priority increase by default - 2072445315370590266: 'Wine workarounds - I could just detect' - 2072506103401754653: snd_pcm_sw_params for ALSA - 2072804183992922296: starting on WDM/KS audio for WIN32 - 2073096069529907441: re-trying WASAPI - 2073110092447203466: CPP_(obj) for mmdeviceapi Cleanup: removed 9 duplicate dirs (same posts at different anchor URLs), script temp files, and the '1857803914604618029' which was already a duplicate of '1857820858162753661' (mmap log canonical).
104 lines
3.6 KiB
JSON
104 lines
3.6 KiB
JSON
{
|
|
"root_post_id": "2060730425929080874",
|
|
"posts": [
|
|
{
|
|
"post_id": "2060730425929080874",
|
|
"author": "NOTimothyLottes",
|
|
"handle": "NOTimothyLottes",
|
|
"text": "Renovating CPU clock code. I'm assuming x86-64 TSC is always >= 1 GHz so that conversion of clock counter diff to nanoseconds is simply a MUL instruction fetching the RDX high 64-bit result (of the 128-bit computed). But figuring out how to do the inline asm was a pain.",
|
|
"timestamp": "2026-05-30 14:29:54",
|
|
"media_urls": [
|
|
"https://pbs.twimg.com/media/HJku0L4WkAAZk5a?format=png&name=orig"
|
|
],
|
|
"reply_to_id": null,
|
|
"quote_of_id": null,
|
|
"metrics": {
|
|
"reply_count": 3,
|
|
"repost_count": 0,
|
|
"like_count": 40,
|
|
"view_count": 4744
|
|
}
|
|
},
|
|
{
|
|
"post_id": "2060742129190568413",
|
|
"author": "NOTimothyLottes",
|
|
"handle": "NOTimothyLottes",
|
|
"text": "Looks like NtQuerySystemInformation() with SystemHypervisorSharedPageInformation (aka 0xc5) gives 64-bit scalar for TSC that converts time to units of 10 MHz. So the smart way is to work in units of TSC, then do a subtraction of TSC terms, then MULHI to get {ms, us, or ns} time",
|
|
"timestamp": "2026-05-30 15:16:24",
|
|
"media_urls": [],
|
|
"reply_to_id": "2060730425929080874",
|
|
"quote_of_id": null,
|
|
"metrics": {
|
|
"reply_count": 1,
|
|
"repost_count": 0,
|
|
"like_count": 6,
|
|
"view_count": 1060
|
|
}
|
|
},
|
|
{
|
|
"post_id": "2060752921092833490",
|
|
"author": "NOTimothyLottes",
|
|
"handle": "NOTimothyLottes",
|
|
"text": "https://gist.github.com/pmttavara/6f06fc5c7679c07375483b06bb77430c - A great reference for getting TSC scaling multipliers on Linux and Windows",
|
|
"timestamp": "2026-05-30 15:59:17",
|
|
"media_urls": [],
|
|
"reply_to_id": "2060742129190568413",
|
|
"quote_of_id": null,
|
|
"metrics": {
|
|
"reply_count": 0,
|
|
"repost_count": 0,
|
|
"like_count": 11,
|
|
"view_count": 924
|
|
}
|
|
},
|
|
{
|
|
"post_id": "2060885487858880689",
|
|
"author": "Robert Clausecker",
|
|
"handle": "FUZxxl",
|
|
"text": "@NOTimothyLottes If you do the multiply in uint128_t and then right-shift by 64 places, the compiler should do the right thing.",
|
|
"timestamp": "2026-05-31 00:46:04",
|
|
"media_urls": [],
|
|
"reply_to_id": "2060730425929080874",
|
|
"quote_of_id": null,
|
|
"metrics": {
|
|
"reply_count": 1,
|
|
"repost_count": 0,
|
|
"like_count": 2,
|
|
"view_count": 253
|
|
}
|
|
},
|
|
{
|
|
"post_id": "2060898306851516562",
|
|
"author": "NOTimothyLottes",
|
|
"handle": "NOTimothyLottes",
|
|
"text": "@FUZxxl “Should” is exactly why I prefer the actual instruction instrinsics or just inline asm (which is what I use on C CPU land)",
|
|
"timestamp": "2026-05-31 01:37:00",
|
|
"media_urls": [],
|
|
"reply_to_id": "2060885487858880689",
|
|
"quote_of_id": null,
|
|
"metrics": {
|
|
"reply_count": 1,
|
|
"repost_count": 0,
|
|
"like_count": 0,
|
|
"view_count": 125
|
|
}
|
|
},
|
|
{
|
|
"post_id": "2061000558698197386",
|
|
"author": "Robert Clausecker",
|
|
"handle": "FUZxxl",
|
|
"text": "@NOTimothyLottes Have fun with a solution that the compiler optimises worse and that is not portable.",
|
|
"timestamp": "2026-05-31 08:23:19",
|
|
"media_urls": [],
|
|
"reply_to_id": "2060898306851516562",
|
|
"quote_of_id": null,
|
|
"metrics": {
|
|
"reply_count": 0,
|
|
"repost_count": 0,
|
|
"like_count": 0,
|
|
"view_count": 27
|
|
}
|
|
}
|
|
],
|
|
"source_url": "https://x.com/NOTimothyLottes/status/2060730425929080874"
|
|
} |