hansvm

It shows up easily at a macro level of you look at total "innovations" for a society (and have a good way to measure that -- currently still in an "I know it when I see it" stage). It won't usually show up in individual researchers. A few will absolutely be insanely productive with real innovations, but unless you're proposing only hiring that small cast of individuals then you're back to the problem of distinguishing good scientific ideas and methods which just didn't pan out from other forms of actual laziness and fraud given that in both cases you see no meaningful output from the researcher in question.

The Bitcoin argument is usually paired with "there are no non-scam use cases which aren't better served by other methods/tech."

Batching order, as you mentioned, matters a lot, and for any heavily optimized kernels it will change from one machine to the next. You also have the choice of backend numerical library from, e.g., different OS versions. There are floating-point bugs from time to time, especially in GPUs. Many operations (like transcendentals) are usually given a couple bits of wiggle room in the result. Another program executing could have changed the floating-point rounding mode on one device. More aggressive ML optimizers might automatically apply various forms of reduced precision to the requested high-level operation. If you have enough optimizations enabled, you might non-deterministically get compiled instructions like fmadd so that any one build of your library is deterministic (excluding other ideas mentioned above) but different machines with different builds (because of a staged rollout, different architectures, engineering mistakes, etc) can have different outputs. And so on.

With breaks, and it's also normal that in a class of ~30 you'll still find a couple students with cramps.

Many good students don't produce such artifacts. That's one of the big problems in academia -- a smart person with good ideas can inadvertently pursue a less promising path and not produce ground-breaking research, so how do you tease that apart from somebody scamming the system? The current approach is to measure unrelated bullshit like citation metrics. I'd hate to see those sorts of perverse incentives pushed down into the student body as well.

I'm all for handwritten tests, but it's more complicated than that. If you're actually writing for 2hr+ and haven't studied appropriate technique or bought some sort of crutch like a pencil holder then the repetitive motion will absolutely cause cramps for a fraction of the class regardless of being 20ish and healthy, and they might not find that out until they're forced to write for 2hr. The muscles manipulating a pencil (with poor technique) are much smaller than those manipulating a post hole digger, so that comparison isn't fair.

> have to manually run the code in your head

If you're doing a good job, you have to do that anyway, or at least have enough of a spidey sense for broken code to know when to investigate and add an extra test case.

Something like 30% of the time at $WORK, interviewers report the candidate as having solved the problem when a closer inspection reveals UB, memory corruption, and other bullshit. The test cases pass, and I think that's part of the problem. You can't tune out and avoid deeply understanding the submission.

My initial implementation used [9][9]u9 (which desugars to [9][9]u16 with some zero bits) and was a fair bit slower. If I had to guess, it's because the shift/extract/align you're describing isn't actually a part of the core solving algorithm, and when you have box constraints, knights-move constraints, etc, you're usually not doing anything which fits in a single u16.

I'm probably not the only culprit then :) I'd be curious to know who else has done things like that.

At most the second from me, and last time I didn't talk about the project (haven't talked about the project online at all IIRC).

Old habits :)

If I had to steel-man the idea, I'm pretty sure the integer-based solution has better codegen with many kinds of sparse, comptime-known masks. I think you're right though, StaticBitSet looks better.

I used it for awhile for "prod" for a toy project. I was scraping nearly every sale across every Target location for awhile. It was fast and easy to use. At the time many (read) queries had bugs of various kinds, requiring strange workarounds to get certain joins and whatnot to work (and not just throwing errors either -- often reporting zero data when there was data there, things like that) and not really being composable. Their CEO (CTO?) responded to my saying as much at one point and mentioned that they had just spent a lot of time fixing all their query logic and writing enough tests that it's actually usable now. I haven't had a reason to check yet, but the next time I'm doing any time-series thing and don't want to write the data layer myself I probably will.

IIRC, for "normal" bit widths the codegen basically uses the next larger machine type and preserves zero bits on the high end. An i3 is an i8 with five MSB zeroes (with more custom behavior for "packed" i3 values). It's UB to fill those with non-zero values. For larger bit widths, like u729, you concatenate many large machine types, the compiler generates instructions in an unrolled loop, and the LLVM optimization pass usually doesn't clean that up (though, now that integers are apparently not using the LLVM u729 implementation, perhaps there are some more optimization opportunities).

They're situationally useful, especially when performance isn't an enormous concern. That u729 example above came from a variant sudoku solver I wrote to aid developing new puzzles (easy to check the rough magnitude of the solution space for whatever idea I was mulling over and examine how restricted the board actually was -- just an intermediate step in puzzle design). It's not optimal (hard on the icache, can be hard on registers, other issues abound), but it's dead simple to use, and the assembly isn't terrible, beating all the normal solvers I saw floating around. It's a nice point on the laziness/correctness/good-enough-perf pareto curve.

Another comment mentioned this, but they're great in packed structs for representing weird numeric entities (I think I have a logarithmic number system floating around which does that).

One thing the language does quite a lot is use them to guard against certain classes of human error at compile time. It doesn't perfectly make impossible actions unrepresentable, but shoving a full u32 into a shift argument usually doesn't make sense, so the types are constrained to be smaller.

