HN user
I worked on a system a couple years ago with a BERT-based model (64M parameters) used for classification. The rest of the system could process data at gigabytes per second, and so here tokenization at a measly few megabytes per second really slowed things down. The model inference was more expensive than tokenization, but tokenization was still >10% of total runtime.
It's not just cosmic radiation or improperly built computers that result in bit flips. Row hammer is a thing :)
Logout functionality is not the only use case for token invalidation. Another significant one is to revoke a token that has been exposed, like inadvertently pushed to GitHub. In that case you want to invalidate the token to a avoid unauthorized access to your service.
With vanilla JWTs, you have no way to do this! But then if you add revocation checking on top (which people do), your JWTs are no longer stateless.
Your general point here is reasonable. But to provide some domain knowledge context: secrets are leaked _very_ often!
In public data (source code on GitHub, etc.) you can expect a prevalence somewhere in the range of 0.5-2.5 live secrets per gigabyte of content. Now yes, there are more than 8 billion people on earth now and the murder prevalence is a lot higher than 0.5-2.5 per billion. But there are _far_ more bytes of public content than there are people on earth, so in absolute terms, there are far more leaked secrets than murders.
If you look at other types of data (like internal Git forges), the prevalence is much higher.
I think you could indeed retire with $1 per leaked secret!
Suppose you have access to certain memory. If you repeatedly read from that memory, can't you still corrupt/alter the physically adjacent memory you don't have access to? Does it really need to be a write operation you repeatedly perform?
Example: A workstation or consumer GPU used both for rendering the desktop and running some GPGPU thing (like a deep neural network)
How is it a write-only attack vector?
Lexing, parsing and even type checking are interleaved in most C++ compilers due to the ambiguous nature of many construct in the language. > It is very hard to profile only one of these in isolation. And even with compiler built-in instrumentation, the results are not very representative of the work done behind.
Indeed, precise cost attribution is difficult or impossible due to how the nature of the language imposes structure on industrial computers. But that aside, you still end up easily with hundreds of megabytes of source to deal with in each translation unit. I have so many scars from dealing with that...
A simple hello world in C++ can pull in dozens of megabytes of header files.
Years back I worked at a C++ shop with a big codebase (hundreds of millions of LOC when you included vendored dependencies). Compile times there were sometimes dominated by parsing speed! Now, I don't remember the exact breakdown of lexing vs parsing, but I did look at it under a profiler.
It's very easy in C++ projects to structure your code such that you inadvertently cause hundreds of megabytes of sources to be parsed by each single #include. In such a case, lexing and parsing costs can dominate build times. Precompiled headers help, but not enough...
Well, the current generation of LLMs blow away that Turing Test
Maybe a weak version of Turing's test?
Passing the stronger one (from Turing's paper "Computing Machinery and Intelligence") involves an "average interrogator" being unable to distinguish between human and computer after 5 minutes of questioning more than 70% of the time. I've not seen this result published with today's LLMs.
A lot of AI-based PDF processing renders the PDF as images and then works directly with that, rather than extracting text from the PDF programmatically. In such systems, text that was hidden for human view would also be hidden for the machine.
Though surely some AI systems do not use PDF image rendering first!
"String interning" is discussed in the Java Language Spec, going back to the 1990s, and wasn't novel there. It goes back at least to Lisp implementations from the 1970s. Probably even earlier than that.
Yes, this was my own experience!
When looking at universities, when I saw a high sticker price, I ignored that university, even if in hindsight I had a good chance of being accepted.
I wish I had had someone when I was young who encouraged me to have broader horizons.
About a dozen OSes / configurations were supported, and the entire test suite would take a few days to run on each such configuration.
This was native desktop+server software, not a hosted SaaS thing.
Major releases were put out every few months.
Developers did run tests regularly with every change they would make, but it was infeasible to run all the tests in every configuration for each change. So they would try to choose tests to run that seemed most relevant to the code they had changed.
The entire test suite would run more or less constantly on shared machines, and every few days some new tricky failure would be detected. The tricky failures were almost always the result of some unanticipated interaction of features, frequently on the more obscure configurations (like IBM z/OS).
The problem was not that developers were not testing, but that the tests were infeasible to run every time. So instead, testing became an optimization problem.
At a previous job, with a huge C++ codebase and ~100 developers over 20 years, many platforms supported, a build could take hours, and the test suite took so long to run that it would take several days or weeks of real time to get through it all.
This cycle time combined with occasional unexpected interactions between components meant that in every release cycle, there were dozens of complicated failing tests where it was not obvious which code change was responsible.
`bisect` here was extremely helpful: instead of having to pore over commit history and think very hard, I could bisect with a small wrapper script that would build and run the failing test in question. Builds still took hours, but I could usually autonatically pinpoint the responsible code change for one of the tests overnight.
(This was not using Git, but Perforce, for which I had to write `p4-bisect`. Alas, it's not open-source...)
When doing appsec review in C or C++, yes!
you can get 100% GPU utilization by just reading/writing to memory while doing 0 computations
Indeed! Utilization is a proxy for what you actually want (which is good use of available hardware). 100% GPU utilization doesn't actually indicate this.
On the other hand, if you aren't getting 100% GPU utilization, you aren't making good use of the hardware.
The common crawl only pulls documents less than a small limit (1MiB last I checked). Without special handling in this project, bigger documents than that would be missing.
So indeed, not representative of the whole Internet.
'git clone --mirror' seems to pull down lots of additional content also.
There seems to be no such thing as a "private fork" on GitHub in 2024 [1]:
A fork is a new repository that shares code and visibility settings with the upstream repository. All forks of public repositories are public. You cannot change the visibility of a fork.
[1] https://docs.github.com/en/pull-requests/collaborating-with-...
If your ranges end up sparsely distributed, using roaring bitmaps can speed things up a lot.
The classical synthesis approaches seem to have much more emphasis on correctness and specification than modern LLM-based synthesis though — things like deriving provably correct lock-free data structures.
The LLM-based synthesis work I've seen, in contrast, maybe uses a set of unit tests for correctness testing.
It doesn't feel like modern LLM-based synthesis supplants the classical approaches.
It predates LLVM. That's one reason, anyway.
Yes and no. Latency across a stage is one reason why orchestras have conductors. An orchestra split across a stage can have enough latency between one side and another to cause chaos sans conductor. It takes noticeable time for sound to cross the stage.
30ms seems high! Though I might believe that.
On higher-end pianos (mostly grands), there is "double escapement" action, which allows much faster note repetition than without. I suspect the latency would be lower on such pianos.
Musicians learn to lead the beat to account for the activation delay of their instrument
Yes, this is absolutely a thing! I play upright bass, and placement of bass tones with respect to drums can get very nuanced. Slightly ahead or on top of the beat? Slightly behind? Changing partway through the tune?
It's interesting to note also how small discrepancies in latency can interfere: a couple tens of milliseconds of additional latency from the usual — perhaps by standing 10-15 feet farther away than accustomed, or from using peripherals that introduce delay — can change the pocket of a performance.
This already happens. I have seen recruiters trying to get domain experts in various fields to write articles for AI training.
So a tiebreaker then?
It's also not clear to me how one would determine that an ML model-generated plan is indeed optimal, or how far from optimal it is. A*-based approaches give you these things.
How would one go about proving that a learned heuristic (something from an AI model) is in fact admissible?