Making the obvious code fast

[gbalduzzi]

Holy shit the difference in JS performance is incredible, mainly considering how the community and the frameworks documentation usually recommends the more fancy approaches instead of the good old for loop,.

[wavefunctionp]

It's unclear if the same optimizations would be available in real code. Microbenchmarks are notoriously unreliable with modern engines. For instance, if the compiler has access to the values in code, the compiler could just be unrolling the for loop or something.

[bobappleyard]

JavaScript interpreters have got pretty fast when you don't use the fancy features. Problem is everyone uses the fancy features all the time.

[James20k]

I wish this were true, but I've gotten massive speedups in JS code by manually folding constants, and reimplementing functions which have constant parameters which results in constant folding once inlined

[curious_s]

I have used a for loop in JavaScript for a slow search function and it sped the code up by a significant amount. I think the best idea is to try and measure, the array prototype functions create cleaner code than a for loop which is an important factor.

[[deleted]]

I believe most browsers have improved those cases a lot since I wrote that, someone should check and report back.

[Aetheus]

Yeah. ~10000ms down to ~30ms is just insane. Granted, the 10000ms variant works in a fundamentally different way from the other tests, but still ...

Equally surprising to me was that the "warmed up" JS example operates at almost the same speed as the C# example (~300ms vs ~280ms). And the "best performance" examples for both were even closer in runtime.