And the main road with cars wouldn't be an issue if people had a little common sense and respect. I was descending down a mountain road on my bicycle once, definitely speeding (enough so that I caught up to the traffic ahead of me -- really just trying to get off the mountain quickly though since I know people like the following exist), and some giant truck decided it was up to them to show me a lesson for riding in the road -- tailgated me the entire way down the bloody mountain, and there was no safe way for me to pull over (no shoulder, trees and steep drop), to speed up (I was already booking it, and there was a car in front of me anyway and no safe way to pass), or slow down (IME, slowing down when in a car sends people like that into a rage, so I wasn't comfortable bleeding off any speed with this guy a few feet behind me). If I had any equipment failures or had to slow down for any reason it would've been a nasty accident.

It's also very likely not physically possible for that car, and unless they're referring to straight-line stroads, many suburban routes can't sustain an average of 160mph with any current car.

> staff+

Maybe. It looking easy isn't the point. If you have the knowledge and skills such that doing so is a semi-repeatable endeavor, especially in a world where your colleagues apparently missed that 10% savings lying on the floor, is that not (part of) the point of a promotion? [0]

> lead 50 engineers

That's a totally separate ballgame. Nothing in your example says anything about leadership ability. Maybe you have those skills, and maybe you don't, but technical acumen is separate from leadership.

[0] https://mosaicstrategy.us/2016/10/10/know-where-to-tap/

Most vendors make it so hard to handle that defaulting to chargebacks is sensible (at least when the charge reasonably qualifies -- the kid with a parent's card example doesn't seem appropriate).

If a vendor makes a $20 oopsy, it's not worth the vendor's time or yours to track down their phone number, find that just the phone number section of their website is broken, acquire it elsewhere, see that it recently changed or is otherwise no longer in service, go to their website and interact with the cheapest chatbot solution they could find which somehow costs more than unfiltered Sonnet 4.6, be greeted by 3 help pages which have literally nothing to do with the problem at hand, go through the entire dialogue tree and see that it's useless, ask to be connected to an agent, which spawns a secret dialogue option informing you that you can call 555-5555 to speak to a human being, sit and wait for a voice prompt recorded at half-speed which feels the need to repeat every single choice and interaction back to you, navigate the entire phone dialogue tree, try various permutations of "representative" and swearing to see if there's an escape hatch, be redirected back to the website, ... <magic> ..., somehow eventually connect to a real human being, have your request denied, go back to step one and find a better informed representative, have the charge reversed, notice that the reversal hasn't applied even a month later, go back to step one, find a representative who will actually press the reversal button instead of just saying they did to juice their metrics, and come back several more times over the next year as an automated system repeatedly flags the associated purchase as not being paid in full (since the charge was reversed).

Or...I can send my bank the timestamped dashcam footage of me entering a parking garage, their prices and policies, and me exiting the parking garage, tell my bank what the right charge should have been, let the garage dispute that if they really think I'm wrong, and wind up having the entire charge reversed instead of just the delta I asked for.

I'm sure your vendor is one of the good ones, but my tolerance for bullshit from the rest is pretty low nowadays, and I won't finish going through the official process if it's too onerous. Somebody got a pat on the back saving $5 for the call I never successfully placed, and the business lost $20 on top of the actual refund in chargeback fees.

I'm personally getting asked more questions as people get emboldened by AI and then need it de-sloppified.

Yep, as a rule of thumb generative models need to be much larger. As a small caveat, that's because of what we're doing with those models; generation itself can also be tiny and fast, but only when the output space is sufficiently constrained. Next-word prediction (in keyboards), speech codecs (TTS, especially for blind people), and a number of other scenarios both admit small models and fall into the domain of what most experts would call "generative."

Yes, but simple models are far more expressive than people give them credit for.

As one example, I've shoved <100 parameter networks into driver code before and hand-tuned them to run in 10-20 nanoseconds. E.g., touchpad hardware tends to suck, especially as it ages, sometimes generating thousands of phantom events per second and causing drift and other such issues. Typically that's solved via careful tuning of hysteresis and other parameters, but the problem is actually very amenable to neural nets. It's easy to collect good-enough data en masse, and you can tune precision vs recall to bias heavily toward dropping more events without any issues (doing so has the effect of slightly slowing down the mouse pointer, which you can compensate for at the OS level where you adjust pointer speed) to achieve 100% reduction of the phantom events.

Lots of image recognition tasks ( like spotting undesirable products in industrial settings), image modification tasks (I have some models locally to process hand-drawn images and unwarp them, remove notebook paper lines, etc), audio modification tasks (part of my editing pipeline includes hand-editing audio to achieve some effect, doing that a few times, and training models to copy that edit), and all sorts of other things are similarly doable in much smaller models than you might think -- not as small as that driver code, but still small enough to fit in hobbyist FPGAs.

