fibonacci112358

It's really strange, you see people claim the same on the Codes subreddit. I can also run Astra xHigh at least for a few days with my 20x, but I don't use any of the token hungry patterns like orchestrators and such (only the code reviews have a skill using either 4 or 8 sub agents, some being Terra/Luna and none Astra). I did have a month ago a period or 2-3 days when usage was draining like 5x faster than usual, maybe some people are seeing smth like that? But more likely many sub agents and other patterns eating tokens.

Is everyone rushing to launch something before Astra tomorrow?

The code in compilers is the closest to your typical app you can get in a benchmark like SPEC, eveerything else is actually far more specialized. Compiler code is full of small basic blocks, lots of branches, indirect memory access; it's actually harder to get good performance for such code, both for CPUs and compilers (that was part of the death of Itanium too).

I have the opposite problem with Code, it barely writes any comments even for fairly complex C++ code blocks (systems programming stuff), have to prompt it to add extra details about why it did something. Request in agents.md doesn't seem to help much.

/code-review in Claude Code spawns a lot of sub-agents (counted like 8 once), each looking at the code from some certain aspect (like correctness, maintainability, duplication, testing, etc). It eats tokens like crazy doing that, but also covers quite a lot. The default code review in Codex does far less (feels like it's only correctness) and doesn't uses subagents. Actually I made a skill for Codex that does a review closer to what Claude does by default, but using like 4-5 agents and some being cheaper models/less than xhigh reasoning. I'm getting pretty nice reviews with that that cover more than just correctness.

Don't bother replying to the trolls around here.

So this is where all the memory they bought is going to.

MSVC (Microsoft's C++ compiler) had an pretty advanced inter-procedural (LTO) way of doing devirtualization, but it was so buggy and slow that it eventually got disabled. It was trying to prove that a pointer can only target a certain class all the time (or maybe a couple), but things get really messy with typical C/C++ code and even worse once you have DLLs which may inject new derived classes.

Sadly for them, Nvidia didn't stay still in the meantime and created the next generation of CUDA, CuTile for Python and soon for C++, through CUDA Tile IR (using a similar compiler stack based on MLIR).

Event though it's not portable, it will likely have far greater usage than Mojo just by being heavely promoted by Nvidia, integrated in dev tools and working alongside existing CUDA code.

Tile IR was more likely a response to the threat of Triton rather than Mojo, at least from the pov of how easy is to write a decently performing LLM kernel.

Maybe OP was thinking about compilers "cracking" certain SPEC benchmarks: implementing exactly the optimization needed to boost a benchmark quite a lot, but that opt. probably won't apply to any other code out there (usually it's so targeted and risky with general C/C++ code that intentionally it doesn't work on anything else). That happened a couple of times over the years, I know about the Intel compiler cases for ex. I can certainly see LLM providers adding tricks that help a certain class of benchmarks, but doesn't help much for anything else.

They won't, Windows isn't even compiled with AVX2 extensions on, even though every CPU in the last 10y+ supports it, for the fear of it running on some machine that doesn't have AVX2. The whole "CPU unsupported" thing is from the marketing side, trying to push purchase of new hardware, not from the actual devs.

I'm not 100% sure, but I think the main reason the new Win11 apps like Notepad, File Explorer, Task Manager have a slow UI and the piece-by-piece drawing issues is because they combine UWP (the "new" tech) with the old Win32 controls, they are not a from-scratch rewrite. There seems to be some big overhead in using the two different UI frameworks together.

There was an attempt to make a Chrome OS competitor that had the entire UI rewritten in UWP, and when that got canceled it seems MS saved the new start menu + taskbar and bolted it on top of Win10, and for Explorer and other apps made this UWP+Win32 abomination. Actually when you profile Explorer you can also see DirectUI running, which is I believe another UI framework from the Office org. this time (maybe it's related to OneDrive).

Btw, apps written in C# using WPF can be surprisingly fast, so it's not really a problem of .NET managed vs. native apps. For ex. may favorite Git GUI (git-fork.com) is C#/WPF.

Thanks for the reply! I'm in WA, the moonlighting IP law seems very similar to CA. Both my contract and current HR guidance state that any invention is mine if done outside work hours, not using their hardware AND doesn't compete with the company and harms it's business interests - the vague part, especially with a company that has it's fingers in dozens of different software.

The app itself is similar to a module of a much larger product the company sells, but that product is far from being a money-maker for the company (may just break even). People are certainly not buying the whole product because of that module, it's a nice thing to have. There are several other companies that do sell stand-alone apps similar to mine though, there is a market for it.

The other concern was whether starting now the work based on the MIT open-sourced version of my app creates a clean slate for me, since the previous work was done in part during work hours on their PCs. Open-sourcing the app through my employer was the only way not to lose it completely in case I switch companies, and have a chance to try a startup based on it.

Some advice I've got was that forking the OSS version should be done by a friend (not in the company) and I should work on it in the background and officially join later, after I quit - that also feels sketchy.