a-dub

hm. in linux you have MAP_POPULATE which forces a prefetch where macos relies on page faults and lazy loading. if MADV_WILLNEED doesn't help, maybe readv to vector read directly or mmap+writev (write to a dummy fd, with an iovec for each page, hopefully resulting in a one-syscall-big-pagefault for mmap.) maybe also experiment with a loop that just reads one byte from each relevant page after mmap but before real computation?

that's basically the argument, thank you! the other person i was debating with was correct to push back on the scope of the generalization! but, in cases where the choice is actually meaningful towards a push to max performance, (not trivial loops as tail call optimizable recursions, further optimization), iteration is the way. recursions are easy to read, understand and reason about, but they also abstract away an implicit data structure choice where unrelated implementation details can impact overall performance.

i don't think that's true. i still have a thinkeco ac modlet that coned sent me years ago as part of some kind of "make your ac smart" promotion.

if you turn those knobs to the off position while the compressor is running, does it actually go into some kind of orderly shutdown or does it abruptly cut power to the compressor?

that's a fun project. i'd be a little concerned about the servos failing to fully switch the switches or placing wear on them, maybe a dangerous failure mode where it is switched into and left in an in-between state unattended that could lead to a fire hazard.

you can buy smart outlets with the correct connector, just look for 20A versions. (honeywell, at a minimum, sells one).

https://prod-edam.honeywell.com/content/dam/honeywell-edam/h...

for a given expert, do you have a sense for what the spatiotemporal access pattern looks like?

let me try arguing it this way: it is impossible for a non-tail-call-optimized recursion to use constant space. the stack grows with O(depth) and therefore memory usage does as well. a consequence of this is that the finite storage lru caches and registers are polluted with one-time-use variables which reduces their availability for actually useful caching.

it IS possible for a loop to use constant space. pre-allocate temporaries and inline any function calls. everything lives in one stack frame. simply iterating the loop itself does not come with fixed space overheads from allocating new stack frames.

i suppose one thing i should mention, i am thinking of extreme optimization use cases where the entire data structure fits in cache (or close to it). think like in-cache tries or similar. if you're hitting main memory with each iteration anyway, it doesn't really matter.

maybe the wrong terminology, but non-tail-call-optimized recursions spray their state across space with each iteration consuming a new stack frame, where iterative algorithms live in one stack frame and can re-use temporaries. the state spraying results in consumption and spilling down the memory hierarchy, from registers through caches. i think of this as the memory hierarchy being designed to best perform when spatial locality of memory usage is maintained, but it's slightly different from what most people mean when they discuss spatial locality... maybe "cache efficiency" is the better term?

lol. i once interviewed with facebook and had some "senior" dev on the phone who was balking and grousing at my claim that iterative algorithms are faster than recursive ones. the minute i mentioned spatial locality, he went quiet.

more to the point, i feel like there should be a compiler switch or decorator style flag in modern languages that declare "this function is expected to optimize with tail recursion, throw a compiler or linter error at static analysis time if that doesn't work out."

> The multi-agent workflow led to interesting dynamics. For example, the key idea in producing this attack was discovered by a pair of workers working together. Both started investigating the idea; the first worker prematurely rejected the idea as infeasible, but the second found a way to fully exploit it. The pair kept exchanging messages, and eventually both agreed they had found an effective attack.

this is pretty interesting. the way it is written doesn't make it sound like the collaboration actually led to the discovery, but rather just the stochastic nature of each thread in the search. it would be interesting to replay and repeat the search (possibly with prior/context pertubations) to get a sense for how often it finds or misses the known working path.

i tend to think of this stuff in terms of top down information theoretic approaches to composition and bottom up psychophysics of auditory perception. there is some cool work out there where physicists attempt to compute information content of western classical music and then there is all the fun stuff around the biophysics of the cochlea, nonlinear frequency discrimination and frequency selectivity of the ear.

it's actually an interesting question: is there a point where the long acting prep injections have effective durations that look like vaccines and boosters. and yes, sadly, it appears that convenience and some of the psychological aspects of marketing play outsized roles in public health.

either way, worth doing. you never know when circumstances might change and another tool in the toolbox becomes essential.

the bletchley park trust sells (used to?) pamphlets in the gift shop that they call "reports" which have been written by some of the rebuild team and other associates.

the nmc is most interesting, but also pretty cool to see turing's office in hut 8 (i guess the portable classroom like structure for a computer lab is a trope that goes all the way back to the beginning)!

that's what i was describing! :) it's on the bletchley site (they share a parking lot) and was where tony sale and friends rebuilt the colossus.

although i just looked. critically they have different ticket offices. it was a long time ago! either way, worth a visit of both and they make up an excellent way to spend a day.

knowledge graph guided task synthesis. very cool! i have long wondered about the "how do you get good coverage of all the tasks" problem.

maybe some interesting theoretical work there around the rate of production of new knowledge itself and various mechanisms (human approaches, mechanistic approaches, etc).

i had the opportunity to visit bletchley about sixteen years ago... one interesting detail was that all the colossus machines were destroyed after the war as they were seen as too powerful and dangerous. it wasn't until years later that the retired telephony engineers (this was where ee excellence lived at the time) who had built them began rebuilding them from memory as a sort of hobby/club centered at bletchley. there used to be a fellow there named tony sale who would tell you all about it, but unfortunately he passed away a few years ago.

