|
energy usage.
Performance is a clear functional requirement that must be met, energy usage is a secondary quality attribute (a.k.a. non-functional requirement) that has gained attention in the last 2 decades.
Computers, servers, internet, cloud, big data etc already use (fill in your favorite number)% of our total energy consumption and that number is very likely to rise. Energy efficient algorithms help to slow that growth.
Another area where energy efficiency is important is mobile devices. Some of you may recall apps on your phone that drained the battery. And IOT, Arduino etc, think devices that run on battery or solar.
As a rule of thumb, faster algorithms use less energy, so improvements in performance might still be valuable.
mental exercise
Another argument for improving performance of algorithms is the mental exercise which is fun for some of us.
|
|
|
|
|
rob tillaart wrote: Energy efficient algorithms help to slow that growth.
That's a very good point. Considering my JSON library is meant to run on devices like 8-bit Arduinos, ESP32s, hopefully android phones at least, and windows, linux and apple PCs it pays to make it scale down to the smaller devices while still being efficient
I do that, and my JSON parser is so small the average query takes far less than 4kB. Between the locality and the small RAM usage, I expect the power consumption to be relatively small on small machines.
On PCs the code uses memory mapped files for performance, which of course would increase energy use despite the speed increase due to paging and such, but it would be hard to tell without profiling for energy use - a kinda tricky thing if you've never done it before.
Real programmers use butterflies
|
|
|
|
|
Reminds me a bit of the ISP's hawking their wares. Lot's of TV adverts, emails, etc., to upgrade that 1Gb/s line yo always needed. Now, if you're a corporation with lots of users and lots of concurrent traffic - maybe.
But for us mere mortals? I noticed no difference when they upgraded me (oddly, to keep the price down with a new 1yr sprecial) to 300Mb/s . As that deal wound down I managed a new one, good until the end of 2022, for $10 less by dropping to 200Mb/s (and letting them charge my credit card automatically). Still no difference.
I mean, in the great reality of things - who can even send you data that fast? And, with net traffic, how would it get to you. And that's the parallel.
Scores of years ago, when I spent some time on Chemical Kinetics, that was always an importing thing to consider - or discover: "The Rate Determining Step" - and whatever is done around it will have no real effect. In layman's terms, it the intrinsic idea of a bottleneck.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Yeah. The bottlenecks in this case depend widely on what you're doing.
With my JSON lib:
If you're reading bulk data from a file on a modern PC, your bottleneck is both file i/o *and* CPU
If you're reading data from a file on an atmega2560 your bottleneck is SD i/o *and* CPU.
If you're reading data from a file on an ESP32 your bottleneck is primarily SD i/o
If you're reading data from a network on an atmega2560 your bottleneck is primarily network i/o *and* CPU
If you're reading data from a network on most any other device your bottleneck is the network.
I always try to know where my bottlenecks are.  I always know where my towel is as well.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I always know where my towel is as we
I noticed, however, the conspicuous absence of your work with magnetic tape drives.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
This is a GREAT question, and it is SOLUTION Dependent!
If you could make the GNU Compilers twice as fast, PLEASE DO. Every time!
Well, until the time savings is so tiny, nobody cares.
We have a phrase: "The right answer late... Is the wrong answer!"
To us, it means that timing is part of the design/interface.
A Ping response that is normally > network timeout is useless to the recipient, as they gave up!
A page that takes 1 second longer than a user will wait, is too slow.
Sometimes, it's about "feedback" (Working... Spinners, Changing Screens, see Travelocity, LOL)
Sometimes, it's simply too slow to feel useable. Or I can do it by hand.
When I can launch EXCEL faster than find my calculator... You can bet I will use excel.
Therefore, either FIND a situation that REQUIRES twice as fast JSON parsing (Apps/Databases/etc), or move on.
Personally, I won't optimize beyond "acceptable" without a business requirement. (NOTE: A business requirement can be indirect, like the impact having 1 million of these running every day at full load).
As an example, we have an update statement taking 2 seconds. It feels slow to me. It's processing almost a million records. Part of a bigger process that is taking too long by 30 minutes. Not in a loop. I think I'll pass. [There is an 8 hour solution that would remove this. I logged a note, not in this pass. Making that update twice as fast is meaningless in this context]
|
|
|
|
|
One of the challenges in developing my JSON processor was making it scale to 8-bit machines with 4kB of RAM reading an SD card and parsing through JSON at it a whopping 24kB a second. On my crappy old i5 that has since died I got 600MB a second throughput on the top end. On my new machine I haven't tried it yet, but with my NVMe and this processor i expect well over 1GB/s speeds - probably multiple GB/s
The issue here is there's two problems with the same solution.
One problem is getting a tiny device to be able to parse JSON that is effectively "too big" for it to use using traditional JSON parsing methods.
The other problem is getting more capable machines to process bulk data efficiently.
The solution is the same - an optimized streaming pull parser whose memory usage is *not* in any way tied to the size of the document, or even individual field lengths.
But since it's a library, and because of the disparate devices, plus tackling two different problems, what "optimized" is varies widely and is in the eye of the beholder I guess.
It would be really hard to come up with requirements around performance without a specific use case for it, if not impossible.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: It would be really hard to come up with requirements around performance without a specific use case for it, if not impossible.
And neither having a specific use case is it guaranteed that you will come up with them...
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Because if the JSON parsing is in an inner loop that's executed frequently you'll see serious improvements in your application.
|
|
|
|
|
My point is even as an inner loop my JSON parser is *plenty* fast. Fast as all the other JSON parsers out there *except* simdjson which requires a lot of memory and a 64bit machine.
Real programmers use butterflies
|
|
|
|
|
Twice as fast doesn't matter if it's not the bottleneck. (I've spent lots of time optimizing code that wasn't the bottleneck... not very rewarding.) When you upgraded machines, you changed the bottleneck. Sometimes the bottleneck is the user (who can't tell the difference between 1/10th of a second and 1/20th and won't respond any faster no matter how much faster you make the software).
That said, when writing shared/reusable code, the bottleneck may be different for different users of the code. Someone trying to parse TBs worth of JSON or trying to shoehorn a small amount of JSON parsing into a very small space in an embedded processor could be very grateful for that extra work!
|
|
|
|
|
Member 14726719 wrote: Someone trying to parse TBs worth of JSON or trying to shoehorn a small amount of JSON parsing into a very small space in an embedded processor could be very grateful for that extra work!
Which is funny because those are the two exact things I designed this library for. 
Real programmers use butterflies
|
|
|
|
|
Then your effort isn't wasted. You're just not testing it with the right data set / machine configuration... (which would make the difference much more noticeable). For example, throw enough JSON at it that it takes a couple hours to work through it... you'll be really grateful for that 2x perf then. Or find a small embedded processor and download and run it there... (it could be processing configuration data, schedules, diagnostics, sensor data, or programming rules - like a Programmable Load Controller using JSON setups).
|
|
|
|
|
I don't have terabytes of space or an on-the-fly streaming JSON generator to make my PC run for hours over some JSON data. I would need many terabytes for that.
And on the embeddeds I'm using some real world data on the large side, and it takes seconds to parse. I can't really improve it though because it's on a dimestore 8-bit cpu not anything superscalar and it can barely keep up with the SD reader at half speed.
Real programmers use butterflies
|
|
|
|
|
Yep. Real world problems stink... You could always pick up a inexpensive external HDD or Thumb Drive (depending on how much data you need) and load it up with JSON files... you really don't need something that runs for hours, just something long enough that people would be willing to pay and/or update their software for something faster (or smaller).
I used to do code optimization on an 8080, that's was fun - counting the cycles of each instruction... writing my own multiplication routines...
|
|
|
|
|
So far I've been fine with 200MB. Eventually I may try 1GB or more, but I think 200MB of data is plenty for me to profile with. When I run the gnu profiler over my code, the timing is plenty with this dataset.
Real programmers use butterflies
|
|
|
|
|
No code "optimization" giving a twofold speedup (or less) is worth it.
Optimizing a library function consuming ten percent of the total CPU power consumed by a production run of your application (or less) isn't worth it.
First law of code optimization: Don't do it.
Second law of code optimization: If you have to do it, don't do it yet.
"Optimization" is one of the most poorly understood, and therefore one of the most badly abused, concepts of the software business.
|
|
|
|
|
I'm not sure I agree with your thresholds but I at least can respect the sentiment.
I'm satisfied with the optimizations I have done. Most were more than a 2 fold speed up. More like 4x-6x overall speedup in final throughput, with every optimization i made considered together.
But where most of the optimization was was in ram use, and every kB counts when you're building something that runs in under 4kB - because that's all some machine have for RAM. 
Real programmers use butterflies
|
|
|
|
|
back when I was building Industrial control software (some of these systems had over 10,000 I/O points), every processor tick counted for getting as close to real time as possible. When I had to use other's libraries: I graded them on speed first, ease of use second.
one of the bigger reasons for speed was: I had no idea what the final computer would be on specs so my test computers would be at least 10 years old running XP with 2GB ram, and a 800mhz processor. if it ran fine and kept the CPU< 5% for normal load, I was pretty confident that it would run on any PC the customer supplied with out much issue.
the embedded industry is even more hard core, and is fun challenge to work with the least amount of resources possible to not max out the CPU or memory on those little chips.
I still bring that same mentality when working on any platform now. If I'm building a website or a desktop app or service, I have no idea what the end users setup is going to be like and may be trying to run still on an 800mhz because they can't afford anything newer. (and yes I know of a few people in this situation).
so yes working on any project to make it just a little faster is a definitely a  with me, and likely many others out there.
|
|
|
|
|
Well, in my case there's a significant downside to optimizing the way simdjson does - simdjson must index the entire document, and while it does so very quickly, it uses gobs of RAM.
My parser will run reasonably on a 4kB machine.
Consider that this "twice as fast" scenario is only on workstations and servers that are 64-bit and like i said, requires gobs of RAM.
Even without it I get massive throughput, even on old PCs so what's the point of going further than that when doing so requires me to load the entire document into RAM, and makes it so it can't run on an 8-bit machine - won't even compile.
That was my calculus. I hope that seems reasonable, but if it doesn't I'm more than happy to discuss it. I'm just a nerd like that.
Real programmers use butterflies
|
|
|
|
|
First of the year, it's like a Winter Wonderland out there!
As in "I Wonder when that white cr@p is going to bugger off?" 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Saw a documentary about a Belgian couple that emigrated to Norway, they discovered a bit too late that the region they were in was notorious for the amount of snow falling. Only a few months of the year they did not have to shovel snow.
|
|
|
|
|
We had a couple move in next door to us one fall. In the spring they sold the house because they couldn't handle the snow. They were from Wisconsin and I'm in Denver.
|
|
|
|
|
And they didn't enjoy riding a one-horse open sleigh?
|
|
|
|
|
So do you prefer rain and mud?
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
