this post was submitted on 14 May 2024
20 points (100.0% liked)

Programmer Humor

32720 readers
368 users here now

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

Rules:

founded 5 years ago
MODERATORS
 
all 46 comments
sorted by: hot top controversial new old
[–] themoonisacheese@sh.itjust.works 8 points 7 months ago (4 children)

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

[–] seaQueue@lemmy.world 5 points 7 months ago (3 children)

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@lemmy.world 3 points 7 months ago (1 children)

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.

[–] seaQueue@lemmy.world 3 points 7 months ago

Hardware accelerated JSON Markov chain operations when?

[–] theterrasque@infosec.pub 1 points 7 months ago

So you're saying it's already feature complete with most json libraries out there?

[–] NigelFrobisher@aussie.zone 2 points 7 months ago* (last edited 7 months ago) (2 children)

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

[–] JackbyDev@programming.dev 1 points 7 months ago

60 million CLOPS? No way!

[–] ICastFist@programming.dev 1 points 7 months ago

Finally, something to process "databases" that ditched excel for json!

[–] 0x0@lemmy.dbzer0.com 2 points 7 months ago
[–] ApeNo1@lemm.ee 1 points 7 months ago

JSON and the Argonaut RISC processors

[–] Randelung@lemmy.world 3 points 7 months ago (2 children)

Well, do you have dedicated JSON hardware?

[–] MareOfNights@discuss.tchncs.de 3 points 7 months ago (2 children)

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

[–] xavier666@lemm.ee 3 points 7 months ago (1 children)

And thus JsPU was born from Lemmy

[–] MareOfNights@discuss.tchncs.de 2 points 7 months ago (1 children)
[–] xavier666@lemm.ee 2 points 7 months ago

Modern sites: This page requires a JsPU to run which is not present on this system. The website will run in reduced feature mode.

[–] ramble81@lemm.ee 1 points 7 months ago (3 children)

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)

[–] InternetCitizen2@lemmy.world 1 points 7 months ago

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

[–] masterspace@lemmy.ca 1 points 7 months ago* (last edited 7 months 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.

[–] raspberriesareyummy@lemmy.world 1 points 7 months ago

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.

[–] fleckenstein@social.lizzy.rs 2 points 7 months ago (1 children)
[–] Randelung@lemmy.world 1 points 7 months ago (3 children)

The R in ARM and RISC is a lie.

[–] ChaoticNeutralCzech@feddit.de 1 points 7 months ago* (last edited 7 months 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?

[–] Reddfugee42@lemmy.world 1 points 7 months ago

Lie starts with L, dummy

[–] barsoap@lemm.ee 1 points 7 months ago

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?

[–] XPost3000@lemmy.ml 2 points 7 months ago (1 children)

Everybody gangsta still we invent hardware accelerated JSON parsing

[–] Overtheveloper@lemmy.world 1 points 7 months ago (1 children)

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"

[–] vvvvv@lemmy.world 0 points 7 months ago (1 children)

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@lemmy.world 1 points 7 months 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

[–] lustyargonian@lemm.ee 2 points 7 months ago (1 children)

CPU vs GPU tasks I suppose.

GPU, render my 4.2 MB json file!

[–] Ironfacebuster@lemmy.world 1 points 7 months ago

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"

[–] MacNCheezus@lemmy.today 1 points 7 months ago

Someone just needs to make a GPU-accelerated JSON decoder

[–] 2deck@lemmy.world 1 points 7 months ago (1 children)

Render the json as polygons?

[–] Dasnap@lemmy.world 1 points 7 months ago (1 children)

It's time someone wrote a JSON shader.

[–] ApeNo1@lemm.ee 1 points 7 months ago
[–] AusatKeyboardPremi@lemmy.world 0 points 7 months ago (1 children)

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

[–] agelord@lemmy.world 0 points 7 months ago (1 children)

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

[–] porous_grey_matter@lemmy.ml 1 points 7 months ago

To appeal to people who don't really understand how stuff works but think GPU is AI and fast

[–] jballs@sh.itjust.works 0 points 7 months ago (1 children)

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.

[–] Johanno@feddit.de 0 points 7 months ago

Just install python and format it. Then

[–] vox@sopuli.xyz 0 points 7 months ago* (last edited 7 months ago) (1 children)

there are simd accelerated json decoders

[–] manmachine@lemmy.world 1 points 7 months ago (1 children)

every day we stray further from god

[–] xmunk@sh.itjust.works 1 points 7 months ago (1 children)

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

[–] dan@upvote.au 1 points 7 months ago

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.