SoylentNews is people
SoylentNews
Submitted via IRC for AndyTheAbsurd
Hammered by the finance of physics and the weaponisation of optimisation, Moore's Law has hit the wall, bounced off - and reversed direction. We're driving backwards now: all things IT will become slower, harder and more expensive.
That doesn't mean there won't some rare wins - GPUs and other dedicated hardware have a bit more life left in them. But for the mainstay of IT, general purpose computing, last month may be as good as it ever gets.
Going forward, the game changes from "cheaper and faster" to "sleeker and wiser". Software optimisations - despite their Spectre-like risks - will take the lead over the next decades, as Moore's Law fades into a dimly remembered age when the cornucopia of process engineering gave us everything we ever wanted.
From here on in, we're going to have to work for it.
It's well past the time that we move from improving performance by increasing clock speeds and transistor counts; it's been time to move on to increasing performance wherever possible by writing better parallel processing code.
Source: https://www.theregister.co.uk/2018/01/24/death_notice_for_moores_law/
(Score: 2) by pkrasimirov on Sunday January 28 2018, @12:07PM (7 children)
> it's been time to move on to increasing performance wherever possible by writing better parallel processing code.
In startups and small-scale projects, or generally in code running on limited resources, perhaps yes. In modern "professional" software even single-threaded algorithms are yet to be refined. I mean I have seen a background task taking 8+ hours doing 10k+ SQLs in a for-loop. When rewritten to be one SQL as it should, it completes in around a minute. The developer claimed "great success" [youtube.com] and proceed to get his annual bonus payment. And I'm not talking some irrelevant task, it's related to the payslips of thousands of unrelated and unsuspecting people.
So, yeah. No law can substitute thinking and coding, and that's not new.
(Score: 2) by JoeMerchant on Sunday January 28 2018, @02:03PM
I recently optimized a single-threaded app that we use at work's execution time down from ~8 minutes to just under 1 minute... as the data it crunches inevitably grew it started around a minute of execution time and grew to ~8... there might be a dozen people who execute this process, all told it might be running 12 times a day on average (heavy user hitting it 3-4x per day, other users hitting it once every 3-4 days or even less frequently). Took a half-day to run the optimizer, identify the big bottleneck, address it, test it, verify no change in output. Up to that point, A) it wasn't a big enough issue to warrant the attention, and B) optimization on a smaller dataset might not have addressed the problems that became clear when the dataset grew. All told, a single small subroutine grew from 4 lines of code to about 12, adding a buffer that stores a costly result and flushing that buffer when changes in inputs invalidate it: 9x speedup. If we wanted another 9x speedup today, that would be a LOT more costly to achieve - the profiler didn't identify any more low hanging fruit. Maybe when the database grows some more, some new low-hanging fruit will present itself.
🌻🌻 [google.com]
(Score: 2) by JoeMerchant on Sunday January 28 2018, @03:10PM (3 children)
Now, for your background task that was taking 8+ hours to execute - if that runs once a month unattended, maybe it's not such a big deal. Sure, it can be >1000x faster, and good on you for improving it, but if it was meeting the users' needs, was it really broken? If there were other things that required attention, things that were actually losing data or returning incorrect results, maybe the question of optimization is moot if the process already completes "overnight" for something that doesn't ever need to be run, then run again quickly?
As for me, I'd go for the faster execution just because it's more testable, but if your "great success" developer had a blind spot there, but was contributing value in other areas (granted, unlikely), things that don't need to be fixed aren't really broken.
🌻🌻 [google.com]
(Score: 4, Funny) by pkrasimirov on Sunday January 28 2018, @04:06PM (2 children)
> if it was meeting the users' needs, was it really broken?
You are ready to be a manager...
> things that don't need to be fixed aren't really broken.
... in operations.
(Score: 4, Insightful) by JoeMerchant on Sunday January 28 2018, @04:26PM
(Good) managers do add value. If you can make a fix like that in less than the time it takes the non-optimized code to run once, sure - go for it, even take a couple more days to prove it's right and "big win" - on the other hand, when there's a loss-of-revenue fire on another project, spending 3 days to speed up something that nobody is complaining about? That's 3 days of lost revenue for "no good reason."
🌻🌻 [google.com]
(Score: 2) by Virindi on Tuesday January 30 2018, @03:02AM
The reason people are employed or contracted is so that they can do things which provide value to the employer. If something genuinely is fine and improving it would provide no value, the employer should not pay for it.
The problem comes when the engineer who is more knowledgeable about the system, sees a problem that the employer does not. This is the common case; often something 'works fine' now but is set up in a way that will cause problems later. But whether this is actually a problem worth fixing depends on both technical and business considerations.......it is a cost/benefit calculation. That is the supposed job of management*, and it is not wrong.
*In a society/environment where people are not acting like little kids who constantly have to be prodded to keep doing work.
(Score: 0) by Anonymous Coward on Sunday January 28 2018, @05:00PM (1 child)
As I teach new programmers. Break the job up! Think like fire fighter. Bucket brigades. SQL is not effechent database. Get data archers to design better databases programmers do not understand. At least for 5 to 10 years.
Personally I would like all programmers to write code that only use 10 k of memory or less. Really learn and show their skills.
(Score: -1, Flamebait) by Ethanol-fueled on Sunday January 28 2018, @06:51PM
Me Chinese, me play joke, me go pee-pee in their Coke!