super interesting place and worth the short trip out of london! also i believe the term they used was "semi-programmable digital computer." bombes were mechanical search machines that i believe operated on short ciphertext sequences and i believe the big innovation with the colossus was having the ciphertext live on a long optical tape that would be re-read at thousands of characters per second, thus enabling a high speed processing loop of longer sequences. but i am no expert on this!

use encryption and keys for all socket connections to adb, listen on 0.0.0.0 and unify the wifi thing with the socket thing, add an app level permission that allows apps to access an ephemeral system key via the binder to enable libadb style usecases?

i'm not totally sold on writing prose by hand. it's still a little too uncomfortable for me. but, for doing mathematics or memorizing things, i have specific rituals built around handwriting that i finally figured out how to make work quite well. i have funny hard requirements though: a) clean, white printer sheets only, absolutely no lines, they are distracting b) mechanical pencils only c) a flat, hard, stable and clear writing surface is a must d) a real eraser must be available

my technique for memorizing things involves a handwritten spatiotemporal reproduction from memory (put everything in the same place on the page in the same order) with spaced repetition that exploits sleep cycles. took me forever to figure it out, but once i did things like exams that build on toolboxes of rote memorization became a lot easier!

i guess i should also mention that i have long had an interest in reproducing the causal nature of handwriting for composing text on the computer. things like write only editors that attempt to encourage that same sort of causal flow.

it's actually very stable on x86_64 these days, even with optimus.

> The takeaway might be that historic data of market data might often be enough to make a reasonable prediction. Only external data that nobody else has (used) can make your prediction better then the market.

that's basically the definition of an efficient market. demand forecasting and insuring against price shifts is the actually useful thing that the commodities futures markets do.

also a fundamental difference from other time series prediction problems. there are all sorts of weird dynamics that go on before one biosignal effects another, or one metric predicts a failure, where a reasonably efficient market price reacts quickly to well known exogenous factors.

something like that would be interesting. i just get the sense that doing it metadata blind would result in something that learns a somewhat brittle short-time covariance-like structure that doesn't use all available information to achieve best possible generalization and that in the end the benchmark numbers start to reflect some luck with that for predicting non-stationary behavior combined with a lot coming from a pretty good synthesizer that matches previous patterns.

that being the case, it seems the next jump in performance would come from incorporating both metadata and metadata enriched causality and maybe that next jump in performance would be the most interesting jump from a practical system that is useful perspective. (it's more valuable for a system to predict outlier events than it is for it to do an excellent job at synthesizing ordinary behavior)

i think i remember seeing an unlockable bootloader on the remarkable?

> Given the lack of forecasting signal, the obvious next step then is to seek out external (exogenous) features in the real world that can help prediction models.

this seems right to me. maybe another interesting approach would be a fusion llm+ts model that does multiple-input-single-output with input metadata and causality narrative. so it "thinks" about what data it has and how predictive it may be of the target variable and when something "interesting" occurs it uses the big priors to synthesize a good guess at what it would look like.

so you'd have something like the time series data plus textual narratives of the causality stories as the training data.

woah! there's a whole genre of old, abandoned and dilapidated bowling alley pics on the internet and it's amazing. thank you for that!

and yes, you should post pics and stories like when jwz renovated the dna lounge. (i think one of his first posts was about building his own pos system, fwiw)

> If you are using Perforce as an enterprise system, $500 is peanuts. Perforce can get pricey.

i think it was $600/seat back when i paid attention (20+ years ago). don't remember if it was perpetual or annual.

> However, I continue to be amazed that Perforce survived Git. I assume its ability to handle large binaries has been what saved it.

yeah i think it lives on in games probably mostly through inertia. last i looked the company itself had shifted away from p4 classic to some git wrapper stuff.

i've never actually seen it but my understanding is that google's custom internal system (piper) basically is a reimplemented scalable p4+g4 wrapper.

i always thought the workspace mapping and workspace template model in p4 was pretty elegant, especially for things like embedded platforms where you could opt in and out various subtrees which made very large device trees/bsps more manageable.

also they were the first widely deployed vcs system that attempted to be efficient (server side indices for local tree state and communication with the server in deltas rather than forcing complete rescans for every operation that often involved talking to the server as each file was scanned)

it's just not as interesting to me when it's no longer evidence of careful and deep thought paired with high quality execution and skillful craft.

plus all the claude-isms get old.

> It seems possible they trained this by doing full RL rollouts of agents interacting with each other. They likely view these prompts somewhat the same as raw reasoning traces, they don't want people to train directly on them.

this tracks. anthropic protects these as well iirc.

> I am unsure if this has been confirmed, but there are some signs that the opaque "compaction blob" they return from their dedicated compaction endpoint might not be text at all, rather a latent space representation of the conversation.

probably not a latent (to my knowledge latents aren't really part of the outer loop in ar-transformer inference processes), but maybe non-human-readable reasoning traces as occurs in fable.

how hardened are modern browsers with respect to detecting underlying os? seems like there would be loads of gaps?

it's kinda like riding an e-bike, but in heavy and unpredictable pedestrian traffic.

sounds like it is just supercharging the business of science with all of its known failings?

it would be funny if by accelerating the enterprise it actually forced an effort to correct the trajectory.