Genuine question: what kinds of workloads benefit most from this speed? In my coding use, I still hit limitations even with stronger models, so I'm interested in where a much faster model changes the outcome rather than just reducing latency.
I think it would assist in exploiting exploring multiple solution spaces in parallel, and can see with the right user in the loop + tools like compilers, static analysis, tests, etc wrapped harness, be able to iterate very quickly on multiple solutions. An example might be, "I need to optimize this SQL query" pointed to a locally running postgres. Multiple changes could be tested, combined, and explain plan to validate performance vs a test for correct results. Then only valid solutions could be presented to developer for review. I don't personally care about the models 'opinion' or recommendations, using them for architectural choices IMO is a flawed use as a coding tool.
It doesn't change the fact that the most important thing is verification/validation of their output either from tools, developer reviewing/making decisions. But even if don't want that approach, diffusion models are just a lot more efficient it seems. I'm interested to see if they are just a better match common developer tasks to assist with validation/verification systems, not just writing (likely wrong) code faster.
I've tried a few computer use and browser use tools and they feel relatively tok/s bottlenecked.
And in some sense, all of my claude code usage feels tok/s bottlenecked. There's never really a time where I'm glad to wait for the tokens, I'd always prefer faster.
There are few: fast agents, deep research, real-time voice, coding. The other thing is that when you have a fast reasoning model, you spend more effort on thinking in the same latency budget, which pushed up quality.
Once you make a model fast and small enough, it starts to become practical to use LLMs for things as mundane as spell checking, touchscreen-keyboard tap disambiguation, and database query planning. If the fast, small model is multimodal, use it in a microwave to make a better DWIM auto-cook.
Hell, want to do syntax highlighting? Just throw buffer text into an ultra-fast LLM.
It's easy to overlook how many small day-to-day heuristic schemes can be replaced with AI. It's almost embarrassing to think about all the totally mundane uses to which we can put fast, modest intelligence.
I'd say using them as draft models for some strong AR model, speeding it up 3x. Diffusion generates a bunch of tokens extremely fast, those can be then passed over to an AR model to accept/reject instead of generating them.
I live in Japan, and our repair framework feels weak.
A lot of it is based on industry association rules (業界団体ルール), not enforceable regulation. For example, major electronics companies sometimes disclose a parts retention period (部品保有期限), like keeping parts for X years, but that is mostly traditional large companies.
On repair policy/enforcement, the EU and US seem more advanced than Japan. That is why stories like this (farmers pushing back on dealer lock-in and repair access) are interesting to me.
Isn't open source the legitimate compromise solution to right-to-repair? If you're unhappy with buying a closed proprietary product, why not support an open source alternative? Granted current open source farm tractors pale in comparison to a John Deere Model X9 1100, often priced at over $1 million.
I agree. I’m a gadget lover too. But we still have a real problem: for major household products like air conditioners and dishwashers, there usually isn’t a practical open-source hardware alternative yet. Iowa farmers are probably in a similar situation.
Go maps reuse memory on overwrites, which is why orcaman achieves 0 B/op for pure updates. xsync's custom bucket structure allocates 24 B/op per write even when overwriting existing keys.
At 1M writes/second with 90% overwrites: xsync allocates ~27 MB/s, orcaman ~6 MB/s. The trade is 24 bytes/op for 2x speed under contention. Whether this matters depends on whether your bottleneck is CPU or memory allocation.
Benchmark code: standard Go testing framework, 8 workers, 100k keys.
Allocation rates comparison is included. If your application writes into the map most of the time, you should go with plain map + RWMutex (or orcaman/concurrent-map). But if, for instance, you're using the map as a cache, read operations will dominate and having better read scalability becomes important. As an example, Otter cache library uses a modified variant of xsync.Map, not a plain map + RWMutex.
I focused on B/op because it was the only apparent weakness I saw. My “reuse” note was about allocation behavior, not false sharing. We’re talking about different concerns.
I was developing games on MSX/MSX2 about 40 years ago. It was already a fight with hardware resources, but the Apple II was an even stricter environment. Impressive work. Below is a quick comparison for those unfamiliar with the specs:
Macintosh (1989): 16-40MHz 68000, 1-4MB RAM, hardware acceleration, QuickDraw, non-blocking sound
Apple II (1979): 1MHz 6502, 64KB RAM, no hardware multiply/divide, race against CRT beam (4550 cycles), blocking sound only
* 10-year age gap, 16-40x slower CPU, 16-64x less RAM
Shufflepuck Cafe ran on the original Macs, which were 8MHz and had between 128K and 512k of RAM. (I never had access to a 128K machine and don't know if Shufflepuck worked on those.) This is still an incredible achievement of course! But the types of Macs that ran at 16MHz with 1MB RAM were probably incompatible with the original Shufflepuck as it was coded with the original Mac screen resolution firmly embedded into the design.
When implementing my version, I have noticed that the original Shufflepuck (with no anthropomorphized opponents) also did use the EOR trick on the player's paddle.
Shufflepuck Cafe, on the other hand, draws it "cleanly". I suppose it was purely for performance too.
I have similar and deep privacy concerns. But I also know that cameras have helped find criminals and assist crime victims. I don't want to let fugitives go without punishment. In fact, I must admit that cameras are a realistic choice given the current technology.
Flock Safety must be under public evaluation. Tech companies tend to hide technical specs, calling them trade secrets. But most internet security standards are public. What should be private is the encryption key. The measure to protect development effort is patents, which are public in the registry.
Why are tech specs relevant here? The problem with Flock is that once the data is collected, and once it's made accessible to law enforcement without any legal review, it's going to be used for solving heinous crimes, for keeping tabs on a vocal critic of the police commissioner, and for checking what the officer's ex-wife is up to.
If the cameras were installed and operated by the DHS or by the local PD, would that make you feel better? The data should not exist, or if it must, it shouldn't be accessible without court approval. The model you're proposing doesn't ensure that; in fact, it moves it closer to the parties most likely to misuse it.
This has nothing to do with the actual problem, which is Flock itself.
The fact that Flock controls all of the cameras, all of the data and said data is easily accessible means police and the state have access to information that they should only get with a warrant. A business having a camera storing video data that's completely local isn't an issue. A business having a camera which is connected to every other business that has a camera is.
Since when are warrants required for footage of people in public? Does a red light camera need a judge's warrant before it snaps a photos of a car running the light?
When it violates reasonable expectations of privacy. Being in public isn't a get out of jail free card. I mean, I could put up a camera right outside your house. It is 'public streets' monitoring your coming to your house is the sort of thing that does require a warrant.
There's no money to be made arresting criminals. Sure you get a few police contracts, and you need to show enough results to keep them.. but your moat is mostly how hard it is to even submit bids.
There's a lot more money to be made knowing that Accountant Mary's Lexis is looking kind of banged up and she could be sold on a new one.
The cameras aren't the problem, it's the companies behind them.
Everybody wants murderers and rapists in jail, nobody wants to 24/7 share their location and upload their every thoughts to palantir and other companies operated by degenerates like Thiel
I'm new to 3D scanning but very interested in trying it myself. I'm looking at OpenScan (€203+) for scanning small Japanese souvenir handicrafts. Does anyone know if this pricing is competitive, or are there better options in this price range?
I bought the OpenScan Mini kit for €170 a few years ago, mostly just to play with it. I've tried scanning things like
- flowers
- dead beetles
- model soldiers / Warhammer
- board game components
The examples are all better than I've achieved, and I could probably improve, but it's a fairly slow process, and difficult to know what to do to get better results. The Openscan Classic has a static model and the camera moves around, which would reduce vibrations and probably helps. Maybe using a professional camera would help too.
If the target isn't naturally 'rough' like a flower or stone, you need to add dots so the photogrammetry has something to align upon. I bought a professional scanning spray, which makes white dots which sublime after a while, but unfortunately it sublimes far too quickly — before the scan is completed. It's probably intended for use in an unheated workshop (e.g. scan a car for designing one of those wrap-around plastic banners).
I got the best results airbrushing white/black paint onto the Warhammer figure, but that's only acceptable if it's not yet been painted.
The kit itself is a bit janky, though mine is 3 years old now. I think the photogrammetry service is the most important part, and you should note it's not open source. When you purchase the kit you get a decent amount of credit to use the service, and can buy more credit as required. I quickly gave up trying to set up open source photogrammetry software, as so far I haven't needed to top-up the credit anyway.
Why not show both? Wikipedia could display archive links alongside original sources, clearly labeled so readers know which is which. This preserves access when originals disappear while keeping the primary source as the main reference.
They generally do. Random example, citation 349 on the page of George Washington: ""A Brief History of GW"[link]. GW Libraries. Archived[link] from the original on September 14, 2019. Retrieved August 19, 2019."
Inspired by this article, I tried to read some tutorials on Forth. My question is whether concatenative languages are AI-coding friendly. Apart from the training data availability, the question is also whether LLMs can correctly understand long flows of concatenated operations. Any ideas?
They can produce idioms that resemble the flow of Forth code but when asked to produce a working algorithm, they get lost very quickly because there's a combination of reading "backwards" (push order) and forwards (execution order) needed to maintain context. At any time a real Forth program may inject a word into the stack flow that completely alters the meaning of following words, so reading and debugging Forth are nearly the same thing - you have to walk through the execution step by step unless you've intentionally made patterns that will decouple context - and when you do, you've also entered into developing syntax and the LLM won't have training data on that.
I suggest using Rosetta Code as a learning resource for Forth idioms.
Thanks for your reply.
In fact, I've grown tired of programming by myself — I do 95% of my coding with Claude Code. But the remaining 5% of bugs can't be solved by the AI agent, which forces me to step in myself. In those cases, I'm thrown into a codebase I've never touched before, and code readability becomes key. That's what drew me to this article and to Forth.
I would look into the Rosetta.
Not relevant for modern LLMs, but concatenative, stack-based languages are very good at genetic programming applications. Concatenation tends to yield more viable programs when things are being mutated over time.
Then you get to definitions like ": open ( string -- handle 1 | 0) ... ;" which describes returning algebraic type Maybe Handle unboxed on the stack. Algebraic types are fun, they can easily represent Peano arithmetic and get us into the realm Goedel incompleteness theorem very quickly.
Or you can deduce signature for EXEC EXEC sequence. EXEC's stack effect can be described as ( \alpha (\alpha -- \beta) -- \beta), where \greekletter is a placeholder for a stack part of arbitrary length. Notice that this type comment has nested brackets and does not adhere to Forth stack-effect comment convention.
When I thought about this more than fifteen years ago, I've got at least two equally valid types for the EXEC EXEC: one where xt at top of stack consumes all its input and leaves no output ( \alpha (\alpha -- \gamma) \beta (\beta -- ) -- \gamma) and when first EXEC produces something for second to execute upon ( \alpha \beta (\beta -- \gamma (\alpha \gamma -- \theta) -- \theta).
One can argue that second type of EXEC EXEC subsume first one, if greek-letter-named-stack-parts are allowed to be empty.
Still it shows that typing Forth, at the very least, needs unification on the Peano's arithmetic level, implementing deduction from length zero to unbounded length.
So, in my opinion, for LLM to dependably combine typed Forth/concatenative definitions, it needs to call external tool like Prolog to properly deduce type(s) of the sequence of Forth's (or concatenative language's) definitions.
This is a Prolog system to learn programs in polynomial time. For one example, it can one-shot-learn a grammar, without being "trained" on millions of samples.
So, should one use a LLM that either needs a paid access or just slow to run, or freely go where "old school" systems like Eurisco [1] and Cyc went?
Eurisco demonstrated superhuman abilities in 1982-83. It also demonstrated knowledge transfer at the time, where rules from VLSI place-and-route algorithms were used to design winning Traveler TCS fleet.
The PyTorch3D section was genuinely useful for me. I've been doing 2D ML work for a while but hadn't explored 3D deep learning — didn't even know PyTorch3D existed until this tutorial.
What worked well was the progressive complexity. Starting with basic mesh rendering before jumping into differentiable rendering made the concepts click. The voxel-to-mesh conversion examples were particularly clear.
If anything, I'd love to see a follow-up covering point cloud handling, since that seems to be a major use case based on the docs I'm now digging through.
Thanks for writing this — triggered a weekend deep-dive I probably wouldn't have started otherwise.
reply