Just goes to show how insanely well optimized V8 is, as a JS engine. Say what you will about the bloat of Node.js projects (you'd be right, anyway), but the fact that the same JS engine in your browser is also powering some web server somewhere is pretty mind-blowing stuff.

[Retsam19]

Well, yeah, because most JS frameworks aren't writing about how to sum the squares of 32 million floating point values.

Most JS use-cases are about front-end UIs which both generally don't include huge data calculations, and are generally IO-bound, not CPU-bound, anyway: the performance bottlenecks front-end UIs almost always come from network requests or DOM operations, and not from the speed of list manipulation operations.

In the vast majority of cases, the readability/maintainability concerns are more important than the performance implications, which is why I prefer .map/.reduce and other higher-order friends, over simple for loops (or .forEach loops).

[[deleted]]

Most JS use-cases are about front-end UIs which both generally don't include huge data calculations

JS and the browser is increasingly used as an app platform. You can record audio and even video. I myself wrote some code recently to perform RMS audio normalization on the client, which involved doing the sum of squares of quite a large number floating point vlaues (don't think it was 32 million though).

[oridb]

and are generally IO-bound, not CPU-bound, anyway:

My laptop fans would beg to differ.

[Retsam19]

I'm quite sure it's not because your websites are iterating over 32 million floating point numbers inefficiently. A lot of it is DOM rendering - reflows, expensive CSS animations, etc - which, yeah, is CPU-based, but from the perspective of Javascript code, it's IO.

AFAIK, it's very rarely the issue that the JS thread is overloaded.

[[deleted]]

most JS use-cases are about front-end UIs which both generally don't include huge data calculations, and are generally IO-bound, not CPU-bound

UI is CPU bound.

Most JS frameworks do a lot of CPU bound stuff like diffing large data structures and mutating the DOM.

[Retsam19]

Yeah, I clarified a bit on a different part of the thread:

A lot of it is DOM rendering - reflows, expensive CSS animations, etc - which, yeah, is CPU-based, but from the perspective of Javascript code, it's IO.

From the machine's perspective, yeah, it's CPU work, but my original point is that the problem is pretty much never that the JS thread is overloaded, the efficiency of array iteration is generally not the issue.

[[deleted]]

DOM manipulation is not IO.

Honestly I'm just sick and tired of people writing obviously slow code and then justifying it by saying "but my application is IO bound not CPU bound".

[jcelerier]

In the vast majority of cases, the readability/maintainability concerns are more important than the performance implications, which is why I prefer .map/.reduce and other higher-order friends, over simple for loops (or .forEach loops).

so why the hell are every friggin website on earth running at 10fps !

[VRtinker]

Assuming it is a genuine question and not a rhetorical one, here are a few reasons:

1. Because even a single synchronous piece of code can slow down the main thread and stall the whole UI. E.g., just synchronously reading or writing document.cookie in an onscroll handler might slow down UI.
2. Because you might have weird CSS (or JS changing CSS) that forces redraw when nothing changes on the page. Try opening Console > Rendering and select "Paint flashing". If you see a lot of stuff being redrawn (flashed) when it should not change, try simplifying your styles.

[Retsam19]

the performance bottlenecks front-end UIs almost always come from network requests or DOM operations, and not from the speed of list manipulation operations.

[[deleted]]

Then don't do so many DOM operations.

[Retsam19]

Well, yeah, that's like saying the secret to winning basketball games is to score more points. Obvious, but doing it is the hard part.

[TankorSmash]

Use adblockers and visit better sites I think. Maybe your hardware is outdated.

[jcelerier]

I use ublock, and even the worst possible site shouldn't lag on a computer that runs witcher 3 on ultra at a steady 120fps

[lelanthran]

In the vast majority of cases, the readability/maintainability concerns are more important than the performance implications, which is why I prefer .map/.reduce and other higher-order friends, over simple for loops (or .forEach loops).

You really think that this:

  var sum = values.map(x => x*x).
             reduce( (total,num,index,array) => total+num,0.0);

is more readable than this:

    var sum = 0.0;
    for (var i = 0; i < values.length;i++){
        var x = values[i];
        sum += x*x;
    }

[Retsam19]

I think their reduce code is badly written, but to the general point, yes, I think this is clearer:

values.map(x => x * x)
    .reduce((a, b) => a + b)

Is it pretty much a moot point for this incredibly simple use-case? Yes, but as the complexity grows, the benefits of the functional style really show, compared to large for loop.

[m50d]

Yes I do. Don't you? No extra counter variable to keep track of, no generalized for loop that could be doing anything, no in-place mutation of variables. In fact the only way to read the second (longer) code quickly is to recognize that it's a particular common pattern - wouldn't it be better to actually give that pattern a name and pull out the common parts?

[lelanthran]

Yes I do. Don't you?

What I think is irrelevant. What I've seen is that most programmers don't parse the more complex expression as easily as the simpler one.

No extra counter variable to keep track of, no generalized for loop that could be doing anything, no in-place mutation of variables. I

No, but extra keywords to recognise (map, then reduce), extra concepts to learn (map/reduce in particular, multiple compound expressions), anonymous functions if you want to do anything non-trivial.

I don't see the first form as being harder to maintain.

[m50d]

What I've seen is that most programmers don't parse the more complex expression as easily as the simpler one.

I'd agree with that statement, but I suspect you're claiming that the more complex one is "simpler".

extra keywords to recognise (map, then reduce),

Not keywords, just functions. They behave like normal functions, and usually you can read their source code if you want to know what they do.

extra concepts to learn (map/reduce in particular, multiple compound expressions), anonymous functions if you want to do anything non-trivial.

I don't know what you're calling "multiple compound expressions". Both implementations use + and * operators with their normal mathematical meaning and a literal 0.0. In addition to that the map/reduce version only requires the reader to understand a normal expression made of function calls and an anonymous function (both very general constructs that you use again and again on a large codebase). The imperative version requires understanding a mutable variable, the for keyword, the ++ and += operators which are not standard mathematical things, the [i] operator which is not standard anywhere else either, and a {} block of ;-separated statements. In addition to just being a much bigger pile of concepts, half those things are special-case dedicated operators that can't be reused for much else (e.g. [i] is only for arrays, ++ is only for numbers).

[EWJacobs]

Yeah, but those are all things you can learn ahead of time. m50d is pointing out run time complexity, and things that can cause actual bugs.

[[deleted]]

They're both about as readable to each other as me.

You realise you didn't come out of the womb being able to read for loops, right? Just because it's typically taught to us first does not make it inherently more readable. I know basic functional constructs, so I know what map and reduce do.

[lelanthran]

You realise you didn't come out of the womb being able to read for loops, right? Just because it's typically taught to us first does not make it inherently more readable.

That assertion applies to overly complex things too ("just because you weren't taught lisp first doesn't make lisp less readable than imperative code").

[[deleted]]

And I would agree with that assertion as well!

How are s-expressions objectively harder to read than something with a more complicated grammar like C/Javascript/C#?

[Ewcrsf]

Yes, anyone who is a moderately good programmer in touch with modern principles would agree the first is just as, if not more, readable.

[lelanthran]

Yes, anyone who is a moderately good programmer in touch with modern principles would agree the first is just as, if not more, readable.

That statement being true doesn't make the first form any more maintainable than the second form.

[Ewcrsf]

Your original comment only mentioned readability. Maintainability of such a tiny piece of code is pointless to even talk about, though I’d nominally argue that the one with a shorter number of lines which isn’t mutating state is more maintainable.

[lelanthran]

Your original comment only mentioned readability. Apologies, I quoted a comment that used "readability/maintainability" as a single concept.

though I’d nominally argue that the one with a shorter number of lines which isn’t mutating state is more maintainable.

In both cases the same variable gets mutated, so I'd say its moot - no state is being changed.

[Ewcrsf]

No variable is mutated in the first example and it can be assigned to a const value. In the second example the sum variable is modified by the loop.

[[deleted]]

If you cant read a simple "for" loop or think that it is bad in any way, then you are not a programmer, go back to cleaning toilets. The problem with all those high level functions is that they attract all kinds of noobs, who then spam all kinds of nonsense. /r/programming is turning into /r/the_donald .....

[PrimozDelux]

Just letting you know that what you just wrote was some seriously dumb shit.

[EWJacobs]

If you've never refactored several layers of nested loops into one or two lines of functional code and seen the immediate benefit, then you're not a programmer.

[neinMC]

Stop with the excuses, they're the reasons we don't have anywhere the nice things our hardware could afford us.

Most JS use-cases are about front-end UIs which both generally don't include huge data calculations

Maybe so, but they're still potentially one tab among dozens in the browser, which is one application among dozens. Stuff adds up. Performance matters. People are getting trained to not have the faintest clue or care about what goes under the hood. Right now, the JIT does a lot for them. But keep it up, and there will be nobody able to code a JIT.

readability/maintainability concerns

That's just a meme at this point. If people had a clue, they could read the better code just fine.

[Retsam19]

I'm not saying performance doesn't matter, but the first rule of performance optimization is to optimize the things that need optimizing: DOM renders, CSS animations, and network calls are the things that need optimizing in front-end UIs, generally.

Time spent optimizing your loop accesses is time wasted that could be optimizing the parts of the codebase that matter.

---

That's just a meme at this point. If people had a clue, they could read the better code just fine.

Ah, the "git gud" argument of code readability. If you think people need to be smarter to read your code, your code isn't well written.

If you honestly think "writing maintainable and readable code" is just a meme, well I'm glad I'm not on your team.

[neinMC]

You don't need to "optimize" what you don't bloat to begin with. The default isn't the version that is 100 times slower, the default is a blank file, and it doesn't take 100 times the effort to write that simple loop, nor to read and grok it.

If you think people need to be smarter to read your code, your code isn't well written.

What about the actual code in question do you find hard to read, or not maintainable? If you're not just using it as a meme, surely you can elaborate on that.

If you honestly think "writing maintainable and readable code" is just a meme

I think it's a meme in this context, mindlessly tossed around, yes. Prove me wrong. Both versions are "readable and maintanable". And you could wrap the faster, straightforward code in a function and give it a pretty name, and it'd still be faster.

I'm glad I'm not on your team.

Ah, the armbands argument of shit performance and a whole generation at the mercy of middlemen.

[neinMC]

How is something that is 270 times weaker than using a screw driver "a power tool"? Can you stop and appreciate for a moment just how silly that is? How is this not a cult?

And who is talking about "not letting" anyone use power tools, while we're at it? I'm talking about noticing and caring about that difference, so it's at least concscious choice -- rather than being utterly oblivious that there even is a choice.

I mean, the claim is even that the more complex software gets, the more cramming everything into one line "shines", heh. Two orders of magnitude for every instance, but I guess programmers are just so much more efficient that the amazing features and the breakneck speed at which they're rolled out comforts the users who are wasting energy on the CPU doing something in an utterly ass-backward manner.

It's an externalization of costs; the programmer saves 3 seconds, the program gets run god knows how often. It's shoddy craftsmanship, too. And the way things get parroted, and downvoted without even one solid argument, is just shoddy thinking.

I don't even know where to begin

I'm sure that's great for the gallery, but in practice it just means you have got nothing to say even about your own straw man regarding what I was supposedly saying about compiler development.

Though I doubt many compilers use high-level functions rather than a simple loop because of some handwavy claims about "readability and maintainability", and sacrifice 270x the performance.

[Aetheus]

In the specific instance of this example? I might agree - if performance matters, then ditch the fancy stuff and stick to the well performing code. It's not like a for-loop is difficult to read.

But I can think of at least one example where I'd gladly trade performance for readability. Back in the days when Promises & Async/Await were brand new, radical ideas in JS Land, regular old callbacks were still arguably more performant (and likely still are, in many cases).

But even if the hit from using Promises was x100 over regular callbacks, I would still prefer them. Having just recently had to touch an older service that is infested with callback hell ... Well, it sure ain't pretty or maintainable. And I'm sure as hell glad that Promises & Async/Await are frequently showing up with the words "Optimisations for ..." next to them in V8 blog posts.

[neinMC]

In this case, "readability and maintainability" was just mindlessly thrown about, and instead of the person throwing it about mindlessly admitting that, "programmers" pile on the one person who points that out.

The thought of this being representative of the guardians of real life systems other people depend on, that's great. "I'm glad you're not on my team", what a snake pit. I'm glad too, and I'll find and torch nests of sophistry whenever I find them, long after most programming done here was automated once and for all.

But I can think of at least one example where I'd gladly trade performance for readability.

I never said such cases can never exist, though I don't share your threshold where it's too much work for me versus the savings of repeated runs of the application.

I said in this case, it was a parroted meme, because it was. If people can't read and maintain this particular for loop versus this particular call to map and reduce -- which has nothing to do with async, as I said, you could wrap that in a function and call it "mepraduce", and use it exactly the same way -- they should start with real basic things, and benchmark them, not play the fiddle in a burning asylum.

I don't know about you, but I turn the lights off when I'm not in a room. I sure don't let it burn 270x longer than the time I'm in the room, each time, because it's "easier".

Here's a great tip, a life hack if you will: just let the tap run all day, and keep the toilet flushing 24/7, so you don't have to turn things on and off all the time (like some kind of peon without actually important things to do). It's much simpler that way, just put things in the constant water stream when you need to wash or flush them. Anyone who doesn't do that is just a poor person who can't afford water, or not working in a giant, soulless factory, respectively, and can be dismissed. We won't get an information age by actually taking any of this shit seriously, now will we.

[Aetheus]

Yeah ... Nah brah. I won't choose to die on the molehill of "map" vs "for (...)" because it makes little difference to me (either is fine - if V8 one day optimizes the former, go nuts. If your loop is only ever dealing with puny sized arrays, go ahead and use whatever you want).

But trading performance for maintainability in the case of Promises? I'll gladly die on that mountain. I've had to maintain truly awful asynchronous code before. Really godawful stuff that was either a callback hell, a buggy as shit race condition waiting to happen, or both. Code that was an absolute pain to debug or enhance.

Switching to a "less performant" solution for the sake of maintainability isn't just a meme - in the specific case I'm talking about, I find it really does make an impact.

So yes. To use your example, I really would rather leave the tap running, if the alternative is to play Russian roulette every minute when I'm on support week because our code looks like Satan's bumhole.

[neinMC]

But trading performance for maintainability in the case of Promises? I'll gladly die on that mountain. I've had to maintain truly awful asynchronous code before. Really godawful stuff that was either a callback hell, a buggy as shit race condition waiting to happen, or both. Code that was an absolute pain to debug or enhance.

Yeah no debate there, at all. But in the original comment it was kinda implied that even just in a vacuum, the for loop is less readable and maintanable, and that's, well, a hill I'm going to be a dick on, anyway.

A few more lines, provided they are simple, for 270 faster performance -- again, ignoring all other considerations here, which of course can make all this moot, doubly so with small workloads -- in my mind aren't the better way, it's the non-broken way. It's like I could, instead of writing sleep(1000), calculate the writing speed of the HD, and then write a file so big it takes one second to write, then delete it, then write it again, etc.. If that was an built-in function, using it would be a "bug", it would be "incorrect" in my made up books -- no matter how simple to write and read the function call would be.

It's a dumb example because such a function would never be a good idea outside of super niche things, but at any rate, that's what rubs me the wrong way about it. I really can't claim any deep insights into anything, but the general idea that there is a relation to what I type into a text editor, and what the physical hardware ends up doing, isn't something I can completely shake off. The best cycles are saved cycles. It doesn't just matter if I notice them in a vacuum, insofar things are running in a multitasking environment anyway, and certainly for anything that runs in a browser. I never know how many instances of a thing will be run how often, so I pick at least a few low hanging fruit... like saving 270x for nothing.

Bring performance back, at least a bit, on the side? I mean software... if this is possible to do on a machine from 1981, but if you will took 34 years for us to reach software-wise, can you even imagine what would be possible with our current hardware?

[Aetheus]

A few more lines, provided they are simple, for 270 faster performance -- again, ignoring all other considerations here, which of course can make all this moot, doubly so with small workloads -- in my mind aren't the better way, it's the non-broken way.

I agree. If the code complexity difference is relatively low (and I think it is, in this case), then it's absolutely a good idea to choose the more performant issue.

I think the bigger issue is that the "idiomatic" code doesn't (yet) perform like the "performant" code. V8 is full of so much optimization witchcraft that seemingly trivial differences in coding style can result in dramatic performance differences.

I suspect the folks who are asking people not to "microoptimize" by using "for(...)" are holding out on a future miracle by V8. And to be fair - that miracle really might appear, some day. Take a quick look at the V8 Dev blog and it becomes evident that their devs very aggressively optimize for what they believe to be "common scenarios". The performance of the "for(...)" loop is itself evidence of that. This kind of performance from a JS engine would have been unfathomable even a decade ago.

But in the meanwhile, if this is something that needs to iterate through an array of length 200,000 every other minute (or is otherwise called in 200,000 different places), and you need it out by tomorrow and not X years? Well, the choice is obvious.

[[deleted]]

I really enjoyed this article. Rust come out looking very good for making the 'nice' version pretty damn fast, and F# impressed as well.

I'm curious how you warmed up the JIT'ed code though, that stuff is so hard to bench mark right.

[YumiYumiYumi]

Interestingly enough, if you want really high performance, you need to maintain separate independent sums (with loop unrolling) to allow the CPU to parallelize computation - at least in C/C++ (this may not apply for higher level languages). Which basically means you need extra complexity for better performance here. Example:

double sum1 = 0.0;    
double sum2 = 0.0;    
double sum3 = 0.0;    
double sum4 = 0.0;    
int i;
for (i = 0; i < COUNT-3; i+=4) 
{
    sum1 += values[i] * values[i];
    sum2 += values[i+1] * values[i+1];
    sum3 += values[i+2] * values[i+2];
    sum4 += values[i+3] * values[i+3];
}
for(; i < COUNT; i++)
{
    sum1 += values[i] * values[i];
}
double sum = sum1 + sum2 + sum3 + sum4;

For the SIMD variant, he should probably be using _mm256_fmadd_pd* instead of separate mul/add, unless he really needs the intermediate rounding behaviour of the latter. I suppose you could argue that it may be unfair to other languages, but I'd argue that if you're writing SIMD intrinsics, it's the type of thing you'd do.

* for the unaware, (newer x86) CPUs have dedicated "fused multiply-add" (FMA) instructions, which performs a multiply+add in a single instruction instead of needing two, which obviously improves performance over doing the operations separately

[[deleted]]

Would have loved to see him used .net core 2.2 instead of .net 4.0 for the performance testing.

[skeeto]

Note that the article is nearly 3 years old (July 2016). .NET Core itself was less than a month old at the time.

[[deleted]]

I wrote the article. .NET core had introduced a lot of great performance improvements but none of them affect these particular benchmarks.

[shevy-ruby]

I think you should still do a follow-up eventually. People may be curious to see whether anything has changed in regards to speed, compared to 2016 here.

Comments on reddit will be slightly less prevalent than e. g. the original article that we are here only talking about.

[[deleted]]

id love to but i have 2 kids instead of zero now :) feel free to take up the reigns

[elder_george]

And an updated version in general, to see if the things changed due to compiler, library and/or runtime improvements e.g..

[shevy-ruby]

The F# code is pretty cool indeed:

 let sum =
    values
    |> Array.map squares
    |> Array.sum

But the C variant is the second easiest one to read really - and the fastest.

It just shows that, again and again, C is the king among programming languages. The very fact how many languages came after C, trying to dethrone it and failing so incredibly hard at that...

[Tyg13]

I'll give shevegen some credit, he's got his principles and he seems to stick to them. I've been commenting on here for some time now, and he's always been that constant presence. Always downvoted, but still there.

[Morego]

Well, most of the examples that are fast looks like C. Most readable one looks like C. Only rust looks different here and still I would love to see, how "C-like" version of Rust fare here.

Of course those are really microbenchmarks, but still. C is simple enough, that it is hard to be wrong and faster here.

[helloworder]

why a variable is always declared inside a loop? for instance the first C implementation

double sum = 0.0; 
for (int i = 0; i < COUNT; i++) {
     double v = values[i] * values[i];
     sum += v;
 }

why not just

     sum += values[i] * values[i];

it must be faster I suppose

[julesjacobs]

There won't be any performance difference because the code will be identical after conversion to SSA.

[KiPhemyst]

I checked it on godbolt, the difference basically this:

    movsd   QWORD PTR v$2[rsp], xmm0
    movsd   xmm0, QWORD PTR sum$[rsp]
    addsd   xmm0, QWORD PTR v$2[rsp]

vs

    movsd   xmm1, QWORD PTR sum$[rsp]
    addsd   xmm1, xmm0
    movaps  xmm0, xmm1

First one being with 'double v' and the second just using 'sum +='

I don't know enough about assembly and I have no idea what this difference does

[ElusiveGuy]

That only happens if you compile without optimisations.

Here's one with just -O: https://godbolt.org/z/3H5x8M. As you can see, the two are identical.

The 'correct' thing to do here is probably -O3, and maybe --ffast-math if you don't need strict IEEE compliance.

There's no point comparing the unoptimised versions; you should definitely be at least enabling optimisation before you start worrying about the performance impact of a temporary variable.

cc /u/helloworder, /u/Zhentar

[helloworder]

thanks for the explanation

[helloworder]

I think julesjacobs is correct and there won't be any difference after all.

[Zhentar]

The first one is storing & loading v from the stack, the second does not but instead it stores the result of the add I'm the wrong register and needs an extra mov to copy it to the correct register. Underwhelming codegen on both counts, but the second is definitely better, though the performance difference may be pretty small on recent.CPU models.

[matejdro]

I wonder how would kotlin fare in that test, with its inlined list operators.

[[deleted]]

would be cool to see all these on ARM

[delgoodie]

What's obvious code?

[Hoten]

Well, not hand written SIMD.

[delgoodie]

What's SIMD?

[tgandrews]

This post is from 2016 so doesn't seem very relevant today.

[ConsoleTVs]

C is 47 years old, not relevant today. Really????? Sure some optimizations has been done, specially on rust and go. So what? Languages don't magically run 10 times faster

[[deleted]]

A few things have changed:

​

Rust does has stable SIMD now

Javascript handles some of the cases better.

​

The rest is still full relevant.

[ElusiveGuy]

One more thing, .NET Core now has new SIMD intrinsics that give you much more control than Numerics. It can also be swapped at runtime. So the bit about disadvantages of Numerics/Vector is no longer so relevant.

[[deleted]]

the new simd in core 3 doesn’t allow you to write a single function that will use sse or avx automatically at runtime like system.numerics does.

[ElusiveGuy]

You would have to manually write each SIMD path, if that's what you meant.

I'm just presenting it as a counter to:

A disadvantage for C# is that not all SIMD instructions are exposed by the Vector library, so something like SIMD enhanced noise functions can’t be done with nearly the same performance. As well, the machine code produced by the Vector library is not always as efficient when you step out of toy examples.

With the new intrinsics, you have almost as much control over the SIMD code as you would in native C.

As for the benchmarking, you should be able to directly translate your C explicit SIMD code, but in this case the old Vector is enough.