Slashdot Mirror
Performance Bugs, 'the Dark Matter of Programming Bugs', Are Out There Lurking and Unseen (forwardscattering.org)
Several Slashdot readers have shared an article by programmer Nicholas Chapman, who talks about a class of bugs that he calls "performance bugs". From the article: A performance bug is when the code computes the correct result, but runs slower than it should due to a programming mistake. The nefarious thing about performance bugs is that the user may never know they are there -- the program appears to work correctly, carrying out the correct operations, showing the right thing on the screen or printing the right text. It just does it a bit more slowly than it should have. It takes an experienced programmer, with a reasonably accurate mental model of the problem and the correct solution, to know how fast the operation should have been performed, and hence if the program is running slower than it should be. I started documenting a few of the performance bugs I came across a few months ago, for example (on some platforms) the insert method of std::map is roughly 7 times slower than it should be, std::map::count() is about twice as slow as it should be, std::map::find() is 15% slower than it should be, aligned malloc is a lot slower than it should be in VS2015.
In SW development it's easy to spot obviously dumb decisions in code and those are probably plentiful. But it's rarely as obvious what the best solution is, mostly because there's always a tradeoff. You can generally use up extra memory in order to boost processing speed (i.e. lookup tables, rainbow tables) and vice versa. This in itself means that on a machine where memory is the bottleneck (and if you exceed it you have paging and swapping on disk) the "best" solution is different than on a machine with excess memory, but a weak processor.
TL;DR: benchmarks depend on hardware. "Best" is often unattainable in a general sense.
And for nearly all applications, they don't give a shit. Computers are today faster than they need to be for nearly all applications the average office runs into.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
It's stupid to call them "the dark matter of programming bugs". We were just accustomed to this being the way Microsoft did things, not a bug, a feature.
That stems from Microsoft, originally writing for IBM, being paid per thousand lines of code. As such it made sense that software was not written efficiently because the programmer was not rewarded for efficiency, it merely had to fit within available memory. Unfortunately it seems that this practice has not stopped given the sheer size of Microsoft operating systems relative to the amount of end-user functionality that has been added since the days of say, Windows 3.1.
Do not look into laser with remaining eye.
A performance bug is when the code computes the correct result,
So... not bugs at all, then, really.
Inefficiency is frequently a better option than nothing at all, and all code suffers from bit-rot.
>> that the user may never know they are there
They will if they try to run a lot of them on a machine with finite resources, like a phone. Or it's a process that's iterated frequently, like a "big data" operation. But if the end user STILL doesn't notice it...then it's hard to call it a bug.
On the other hand, the performance/just-get-er-done trade-off is well known to programmers of all stripes. (At least I hope it is - are people really finding new value in the article?) There's the quick and dirty way (e.g., a script), and then there's the "I can at least debug it" way (e.g., a program developed in an IDE), and then there's the optimized way, where you're actually seeing if key sections of code (again, especially the iterated loops), are going as fast as possible. Generally your time/cost goes up as your optimization increases, which becomes part of the overall business decision: should I invest for maximum speed, maximum functionality, maximum quality, etc.
I came here to say this, mostly.
I *know* that there are plenty of places in our software that I could spend an hour or two, and rewrite an algorithm to run in 1/5th the time. And I don't care at all, because the cost is too low to measure, and usually, performance bottlenecks are elsewhere.
Who really cares if I can get a loop to run in 800ns instead of 1500ns, when the real bottleneck is a complex SQL query 11 lines up that joins 11 tables together and takes 3 full seconds to run?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Is it a problem, if no one notices? Most code can be optimized more than it is, but if everyone's happy with how it works, what's the problem?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Like windows update doing something in N*N instead of N?
Yeah it's a little bit slower... At the beginning.
Programmers need to always keep in mind that their software is always going to be used, by some people, for a longer duration than intended, and with larger datasets than expected.
of C, C++ ("embedded C++"), assembly on Intel (with MMX/SSE/SSE2/...) and some VLIW architecture on TI C64x.
But I am now managing projects.
Because nobody gives a shit about performance, except for very specific niches (here audio video codecs).
The first example: std::insert should do nothing if an item is already present. So calling std::insert only if the object is not yet present is 100% equivalent to calling std::insert directly, but it is 7 times slower.
This violates the important principle that when using a library, the obvious way to do things should be the fasted. So hacks are required to make your code fast, and that shouldn't happen.
I assume the explanation is probably that std::find is small enough to be inlined, while std::insert is too big, so nothing is inlined at all when you call it.
Maybe in your world, but when weighted down with sloggy operating systems and minimal memory (typical of many Windows 10 installations TODAY), code can get pretty slow.
For a very long time now, there have been libs that add breakpoints to examine how long processes are taking, think: debug mode, that can pinpoint problem areas pretty easily. Not enough coders use them.
It gets worse when a user has 94 Chrome tabs open, something in Office, and an AV app running.... all on a laptop whose processor speed is measured in furlongs per fortnight.
Yeah, SOME computers are way faster, and some have been habitually overloaded with things outside of a coder's control yet their app still must perform within a "reasonable" amount of time. Blah.
---- Teach Peace. It's Cheaper Than War.
It is a losing battle to try and solve performance in the programmer space. The Compiler does a much better job of optimization due to a multitude of compiler trics including both Static and dynamic analysis, cache analysis and so on. The programmer trying to write the most efficient code should rather spend his/her time trying to use out of the box algos as far as possible as the compiler knows how to fine tune those. next they should run a profiling tool like jprofiler and see where the job is actually spending its time rather than trying to say this is probably the heaviest part of the program. With multiple cores and multiple instruction pipelines and optimizing compilers the bottleneck is oftentimes not where we would think it to be. Once we find the bottleneck using a profiling tool than we can optimize it. In most cases 2% of the code is causing 98% of the bottleneck so its a much better use of programmer time (which is of course more expensive than computer time in most cases) to work backwards.
1 Write your code so that its correct irrespective of efficiency,
2 profile and then
3 fix the bottlenecks
rather than trying to find the most efficient algorithms before you write your code.
**Life is too short to be serious**
Programmers love to use the cop-out
"Premature Optimization is the root of evil"
dogma which is complete bullshit. It tells me your mindset is:
Except later never comes. /Oblg. Murphy's Computer Law:
* There is never time to do it right, but there is always time to do it over.
As Fred Brooks said in Mythical Man-Month.
Which can be translated into the modern vernacular as:
* Show me your code and I'll wonder what your data structures are,
* Show me your data and I'll already know what your code is
There are 2 solutions to this problem of crappy library code.
1. You are benchmarking your code, ALONG THE WAY, right?
Most projects "tack-on" optimization when the project is almost completed. This is completely BACKWARDS. How do you know which functions are the performance hogs when you have thousands to inspect?
It is FAR simpler to be constantly monitoring performance from day one. Every time new functionality is added, you measure. "Oh look, our startup time went from 5 second to 50 seconds -- what the hell was just added?"
NOT: "Oh, we're about to ship in a month, and our startup time is 50 seconds. Where do we even begin in tracking down thousands of calls and data structures?"
I come from a real-time graphics background -- aka games. Every new project our skeleton code runs at 120 frames per second. Then as you slowly add functionality you can tell _instantly_ when the framerate is going down. Oh look, Bob's latest commit is having some negative performance side effects. Let's make sure that code is well designed, and clean BEFORE it becomes a problem down the road and everyone forgets about it.
2. You have a _baseline_ to compare against? Let's pretend you come up with a hashing algorithm, and you want to know how fast it is. The *proper* way is to
* First benchmark how fast you can slurp data from a disk, say 10 GB of data. You will never be FASTER then this! 100% IO bound, 0% CPU bound.
* Then, add a single-threaded benchmark where you just sum bytes.
* Maybe, you add a multi-threaded version
* Then you measure _your_ spiffy new function.
Library Vendors, such as Dinkumware who provide the CRTL (C-Run Time Library), _should_ be catching these shitty performance bugs, but sadly they don't. The only solution is to be proactive.
The zeroth rule in programming is:
* Don't Assume, Profile!
Which is analogous to what carpenters say:
* Measure Twice, Cut Once.
But almost no one wants to MAKE the time to do it right the first time. You can either pay now, or pay later. Fix the potential problems NOW before they become HUGE problems later.
And we end up in situations like this story.
Indeed. A human being can not even perceive a difference between 1 millisecond and 1 microsecond.
But, repeated a million times, the former turns into 15 minutes, whereas the latter is still merely a second. Food for thought...
In Soviet Washington the swamp drains you.
Check the links, decent code and analysis. Short and simple. I recently found a very similar bug in both PHP and HHVM with their trim() function (and variants there of). In both PHP and HHVM, trim() unconditionally allocates more memory, even if there is no white-space on either end of the string to trim. It is faster to write PHP code to check for white-space on both ends and then conditionally call trim() on a string.
It's not even clear if some of the stuff he says is a bug. For example, his aligned memory allocation example takes 100ns longer than it "should" when calling an Intel specific function. It's not at all clear what the Intel function does differently, if anything... Seems to be part of one of their frameworks that makes cross-platform aligned memory allocation easier.
It may not be comparing like-for-like. I have a feeling Microsoft will respond to his bug report with little enthusiasm.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
The programmer is writing crappy and unoptimized code.
It's a myth of the cult of unit-testing that all tests passed == no bugs. Correctness bugs outlive all executed tests, and are a worse form of dark matter because they give no outward signs.
In many simple situations, yes.
But there are plenty of cases where you are operating on such a large scale that using programming resources to optimize performance is a a good tradeoff. As example: in one customer case a 1% total increase in efficiency maps to 5000+ euro/month in the costs they pay to host the solution, on a yearly bases that buys quite many programmer days of optimization.
Come back when you want to talk unnecessary complexity increases, like the update procedure that takes exponential time.
I interact with a piece of code I don't maintain that has this issue. A piece of Visual Basic (don't get me started) that copies from a source to a destination. However instead of using B=A to move the data, the author used copy(A) and paste(B). The data therefore interacts with the clipboard, slowing the process down.
The issue might not be noticeable on a small amount of data. However, I use this piece of code to move gigabytes of data every day.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
Same here
The users are getting a correct result. Good.
The developers moved on to something else that's also important. Good.
The machine is doing 15% more work than strictly necessary... Is it slowing down the users? No. Are we getting hammered by the electricity bill? No. Is the machine getting tired? No. So what exactly is the problem?
Like the real Donald (Knuth) said: "premature optimization is the root of all evil (or at least most of it) in programming".
We were required to install it on our Linux servers - we run CentOS (same as RH). Every few days, the stupid monitor is suddenly eating 99%-100% of the CPUs... for *hours*. Overnight.
I attached strace to it, and it's in some insanely tight loop, looking at its own threads.
Maybe if I prove that it's doing it on multiple servers (it is, but I have to catch it - nothing's reporting this, unless it runs the system so hard it throws heat-based machine checks), and put a ticket in, and *maybe* the team that forced it on us will *maybe* talk to CarbonBlack....
I have *zero* doubt that there's a ton of other COTS products with issues like this.
Being an old fart, in my day, I remember the worst performance problems were caused by programmers with their own badly written library of functions and objects that they included everywhere, most of those were from their very first weeks of being a programmer and they sucked badly.
And if you think the performance N.F.R. is dark, wait 'til you find out about security.
NFR
Congratulations - you've invented the "message queue".
Assuming that there aren't other disadvantages, if there's a faster algorithm or faster implementation that achieves the same goal, the slower approach is slower than it should be. For instance, using bubble sort when you could use quicksort.
Just barely meeting your requirements leaves you vulnerable to a competitor who can do a better job.
Contribute to civilization: ari.aynrand.org/donate
Then how long would it take to remove or replace the SQL query with something faster? You don't have to be stupid unless you want to.
Sayeth the noob who didn't think about how long testing the change would take...
In 1973 or 1974 I was the systems programming manager at the National Academy of Sciences after our IBM mainframe had been upgraded to the first version of the OS supporting virtual storage. And many programs, mostly Fortran programs, were running much slower than they used to. The problem was two-dimensional arrays and how they were initialized and searched. If you're looping through the wrong subscript in a big array, you cause a page fault every time you increment it. Flash storage makes that a much smaller problem than it is with disk drives, but I'm sure most programmers today have no idea that this problem exists or how to handle it.
It would take as long as it is cheaper to run the inefficient query than recoding it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Videogame programmers care *very much* about all these sorts of performance issues. Not coincidentally, many videogame programmers use custom containers, and nearly ALL of them use custom allocators for exactly this reason.
That being said, not everyone programs real-time pseudo-simulations like we do. But you should very much care about ensuring the most basic building blocks of code everyone uses are highly optimized at the very least. The more often code is called, the more attention should be paid to ensuring its as optimal as it should be.
I'd be curious to hear MS's response to these issues. It could be that there were some deliberate reasons for the choices made, or possibly some unintended consequences to the solutions offered, but it's hard to say without a fairly deep knowledge of the STL internals MS uses (based on Dinkumware, I think?)
Irony: Agile development has too much intertia to be abandoned now.
Agreed. Nit-picking code efficiency is great for code reviews, but not a productive technique to improve performance. ROI says its better to find and fix the one stupid bug that profiling identifies as 70% of your latency instead of dozens with no perceivable impact.
The rule of thumb for programming anything is, first make it work, then make it work better / faster.
If the first pass works well enough and fast enough, it doesn't matter if the code was written an efficient manner. If somebody used bubble sort for an array of 5 items, who cares? If the array becomes larger, now you have a performance bug.
It's literally wasteful to spend time on performance enhancement before you know which performance problems actually occur in real life. Another name for premature performance enhancement is "gold plating."
Computers are today faster than they need to be for nearly all applications the average office runs into.
For nearly everything except rebooting. I still don't understand the problem. It's better than it was, but we're still back in the old days of waiting for the TV to warm up.
“He’s not deformed, he’s just drunk!”
"an experienced programmer, with a reasonably accurate mental model of the problem"
Well, that's one of the many things that separate programmers from coders as I designate them. I.e., the ones who know and do vs. the ones who have a limited clue at most but do it nonetheless and behave like they'd be the gods of algorithm and program development. In my book, and in my area of work, a code that gives the result but it's 2-7-whatever times slower than it could be with some actual knowledge besides tapping codewords in the correct order, that code is nothing besides a limited applicability proof of concept at best, targeted for supporting viability and then destined for disposal. That's why I never worked with coders and I don't care for the gazillions out there who think the ability to use python makes them devs or software engineers, oh my. Also, for the poster, performance issues regarding stl, well, good story, no news.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
When you can fix those to get them to run in seconds you get really popular. (Perhaps not so popular with the original "developer", but that's part of life, eh?)
Yes, ... umm... no.
Not anymore. Yes, it still matters with high end, AAA titles. For everyone else, there's Unity. And Unreal Engine. And ... something I forgot now. Game programming used to be one of the few areas where you really needed top programmers that can come up with creative ways to cut a few extra cycles. Just think of the infamous 1/sqrt(x) hack.
I wouldn't expect many who currently claim to be game programmers to understand it. Let alone come up with something close to it.
Even in games, efficient code isn't the be-all, end-all anymore. Being able to "cheat" with the graphics and making low poly shit look great with creative texturing is where the money is today, it seems.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Real programmers use only the 1 and 0 keys
Keys? Real programmers use jumper wires directly on the memory bus pins of the CPU.
So, I profile that code, I find, hm, odd, this loop is taking a lot of time.
It's accessing some array, wierd, array accesses are normally blazingly fast.
Oh look, it's a two dimensional array, that's something you don't see every day!
Let's play a bit with the code, hey, it's fast now that I'm looping through it differently... hm, I wonder how that thing is laid out in memory... oh, could it be that it is causing cache line misses / page faults / disk cache misses (yes, those abstractions are present at every level)?
No. Butterflies.
You'd think someone who's been here as long as you would have heard of profilers.
Your first tool should be performance monitor. In my experience most slow tasks will show 0% CPU utilization for a large part of the wait. Because some coder has never heard of firing queries asynch, then doing local work while waiting.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
You can optimize for dev time or CPU time. Which is cheaper?
The inexcusable is optimizing for neither. e.g. server side javascript.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
I would probably say that performance is probably dead last on any software company's mind, unless something is so slow that it gathers user complaints of affects the use of a device (for example, an embedded controller in a vend a goat machine is having a software loop that fires off every five seconds, winding up taking 6-7 seconds to complete, or a daily backup taking 26-27 hours to complete.)
Performance can always be improved, but oftentimes, it is a case of diminishing returns. In reality, it will not even be looked at, because most software, the developers are thanking their respective deities that it built, passed unit tests, and was able to be built in an executable. Stuff like security and performance... waaay low on the list.
Sayeth the noob who didn't think about how long testing the change would take...
Agreed that replacing tested/working code with new "more efficient" code does incur a re-validation cost.
On the other hand, that's also an argument for writing the more-efficient implementation the first time, rather than waiting until some later release. Since you know it's all going to have to go through the testing cycle at least once, why waste your QA group's time testing slow/throwaway code, when you could have them spend that time testing the code you actually want your program to contain? (Assuming all other things are equal, which they often aren't, of course)
The shortest distance from A to B is a straight line.
I don't care if it's 90,000 hectares. That lake was not my doing.
If performance sucks, buy a faster computer. Speed covers a multitude of sins.
You're not a programmer, right? See things aren't so simple. A poor design decision will still be slow on a faster computer, and the speedup you get will not correlate to the extra money spent. Spending double on a new computer will not cause your program to finish in half the time if it's waiting on a poorly constructed network request.
I'm a minority race. Save your vitriol for white people.
Sure, I've heard of and have used profilers.
But performance monitors often only give point to point execution times, not "network I/O took 3242ms") or "Auth timed out 3x" sorts of details.
I like logs, syslogs, and other methods of determining execution problems, too, because sometimes: it's not actually the code, it's the host, the UI, the wm, the phase of the moon. Best to know.
---- Teach Peace. It's Cheaper Than War.
Two types of performance. If you don't get 'time to market' nobody will ever see the delay to complain about it.
Which isn't an excuse for just plain bad programming. Which is a constellation of potential mistakes.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
The shortest distance from A to B is a straight line.
Until a committee or management are involved. Then your straight line looks like the paths a dozen Pachinko balls take through the machine.
Throwaway code is often rolled into prod because that's all you have time for. I wish all other things could be equal.
"Anything you say can and will be used against you in a targeted advertisement" - Adam Harvey
You see a client sitting at 0% utilization, you click 'break all' in the debugger. You're looking at the offending block. It's real useful.
Then you start into the logs to see how it got there, if it's not obvious.
It's a particularly useful method when faced with unfamiliar code that is sucking big wet donkey balls.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
This is why I do all my coding in PHP and JavaScript. Performance concerns are jettisoned before the coding even starts.
You're not a programmer, right?
Not professionally. I work in IT Support.
Spending double on a new computer will not cause your program to finish in half the time if it's waiting on a poorly constructed network request.
Those days are long over. I switched out my quad-core processor for an eight-core processor. Performance overall didn't improved that much because most of my applications are single core.
> And for nearly all applications, they don't give a shit. Computers are today faster than they need to be for nearly all applications the average office runs into.
This is why I refuse to run the latest photoshop, MSoffice, etc. I don't need you to triple the resource bloat for features I don't care about, and to see people paid to mess with the GUI for the sake of messing with the GUI.
I like execution-time libs that give me full stats, so the database guy doesn't argue with the network guy who doesn't argue with the team that did middleware, etc etc.
DevOps, SCRUM, and other continuous development systems often eschew this, because they're running under fire control rather than improving incrementally. This said, I've seen a few SCRUM teams that were fast and surgical and rightly proud of their work.
---- Teach Peace. It's Cheaper Than War.
A good team can produce results with any POS methodology, even SCRUM. Typically despite the formal methods, not because of them.
Stats can prevent circular blame pointing? Not in my experience with the 'barely competent'.
When network operations go from acceptable to too slow, it's been my experience that people who don't know what they are doing have been fucking with them. e.g. Six outer joins to the same table. queries that were building temp tables but nobody noticed etc. Sure sometimes the data volume has grown or you've gained a bug from a update of the underlying OS or libraries. But 90% of the time is was someone who thought something was simple, but were wrong.
My method works when you are dropped into a project you've never touched before to firefight. Lack of symbol tables (middleware team) quickly reveals the real problem, if it's with project organization. Even in that example, you add to the middleware unit tests and are on track to a solution as quickly as possible given the constraints.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
For an explanation: http://thedailywtf.com/article...
I guess the premise needs to be someone above barely competent.
We'll agree that your method works for fire control. Projects should NOT BE fire control in most cases. Sadly, many are. While I like to be the Ross Adair of systems malfunctions, I'll also take a less stressful life. At the end of fire control, there are often a pile of ashes. It's possible to lead a long and successful life, and not deal with but a small pile of ashes. Others seem to need them for daily lunch.
---- Teach Peace. It's Cheaper Than War.
Isn't this why we have profilers like Valgrind to identify slow functions?
Anons need not reply. Questions end with a question mark.
an embedded controller in a vend a goat machine is having a software loop that fires off every five seconds.
Is 17,200 goats per day actually necessary?
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Fires happen. Even with the best of teams. HR gets involved and a seat is filled. Six months later you get back to a block of code and WTF happened? How did this pass QA and code review?
Nobody likes it, but I've yet to find a long term solution. I've quit, more than once, over teams being ruined by rapid growth and 'he was the best we interviewed'. Was clearly net negative worker who, at best, could have maintained some simple reports. Shouldn't have gotten out of probation, even if you accept the premise that he was the best available at hire time (which I knew to be bullshit).
At least in one case they were punishing me for turning down a management position. If they had told me directly: 'If you don't take the job, we'll give it to Li.' I'd have mentally quit then and there, actually quit a few weeks later, once I found another job.
More SW jobs suck than don't. Even when they don't suck initially, they often change with growth or acquisition.
'Process immaturity model' is usually a better metric than 'process maturity model'. Even/especially in organizations that claim all sorts of nonsense about their processes.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Often performance issues are caused by a sub-optimal algorithm. It works, but a different approach would be better. A recent dev post about the game Factorio highlighted a more straightforward issue:
A one-parameter fix to a long-standing bug. Gotta love it.
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
Incorrect. Message queues dont share IO state either. You would know that if you tried to pass back to proxy or api server. They cannot synchronize state and the best people have figured out is to pass a 'state token'. This doesn't work however because IO's central version of truth is where I/O meets and so when proxy sends state token, api server may have different state because they didn't synchronize since last update to api server. Or perhaps MQ has different stae from api server and thus rejects because it didn't synchronize. Yeah so... nothing like MQ my friend. Try to understand I/O before commenting like a monkey behind a typewriter
This is my sig. There are many like it but this one is mine.
Klingon coding...
Copy con: program.exe
Then enter structure, opcodes and data with Alt-keypad.
Comments...where would those go?
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
I came here looking for the usual discrediting due to edge cases, obscure platforms or bad statistics. Instead there's a bunch of arguing over the tired old "it does (not) matter", so I had to look myself. Well blow me down, this is as clear as day - on recent Visual Studio and XCode with clang, unsorted_map::insert is 7 times slower than calling unsorted_map::find first and skipping the call to insert if it already exists. That's just what insert is supposed to do for you. The platforms, the compilers, the library and the functions are all extremely common. Debugging suggests the delay is due to an unnecessary alloc/dealloc. Good find!
Only because Fortran stores multidimensional arrays in column-major order, while every other language in the known universe uses row-major order.
Julia is another that I know of, not surprisingly because it continues the scientific computing traditions of Fortran in many ways. From TFM:
Multidimensional arrays in Julia are stored in column-major order ...
This convention for ordering arrays is common in many languages like Fortran, Matlab, and R (to name a few). The alternative to column-major ordering is row-major ordering, which is the convention adopted by C and Python (numpy) among other languages.
Escher was the first MC and Giger invented the HR department.
SQL Server's query planner gets better and better with every release, but it still screws up on a regular basis. To have efficient queries on SQL Server the programmer (in the absence of a full-time DBA) needs to know far more about the internals of the server than they really should. Some of the common issues for slowly running queries I see include:
SQL Server's a mine field of bad performance for the unaware. I doubt it's much different in Oracle and MySQL/MariaDB.
Right. Rust is never accidentally quadratic.
Who really cares if I can get a loop to run in 800ns instead of 1500ns, when the real bottleneck is a complex SQL query 11 lines up that joins 11 tables together and takes 3 full seconds to run?
Sooo...rewrite the slow loop in the database server? ;)
Ezekiel 23:20
Although, a "scripting" language without a serious performance bug may actually process a larger data set faster than a program written even in a system language like C, if said latter program contained a serious performance bug. But not making obvious mistakes is hardly "optimization". At the risk of making a little bit too contrived example, the decision not to use a bubble sort is not something I'd call optimization. It's just common sense.
Ezekiel 23:20
I believe that Alan Kay may have invented it, actually.
Ezekiel 23:20
Hilarious. But on modern machines and language runtimes, GC is for a substantial problem domain definitely better than many of the other options, especially the ones that require refcounting. Those that do not often involve manual decisions. Your problems are going to lie elsewhere.
Where Java actually has a problem is the "everything is a headered object" approach. Now that is a lot of unnecessary waste.
Ezekiel 23:20
I'm pretty sure that you have effectively still the same problem with CPU caches and that this is the reason why Fortran compilers regularly perform loop transformations today.
Ezekiel 23:20
It's not the use of programming languages, it's use of completely inappropriate, daily-WTF-worthy, algorithms and mechanisms. We do development that involves interfacing with various libraries and components provided by third parties, and holy fsck, it's a wonder some of this stuff works at all, let alone inefficiently. You look at some of the duct-taped-together crap that we have to deal with and in some cases literally can't see why what they're doing works, it's pure coincidence that the way they're using the APIs happen to produce an actual result rather than an error code or a hang.
So why were there no tests against the full dataset? Because that made the CI runs take too long.
As a software tester, I've done a few back of the envelope calculations, filed a bug report if the maximum value is too long, and forced the programmers to prove me wrong. Most of the time they go back and refactor the code. Sometimes they wait until the bug bites them in the ass just before code release.
But the problem most likely exists in all the newer languages, yet I have never heard of programmers being aware of it or optimizing for it.
I might be biased because I work in the computer graphics industry but memory coherency is the first thing we think about when doing something new. This is also a major point if you look at any of the presentations about performance at CppCon (C++ conference). They are easily found on YouTube. See also data oriented programming. This is NOT a forget ten problem at all.
Every numerical methods text involving a scientific math library has warnings about the array-transposition bug. Huge math optimization work has gone into dealing with it. The problem is much worse in modern super-computers than in the older computers. In the old computers, memory accesses were fairly predictable. New supercomputers are clusters of computers. Each node can only hold a small section of a large array, and communication time is often a function of both the distance between nodes in hops and total communication load (saturated interconnects).
Huge work goes into figuring out how to do array operations in a fast manner. The work often becomes highly application dependent. Find special short-cuts that apply to particular matrices that allow one to make use of special theorems.
Huge work goes into figuring out how to do array operations in a fast manner. The work often becomes highly application dependent. Find special short-cuts that apply to particular matrices that allow one to make use of special theorems.
This is actually one of the things I'd like to see in the kind of experimental compiler I outlined above.
Ezekiel 23:20
Using a modern game engine doesn't absolve responsibility for writing good, efficient code, and even moreso like me if you ARE the one working on the engine. Plenty of studios still write and use their own custom engines.
Optimization is still critically important. I'd argue its one of several pillars of our technical requirements. That being said, I never claimed it was the "end all be all". But yes, we actually do worry about the cost of operations like allocations, locks, or operations which enter kernel space, because of the cost of the context switch. Those things add up if they occur when iterating over the typically massive, complex data structures we tend to work with.
But at a broader scope, "optimization" these days more typically means being smart about how you code in a real-time and occasionally memory-constrained environment rather than micro-optimization, which isn't practical for the hundreds of thousands of lines of code in modern, large-scale projects. For instance, being smart about caching both objects and data to avoid unnecessary allocations (or writing your own allocators to help with that), optimizing for multi-threaded execution, writing CPU-cache friendly code and data structures where necessary (more important than micro-code optimizations in many cases), and so on.
BTW, this is a common misconception, but far more happens outside of the graphics sub-system that needs programmer attention. People tend to forget that most animation happens on the CPU, not to mention physics, audio, AI, scripting, resource management, and general gameplay logic.
Irony: Agile development has too much intertia to be abandoned now.
Who really cares if I can get a loop to run in 800ns instead of 1500ns, when the real bottleneck is a complex SQL query 11 lines up that joins 11 tables together and takes 3 full seconds to run?
To misquote a not-quite-famous Congress critter: A nanosecond here, a nanosecond there, eventually we are talking about real time (minutes).
You do not exist in a vacuum. You think your application is the only one but I have hundreds of "applications", written by people just like you, who thought that the real bottleneck is elsewhere so why worry about this particular bottleneck?
This attitude is why I can notice the delay in a particular window opening up or why I see "hiccups" in the smoothness of my screensaver.
I am sure that numerous studies were performed to say that the user will never notice and that these "minor" delays do not affect anything... but these studies are wrong. I notice.
(Granted, you seem to be addressing a server application where the application truly is the only application that matters, but my point about unnecessary wasting of CPU cycles still stands. Should you go to the extremes that ancient assembly language hackers used to go through to make something not possible into possible? No. Each programmer should be trying to be as efficient with CPU time as possible.)
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
Inefficiencies are a sign of incorrect modelling.
Inefficiencies are a sign of slack coding standards.
Inefficiencies are a sign of not knowing exactly what the code is actually doing.
Ultimately, these all lead to errors, and when compounded across multiple running programs, will have effects that are neither predicted nor likely to be desirable.
Your model is good:
Is it slowing down the users?
Are we getting hammered by the electricity bill?
Is the machine getting tired?
However, it lets dirty code slide into use as long as you can say, "It is slowing down the users, but they will never notice and besides, our electricity bill is not rising too much."
Like the real Donald (Knuth) said: "premature optimization is the root of all evil (or at least most of it) in programming".
The keyword here being "premature". Do not take it to mean optimization should never be done or even that optimization is unimportant. It is merely stating that getting optimization done before you have everything fully modeled out is a waste of time (for various reasons).
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
Has anyone seen my essay on the (rem) pseudo-instruction construction for comments? I omitted publishing because a previous text was gone from the forum, then the computer was stolen from me.
or security admins who misuse McAfee
Table-ized A.I.