| ▲ | vmg12 a day ago |
| Drawing to the terminal / rendering / whatever, this is all arguing semantics and very uninteresting and not insightful. > they need a high powered game engine rendering loop Don't believe the bs on twitter. Claude code source was leaked, there is no high powered game engine rendering loop. > It needs to stream text to stdout These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown. If the work was split across threads they would not use anywhere close to as much power and there would not be a slow ui. If you think this is actually nothing, prove it. Put the code up on github that shows taking a constant random stream of markdown, code, and diffs and displays it in the terminal can be done cheaply on a single thread. The reason the computer gets hot and uses more power is because the cpu is getting close to 100% utilization. |
|
| ▲ | wild_egg a day ago | parent | next [-] |
| There are two different arguments here. > These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown. The first argument is that these are expensive operations. They are not. And the second argument is the assumption that these are desirable things for an agent system to be doing. That's a personal preference but, personally, I don't want them and would appreciate a way to disable all of that to reduce CPU use. |
| |
| ▲ | vmg12 21 hours ago | parent [-] | | The argument is that doing it all on a single thread will result in high cpu utilization and that is what makes the power usage spike and the pc feel hot. Thats it. A lot of people go “js is bad” reflexively and they are right for the wrong reasons. Its not because js (specifically v8) is slow. I have many websites and web based apps open and none fuck up my laptop as hard as claude code. | | |
| ▲ | hahahaa 19 hours ago | parent [-] | | Yeah I don't get it we had terminals on single core machines. In early 2000s I am sure they could handle the UI of Claude (probably IO too). | | |
| ▲ | wild_egg 19 hours ago | parent [-] | | Early 2000s tech could absolutely handle LLM agents as a client. They output like 1-2kbps and even dial up modems would have plenty of capacity for other traffic. The UI itself requires laughably simple tech. The idea that a markdown renderer that can produce HTML at 50MB/s would use much CPU to process incoming hundreds of bytes per second is insane. CPU should be idle even if doing that constantly. Nevermind that between turns it has nothing to do whatsoever and should use zero CPU at all. |
|
|
|
|
| ▲ | mixmastamyk 21 hours ago | parent | prev | next [-] |
| Stuff doable on a pentium 90, and before that, just slowly. |
| |
| ▲ | hahahaa 19 hours ago | parent [-] | | I wonder if those were fast enough nostalgia says yes but I bet it was dog slow if we tried today with 2026 lens. | | |
| ▲ | mixmastamyk 18 hours ago | parent [-] | | My Turbo Pascal programs could calculate and print to the screen faster than could be read, on a 486. With DOS however. I picked the P90 because I remember running Linux ~1.0 and/or NT on it, with real multitasking and services etc. Those soaked up many of the cycles. Another story, around Y2k/Win2k was asked to write a C program to record all the files/sizes on the C: in to file. Then something would be installed, my program run again, and the results diffed. Despite thousands of files the program was done before the enter key came back up. Boss told me that he thought the program was cheating. That’s just how fast modern computers are these days, I said. When running C code anyway. That perf is still available today, compare astral’s uv to slow competitors. Just takes some investment, though probably less when boosted by VC bionics. | | |
| ▲ | wild_egg 17 hours ago | parent [-] | | "The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry." — Henry Petroski | | |
|
|
|
|
| ▲ | nnmg 21 hours ago | parent | prev | next [-] |
| I don't think any of that seriously counts as real work. Casey Muratori addressed this years ago with the windows terminal drama, https://github.com/cmuratori/refterm |
|
| ▲ | cdelsolar 17 hours ago | parent | prev | next [-] |
| The heck? It does all that rendering for a tiny fraction of the total amount of time that the TUI is running. The streaming is IO bound, there’s no way that it’s outputting nearly enough text to tax the CPU that much. |
|
| ▲ | anthk a day ago | parent | prev | next [-] |
| Sorry, but nope; Golang there would be there a beast doing that in a much, much faster way. Not to mention C/C++ with NCurses. |
| |
| ▲ | vmg12 a day ago | parent [-] | | > If you think this is actually nothing, prove it. Put the code up on github that shows taking a constant random stream of markdown, code, and diffs and displays it in the terminal can be done cheaply on a single thread. Put up the code and prove it. We already know exactly how fast golang is in comparison to nodejs on basic numeric computations, it's roughly 40 to 50% faster. | | |
|
|
| ▲ | redsocksfan45 a day ago | parent | prev [-] |
| [dead] |
