That exist, kinda. Android gaming handhelds have mobile SoC and also active cooling. See Ayn and Retroid devices. Their (almost) throttle free is a very nice experience.
Yeah I have an Ayn Thor with a Snapdragon 8 Gen 2, it's great being able to play fairly demanding Windows games on this tiny device.
It's still PoP with the RAM stacked on top in a plastic casing so you need a pretty big fan to cool it since you have to go through insulating plastic, then the RAM to get to the CPU.
With a HPB packaging you can cool the CPU directly and could theoretically get the same amount of cooling power with a much smaller fan that could be integrated into a thing smartphone (à la RedMagic).
I’m not sure I follow why the performance is “Insane”
This is a M5 level chip that runs slightly within a ballpark of M5 wattage (afaik M5 is between 15W max on an iPad and 30W max CPU+GPU on a cooled Mac)
This is running in a thermally unconstrained bench setup and has potentially worse power consumption with what will be lower than previous gen performance when this and the alleged M6 are truly out.
So tired of people on HN calling you out for being excited about tech.
It gets M5-level numbers at 12-14W.
It gets about 30% better perf than the A19 Pro at equal wattage on the whole 4W - 8W range.
So no it's not worse power consumption than prev gen. This is ARM's stock GPU having finally caught up and being competitive with Apple and Qualcomm's mobile GPUs.
This is insane to me. Stay cynical if you want, I have the right to be excited about it.
I’m not trying to say you shouldn’t be excited by it. But there’s a significant number of caveats to every single number you posted but you glossed over the points I made.
And in being defensive, you jumped straight from the topic you were discussing (GPU perf) to CPU perf numbers to try and make a point.
There’s a difference between being cynical and pragmatic, just as there’s a difference between being hyped and realistic.
You haven’t seen this in a product. You’re seeing development board numbers. Be excited all you want but it’s a public forum, if you want to just post without any responses make a blog.
No? The numbers I quoted were GPU numbers, sourced from this video [1].
Also I explicitly acknowledged in my first comment that real devices won't be able to draw that kind of power. But 4 watts is 4 watts whether it's in a test bench or a phone.
Xiaomi smartphones were extremely well made at least a few years ago. Even the core software was impressive vs Google for example (try echo cancellation on any of your non-Xiaomi devices). Its only real problem is ads.
Yeah it wasn't a dig a Xiaomi specifically. All Android devices have broken Vulkan drivers. We have to rely on alternative open-source drivers (e.g. Turnip for Snapdragon) for real compatibility and performance.
Although assignments as expressions in C are convenient, I don't think they make a ton of sense and find Zig's capture easier to read (easier to immediately see what's being evaluated)
Every prompt will get this info, probably not only initially, since it could run out of context window. But every re-prompt in existing chats, even, gets one system prompt per model used per chat dialogue done.
Adds a fraction of cent of electric power just to every usage.
At home, I work with 65k context window, and if my system prompt and agents.md were both this length, I would spend two-thirds of the input window, before compacting which perhaps alleviates the issue for my use case, on re-feeding what mostly the reinforcement-learning should have implicitly baked in.
But what makes it crazy? If nobody told you it was 22k chars, and it gets the provider the results they want for their benchmark goals, why is it crazy?
The only observable side effect, as a user, is that the system does what you want more often than one without this prompt. Or, it stays more aligned with the provider’s guidelines. Or some combination of both.
If it was a 65k context window, then it might be a bigger deal. But it isn’t, so the comparison is moot.
That's the thing I don't think it gets the provider the results they want for their benchmarks.
It gets them what they want for their legal safety, but it actively harms the performance.
Pi with its 300 words system prompt outperforms Claude Code and Codex both in token usage and passing rate, when using the same model + effort configuration [1].
So yeah not only does it bloat context, but it runs worse too.
Deepseek V4 Flash 0731 was such a massive jump in capability for such a small model (and price), that I'm a bit disappointed by this release.
I keep my agents on tight leashes, using them very interactively for bouncing off ideas, architecture, and then writing code (especially prototyping) and Flash has been crushing everything I ever needed it to do.
Maybe my ambitions are too tame compared to people needing Fable / Sol grade models, but I'm probably staying on Flash and not moving on to Pro for the foreseeable future.
I read "coding" as literally the act of being in the text editor and writing the code, not the encapsulating job of defining requirements, desigining a solution, etc. which is definitely not a solo activity.
But I agree with OP that when comes the time of sitting down and writing the code, it is a solo activity. I want to lock in and not see multiplayer cursors or avatars popping up around the editor. The part before and after that are for collaboration, but writing your piece of the code is (or at least I like it to be) solo.
You probably haven't read the article, but the software they build is a TUI, not a Desktop GUI (in fact a big chunk of the article is how they need to fight against Flatpak and AppImage because they are designed around the assumption of a GUI).
Conveyor is used to distribute itself and it's a CLI app. I also use it to distribute other CLI tools and servers. It has some systemd support, for instance.
Albeit, the support for pure CLI apps on Windows/macOS isn't as strong as for GUI apps. There's an internal feature that isn't documented that's useful for it - it bundles a little GUI with a button that adds it to the user's path, and let's you trigger the self-update flow. We should expose that more obviously as a feature, although the incentive is low as most people distributing CLI apps and servers aren't paying customers.
The comment I replied to didn't mention anything about being close to frontier, just a blanket statement about Chinese Labs models being slow and inefficient.
People talk about frontier as if it's the only innovation worth pursuing. Deepseek V4 is far from fontier, but it's architecture is super innovative and efficient and what it achieves at that size (especially V4 Flash) is incredible.
I don't think Zig community is triggered, I think only Zig's creator is triggered because he is afraid of people interpreting this as "Zig is unsuitable for X".
I think a lot of people will, but those who do probably weren't the target audience for Zig in the first place?
Context matters. Big announcements and uninformed blog posts can kill your momentum.
I still remember the Twitter dev blog where they abandoned Ruby/Rails and the damage that did. It turned out Twitter was doing a lot of stupid things and there was a mismatch of tools and their goals. They loudly blamed the tools and people ate it up because Twitter was big, visible and adored at the time. Their conclusions bypassed most people’s ability to reason.
I remember that. It was the first time I heard about Scala.
I saw a lot of RoR companies/users thinking “should we do the same?” without even realizing that they do not have the same twitter scalability problems.
The same engineer at Twitter decided early on that no distributed messaging technology was good enough for Twitter, so they wrote their own. It fell over and they threw it away and wrote their own again. It fell over and they threw it away and now they use mainstream tools.
Similar to Discord's migration from Go to Rust. The measurements and reasons they gave were true but even by the time of the migration, Go had already moved on and improved. They were using an old version of Go.
Rust might be the right choice for Discord, I've no idea about that, but the problem is that the blog post lives on and influences people to this day.
[1]: https://www.youtube.com/watch?v=BCCJuOopLK8