Maybe it’s time we invent JPUs (json processing units) to equalize the playing field.
The best I can do is an ML model running on an NPU that parses JSON in subtly wrong and impossible to debug ways
Just make it a LJM (Large JSON Model) capable of predicting the next JSON token from the previous JSON tokens and you would have massive savings in file storagre and network traffic from not having to store and transmit full JSON documents all in exchange for an “acceptable” error rate.
Hardware accelerated JSON Markov chain operations when?
So you’re saying it’s already feature complete with most json libraries out there?
deleted by creator
Did you know? By indiscriminately removing every 3rd letter, you can ethically decrease input size by up to 33%!
Until then, we have simdjson https://github.com/simdjson/simdjson
JSON and the Argonaut RISC processors
Latest Nvidia co-processor can perform 60 million curly brace instructions a second.
Finally, something to process “databases” that ditched excel for json!
60 million CLOPS? No way!
Well, do you have dedicated JSON hardware?
@Randelung @seaQueue well, i have dedicated JavaScript hardware (https://developer.arm.com/documentation/dui0801/h/A64-Floating-point-Instructions/FJCVTZS)
The R in ARM and RISC is a lie.
Lie starts with L, dummy
The website title says “Arm Developer”, not “ARM Developer”, in a clearly non-acronym way so it’s a guide for making prosthetic hardware. Of course you want a cyborg arm to parse JS natively, why else even get one?
Nope it’s still a register-register op, that’s very much load-store architecture.
It’s reduced, not minimalist, otherwise every RISC CPU out there would only have one instruction like decrement and branch if nonzero. RISC-V would not have an extension mechanism. The instruction exists because it makes things faster because you don’t have to do manual bit-fiddling over 10 instructions to achieve a thing already-existing ALU logic can do in a single cycle. A thing that isn’t even javascript-specific (or terribly relevant to json), it’s a specific float to int cast with specific rounding and overflow mode. Would it more palatable to your tastes if the CPU were to do macro-op fusion on 10(!) instructions to get the same result?
Please no, don’t subsidize anything Java-Script. It will only make it less efficient.
And thus JsPU was born from Lemmy
NOOOOOOOO
Modern sites: This page requires a JsPU to run which is not present on this system. The website will run in reduced feature mode.
My thoughts on software in general over the past 20 years. So many programs inefficiently written and in 4th level languages just eats up any CPU/memory gain. (Less soap box and more of a curious what if to how fast things would be if we still wrote highly optimized programs)
Even if our apps used resources better the adware will just use the free space.
Answer: there’d be far less software in the world, it would all be more archaic and less useful, and our phones and laptops would just sit at 2% utilization most of the time.
There’s an opportunity cost to everything, including fussing over whether that value can be stored as an int instead of a double to save 8 bits of space. High level languages let developers express their feature and business logic faster, with fewer bugs, and much lower ongoing maintenance costs.
I fully concur. There’s tons of really inefficient software out there that wastes resources just because for a long time, available resources grew fast enough to just keep using more of them without the net speed of an application slowing down. If we didn’t have so many lazy SW devs, I suspect the reduction in needed CPU cycles would have a measurable positive effect on climate change.
Rockstar making GTA online be like: “Computer, here is a 512mb json file please download it from the server and then do nothing with it”
CPU vs GPU tasks I suppose.
GPU, render my 4.2 MB json file!
I’m afraid I can’t do that, Dave
Everybody gangsta still we invent hardware accelerated JSON parsing
Someone just needs to make a GPU-accelerated JSON decoder
Render the json as polygons?
It’s time someone wrote a JSON shader.
I have the same problem with XML too. Notepad++ has a plugin that can format a 50MB XML file in a few seconds. But my current client won’t allow plugins installed. So I have to use VS Code, which chokes on anything bigger than what I could do myself manually if I was determined.
Time to train an LLM to format XML and hope for the best
Do we need a “don’t parse xml with LLM” copypasta?
L arge L regex M odel
Would you rather have 100,000 kg of tasty supreme pizza, or 200 kg of steaming manure?
Choose wisely.
Careful, the 100,000 kg of pizza will turn into manure.
I figure I can probably convert about 10 kg into manure before it autoconverts into compost. Which is maybe even a worse problem.
there are simd accelerated json decoders
every day we stray further from god
Don’t worry, they still make extensive use of regexes.
I didn’t think any JSON parsers used regex given how simple the grammar is… but I’ve seen some horrors, so I shouldn’t rule it out.
Given it is a CPU is limiting the parsing of the file, I wonder how a GPU-based editor like Zed would handle it.
Been wanting to test out the editor ever since it was partially open sourced but I am too lazy to get around doing it
That’s not how this works, GPUs are fast because the kind of work they do is embarrassingly parallel and they have hundreds of cores. Loading a json file is not something that can be trivially parallelized. Also, zed use the gpu for rendering, not reading files.
As far as my understanding goes, Zed uses the GPU only for rendering things on screen. And from what I’ve heard, most editors do that. I don’t understand why Zed uses that as a key marketing point
To appeal to people who don’t really understand how stuff works but think GPU is AI and fast