Not all of those require low latency or high throughput, but audio processing is expensive, so high throughput is nice; industrial applications often operate on fast streams of many products, so both throughput and latency are important; and more generally when you have fast models available (or any fast code really) you'll tend toward different thought patterns and creative ideas which you wouldn't have even considered otherwise and which wouldn't be possible without those faster solutions.

Now that I think about it, we average 1.5M inferences per second at $WORK, expected to scale up 10-30x this year, and we have a moderately tight latency budget. This solution wouldn't fit without a larger, more expensive FPGA, at least not unless KANs are comparatively that much more expressive than our current solution (based on past experimentation, my hunch is that they're not, but you never know), but it's borderline useful.

Is that a rhetorical question suggesting those people are wrong, or are you asking for, e.g., the technical reasons some software only works with Chrome in the mix?

> otherwise, popular solutions would integrate the idea

None of the major players are incentivized to care about this, especially not over other opportunities. Why would you expect them to integrate it?

One of the biggest wins you can institute for your own codebase if you use agents is writing your own harness, by a huge margin. The defaults are fine, but you can do better.

A coworker had me work through a particular problem (some no-importance web demo) with Cursor and Sonnet 4.6. It still sucked, but there was a qualitative shift in suckiness, one that I realized could finally be used to solve some real problems I had if I wrote an appropriate harness and used good enough models.

I still find it mandatory to write a lot of kinds of code by hand, but I write a lot of code with agents too now, and I previously literally didn't think that'd happen in <5yrs.

Why would double be a good rule of thumb for typical US SWEs? Most of the costs aren't proportional to salary, and the ones which are aren't anywhere approaching 50%, much less double.

Maybe for f16. The compiler's implementation could just be checking all numerators to see if the transformation is safe. The corner cases are messy and not quickly brute-forceable for f32 or brute-forceable at all for f64 though, so I doubt they'd bother, especially when I bet those constants have showed up literally zero times across all programs.

Thank you :)

The other side of this isn't sunshine and roses either.

Imagine you're a reasonably talented developer and just can't seem to break into a good job. You've been working delivery or something to make ends meet, and somebody finally offers a tech job. It isn't much, but your kids are hungry. You'll take it.

You show up, and it's everything the cynics here could have told you. Spamming people for money is the least of your worries. Whatever, at least you're actually programming, and maybe this is your chance to break into one of those mythical "good" jobs people keep talking about -- a stepping stone.

In an effort to impress, you figure out how to leveraging the HN who's hiring thread. It takes a bit of convincing for management to give you the time, but you're eager to prove yourself, and that enthusiasm is a bit infectious. Somebody signs off on the project.

It's a total flop though. You get zero conversions, nothing, nada. You've been spending the last week frantically debugging, getting more and more desperate as you realize what this means for your career prospects in a cutthroat environment like the one you're trying to appease.

As luck would have it, you stumble across this post today. Then the weight of your fuckup dawns on you. You spammed the "who wants to be hired" thread instead. Not fully yet recovered from the shock, you hear your boss call you over. "Do you have a minute to talk about something important?" There's a glint of orange on their desktop, and a pit sinks through the bottom of your stomach.

That's not totally true. It's sufficient to be exactly representable, but you only need the reciprocal rounding error to be small enough to guarantee the multiplication rounding step fixes it across the entire range of numerators. For IEEE754 f16 values, there are 28 such extra values, the positive and negative sides of 1705/x where x is a power of 2 at least as great as 2048.

It depends what you mean by "general purpose." First, these things generalize more often than you'd expect. Second, even in the absence of generalization they're still useful for, e.g., fingerprinting activities to manufacture a unique ID where non previously existed.

I dunno. Varints in the wild tend to be misused, and there are external proto schemas at work we have to integrate with which would literally be both faster and smaller as gzipped json. They're misused because they have an API encouraging misuse -- compressing scalars rather than sequences. Varints are used because they can have reasonable developer ergonomics while sometimes improving computer metrics a twidge.

On top of that, for the vast majority of performance/cost parameter spaces, you're better off both in developer ergonomics and speed/space slapping zstd across a flatter binary format, supposing no better tool fits your use case better. Especially if your messages aren't exceptionally tiny. You're not using them in a raw DB or doing raw bulk analysis on varints (else basically zero choices of parameters make varints win out), so you're transferring them somewhere and decoding them. That decoding step, even for highly optimized solutions like bijou64, is on par with (slightly better than, if you have an older datacenter link) your raw network. If you spend 1s on networking, you spend 1s on parsing. That's a bad tradeoff almost always, and that assumes a good varint solution.

Even when varints make sense for some set of perf/cost parameters, it's still only for developer ergonomics 99.9999% of the time. Even simple changes like operating on a sequence of values rather than a single scalar enable vastly better CPU/space tradeoffs, and being willing to craft a proper data layout usually offers huge gains on top of that.

It's interesting that you pick delta encoding (or, its natural extension, double-delta encoding often being valuable) for time-series databases as an example. That's an obvious case where you have a solution which is extremely cheap in storage/network/CPU. Varints suck comparatively, almost always.

Not to rip on them too much, especially since it's nice to have primitives available which let you not have to do hard thinking for literally every problem, but they're not amazing and not a great default.