251–260 of 264 posts
Earlier quoted context omitted.
They aren’t going away. They are an obvious answer to Microsoft GUI development being in the wilderness for 20 years.
Java has been right there all along like the awkward best friend in a romcom.
In particle physics, processing jobs face a limit of about 2GB/core. This is driven by the realities of "grid computing". The hardware in the computing facilities have approximately 2GB/core and jobs allocate based on number of core. This ratio has been fairly stable for a long time. Some facilities may have a bit more RAM per CPU core but 2GB/core is the general rule of thumb. I hazard a guess that this will not cha…
I remember reading somewhere about an HPC "rule of thumb" that was like 1GB RAM/1GHz of processing is about the right amount for most applications.. Don't recall where that came from or what the exact reasoning was. That kind of aligns with 2GB/core.. Was that a thing?
In particle physics, as more of the code is being GPU-accelerated, there is now another integer ratio to worry about optimizing: CPU core per GPU device. Across the landscape, some jobs have zero GPU acceleration, others may need 100 cores to keep a GPU busy, or only 1 core. Yet others can tune their CPU/GPU ratio to optimize throughput given what hardware ratio a given facility provides. Only a fraction of the software in the ecosystem takes up this challenge.
Most physicist pretending to be software developers or vice versa who are involved in the field do not consider any of these computing realities. At some level, that's natural and excusable. It's hard enough to develop the simulation and reconstruction and analysis algorithms. Simultaneously optimizing their implementation for throughput on a given hardware assumption is even harder. Harder still is to do that optimization over the variety of hardware assumptions. There are only a few cases where this holistic thinking has driven the design of the software.
Earlier quoted context omitted.
I remember reading somewhere about an HPC "rule of thumb" that was like 1GB RAM/1GHz of processing is about the right amount for most applications.. Don't recall where that came from or what the exact reasoning was. That kind of aligns with 2GB/core.. Was that a thing?
Maybe it was a thing from before clock speeds saturated and Moore's law mutated into being satisfied by ever increasing core count? It could have been useful when spec'ing hardware with the goal of running multi-threaded jobs that scale both their throughput and RAM requirements linearly with number of threads. That would make it sort of a continuous version of the more discrete GB/core rule of thumb. However, such l…
I feel like we're about to learn a similar lesson with generative AI. Things don't always get easier/better/faster.
Earlier quoted context omitted.
> I don't know what needs to change for things to get better. Studios need to start creating custom engines again, for one. We'll get better games with less unsatisfying jank, some of the projects will actually cost less (which is paradoxical to some) and performance is likely to jump significantly. Off-the-shelf engines have as many costs as they have benefits, but like a lot of technology people refuse to look at t…
Game studios should choose CryEngine/Decima again over UE5
I will say though, optimizing memory usage is easier than ever. Doing a scan of your codebase with an LLM for _large_ memory gains can probably shave a decent chunk off of any application with ease. You don't have to go down the rabbit hole, but taking the top 3 large things it catches would probably result in notable gains for minimal time usage.
Hell, I've hunted down code that was causing an OOM from a coworker that ran a regex that would have to search the entire string of a base64 payload that was often around 24MB, when it very easily could have been a basic string operation on the first 50 characters or so. I caught it myself, but went back after with an LLM about 8 months ago and it also spotted it with a vague point in the direction of where it could be.
There are probably a lot of small slip ups across a codebase that are simple fixes that add up over time, but we never catch because we're not actively profiling.
Earlier quoted context omitted.
The classic excuse for industry-wide incompetence. The average programmer today can't write good code even if told it's an explicit priority. The manager wants the Submit button to submit the form, they rarely care how the programmer does it. It's the programmer that chose to install the 11,000 node_modules, to use React with 3 layers of state management on top with hybrid SSR/CSR and to do Kubernetes because that's…
How much "junk" do you want to get rid of? I suspect you're imagining something like, just write some vanilla JS and maybe some tasteful but not bloated CSS. You could do that. Then I'll come along with my old man Win32 skills and write a form with a submit button that sends the data by doing a memcpy into a UDP packet. It will take 300 kilobytes of RAM and start in 0.1 seconds. That'll make it approx 100x more RAM e…
No, even at these high memory prices it's cheaper to produce code as fast as possible than to spend the time to optimize it for efficiency. It has always been the case that hardware improves at a faster pace than software. So what will happen is that we will get tech improvements in hardware that will reduce its price faster than we can write software to fully take advantage of the hardware. The current bottle neck t…
Will we? I don’t think new capacity will come online for several years and at the current rate there’s not a lot of evidence that the new capacity won’t simply be scooped up by the big data centers like they are now. At the very least we’re in for a rough 4 years at least
I know we are having issues with china and they can't produce the latest tech but I suspect they will produce ram so cheap relative to the competition that companies will find away to buy from them.