1342
submitted 1 month ago by seaQueue to c/[email protected]
top 50 comments
sorted by: hot top controversial new old
[-] [email protected] 280 points 1 month ago

Maybe it's time we invent JPUs (json processing units) to equalize the playing field.

[-] seaQueue 214 points 1 month ago

The best I can do is an ML model running on an NPU that parses JSON in subtly wrong and impossible to debug ways

[-] Aceticon 56 points 1 month ago

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.

load more comments (1 replies)
[-] [email protected] 54 points 1 month ago

You need to make sure to remove excess whitespace from the JSON to speed up parsing. Have an AI read the JSON as plaintext and convert it to a handwriting-style image, then another one to use OCR to convert it back to text. Trailing whitespace will be removed.

load more comments (1 replies)
load more comments (1 replies)
[-] [email protected] 32 points 1 month ago* (last edited 1 month ago)

Latest Nvidia co-processor can perform 60 million curly brace instructions a second.

load more comments (2 replies)
[-] [email protected] 15 points 1 month ago
load more comments (1 replies)
[-] Randelung 158 points 1 month ago

Well, do you have dedicated JSON hardware?

[-] [email protected] 101 points 1 month ago

Please no, don't subsidize anything Java-Script. It will only make it less efficient.

[-] [email protected] 56 points 1 month ago

And thus JsPU was born from Lemmy

[-] [email protected] 26 points 1 month ago

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)

[-] [email protected] 35 points 1 month ago* (last edited 1 month ago)

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.

[-] InternetCitizen2 18 points 1 month ago

Even if our apps used resources better the adware will just use the free space.

load more comments (1 replies)
[-] [email protected] 24 points 1 month ago
[-] Randelung 24 points 1 month ago

The R in ARM and RISC is a lie.

[-] [email protected] 14 points 1 month ago* (last edited 1 month ago)

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?

load more comments (2 replies)
load more comments (6 replies)
[-] [email protected] 15 points 1 month ago
load more comments (1 replies)
[-] [email protected] 116 points 1 month ago

Everybody gangsta still we invent hardware accelerated JSON parsing

[-] Overtheveloper 96 points 1 month ago

https://ieeexplore.ieee.org/document/9912040 "Hardware Accelerator for JSON Parsing, Querying and Schema Validation" "we can parse and query JSON data at 106 Gbps"

[-] ByteJunk 29 points 1 month ago

I'm so impressed that this is a thing

load more comments (1 replies)
[-] vvvvv 26 points 1 month ago

106 Gbps

They get to this result on 0.6 MB of data (paper, page 5)

They even say:

Moreover, there is no need to evaluate our design with datasets larger than the ones we have used; we achieve steady state performance with our datasets

This requires an explanation. I do see the need - if you promise 100Gbps you need to process at least a few Tbs.

[-] neatchee 12 points 1 month ago

Imagine you have a car powered by a nuclear reactor with enough fuel to last 100 years and a stable output of energy. Then you put it on a 5 mile road that is comprised of the same 250 small segments in various configurations, but you know for a fact that starts and ends at the same elevation. You also know that this car gains exactly as much performance going downhill as it loses going uphill.

You set the car driving and determine that, it takes 15 minutes to travel 5 miles. You reconfigure the road, same rules, and do it again. Same result, 15 minutes. You do this again and again and again and always get 15 minutes.

Do you need to test the car on a 20 mile road of the same configuration to know that it goes 20mph?

JSON is a text-based, uncompressed format. It has very strict rules and a limited number of data types and structures. Further, it cannot contain computational logic on it's own. The contents can interpreted after being read to extract logic, but the JSON itself cannot change it's own computational complexity. As such, it's simple to express every possible form and complexity a JSON object can take within just 0.6 MB of data. And once they know they can process that file in however-the-fuck-many microseconds, they can extrapolate to Gbps from there

load more comments (3 replies)
load more comments (1 replies)
load more comments (4 replies)
[-] 2deck 101 points 1 month ago

Render the json as polygons?

[-] Dasnap 82 points 1 month ago

It's time someone wrote a JSON shader.

[-] Lumisal 17 points 1 month ago

That just results in an image of JSON Bourne.

load more comments (1 replies)
[-] BlessedDog 16 points 1 month ago
[-] [email protected] 77 points 1 month ago

That is sometime the issue when your code editor is a disguised web browser 😅

[-] [email protected] 12 points 1 month ago

No, if you're struggling to load 4.2 mb of text the issue is not electron.

[-] [email protected] 55 points 1 month ago* (last edited 1 month ago)

there are simd accelerated json decoders

[-] manmachine 65 points 1 month ago

every day we stray further from god

[-] [email protected] 21 points 1 month ago

Don't worry, they still make extensive use of regexes.

load more comments (4 replies)
load more comments (1 replies)
[-] model_tar_gz 44 points 1 month ago

Would you rather have 100,000 kg of tasty supreme pizza, or 200 kg of steaming manure?

Choose wisely.

[-] [email protected] 28 points 1 month ago

200kg of steaming manure would be pretty sweet if you had a vegetable garden

[-] ByteJunk 13 points 1 month ago

Not sure if I'm just missing a reference here, but if you choose the pizza you can have both.

load more comments (1 replies)
load more comments (3 replies)
load more comments (2 replies)
[-] [email protected] 41 points 1 month ago

CPU vs GPU tasks I suppose.

[-] Potatos_are_not_friends 40 points 1 month ago

GPU, render my 4.2 MB json file!

[-] [email protected] 19 points 1 month ago

I'm afraid I can't do that, Dave

load more comments (1 replies)
[-] [email protected] 36 points 1 month ago

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.

[-] seaQueue 12 points 1 month ago

Time to train an LLM to format XML and hope for the best

[-] [email protected] 21 points 1 month ago

Do we need a "don't parse xml with LLM" copypasta?

[-] [email protected] 14 points 1 month ago
load more comments (2 replies)
load more comments (3 replies)
[-] [email protected] 24 points 1 month ago
[-] [email protected] 12 points 1 month ago

Except if it's a single line file, only god can help you then. (Or running prettier -w on it before opening it or whatever.)

load more comments (9 replies)
[-] [email protected] 24 points 1 month ago

Someone just needs to make a GPU-accelerated JSON decoder

[-] [email protected] 15 points 1 month ago
load more comments (14 replies)
load more comments
view more: next ›
this post was submitted on 14 May 2024
1342 points (99.0% liked)

Programmer Humor

31074 readers
116 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 4 years ago
MODERATORS