None of the software your described requires more work on the UI than the rest.
Image processing, simulation and spatialization in particular are domains requiring intensive computing, potentially involving some advanced algorithmics and math, which are much more challenging to engineer than writing glue code for user interaction.
That approach requires synchronous processing, all messages must be handled and they must be handled in order. It is extremely latency sensitive and would lead to lags.
Seriously, I don't think I could have made a worse one even if I tried. How about giving some useful information, or maybe something that would actually be newsworthy?
"New Chrome version with new features" OMG! Who knew this version thingies meant they added features!?
Playing online with consoles requires a dedicated subscription. I never quite understood why I should pay to be allowed to use my internet connection, and I suppose a lot of other people like me cannot play online with their console.
Printing with food has actually some pretty interesting applications: arbitrary shapes and sculptures that are edible + new dishes that are not possible with traditional techniques.
If out and in don't alias, it can batch them up and e.g. use some SSE things to copy faster.
I didn't realize this sort of thing prevented vectorization, that might indeed be true.
You still avoid the problem by writing it as this: (verbose, you might want to investigate another option)
T in0 = in[i]; T in1 = in[i+1]; T in2 = in[i+2]; T in3 = in[i+3]; out[i] = in0; out[i+1] = in1; out[i+2] = in2; out[i+3] = in3;
Why? often the compiler does a decent job, and I'd rather not do the compiler's job for it.
It's my opinion that for algorithms to vectorize well, you need to design them with vectorization in mind. It's easier to do that when you program it explicitly.
What do you recommend?
I contribute to a library that provides an abstraction layer for SIMD (SSE, AVX, Altivec, etc.) called Boost.SIMD and that is currently part of the larger NT2 library, with plans of getting it included into Boost. There are other C++ libraries which provide similar abstraction layers.
It's not just that: even without redundant loads, the optimizer needs to know about aliasing.
Just write your code in a way where the compiler does not need to make guesses about who aliases who. Just load it once explicitly, problem solved.
i.e. instead of
out1[i] = in[i]; out2[i] = in[i];
write
T value = in[i]; out1[i] = value; out2[i] = value;
This way, even if the compiler doesn't know that in and out1 don't alias, you only load once and not twice. This is the kind of optimization (it's called scalarization) that FORTRAN compilers will be able to perform reliably, and people have been using it to justify that FORTRAN is a superior language to C++.
For the autovectorizer, the only way of getting around that is to do explicit loads with intrinsics, but that gets into non-portable and irritating territory. It's also necessary for any order altering stuff like autoblocking and strip mining.
You should vectorize, unroll and pipeline explicitly if you really want it to happen. In C++ it's not hard with the proper tools, and it can be done generically and portably.
I gather the $$$ commercial compilers are quite a bit ahead of GCC
Of course when I'm speaking of FORTRAN compilers, I mean Intel and SGI. And they're not even really better than GCC or Clang in many cases.
FORTRAN wins (last time I checked) more of the funny language shootout benchmarks than any other single language.
It wins when you compare trivial syntactically equivalent code. The point in that when you use C++, you can do more than that.
However, I do sometimes notice missing optimizations in C++. Especially if you're working with two float containers, e.g. an image of floats and a vector for storing stuff. There's no easy way of telling C++ that the two don't alias which is deeply irritating. I would love to be able to annotate the language to tell it about aliasing more precisely. You can see sometimes it's missed opportunities by examining the emitted asm code.
There is a mechanism to annotate aliasing, it's the restrict keyword. It's not usable in all scenarios though. C++ compilers are pretty good at aliasing analysis now, so they should manage to deal with it without any annotation.
Nevertheless if you really care about this, just perform memory loads and stores explicitly in your code instead of relying on optimizations removing the redundant memory loads you shouldn't have performed in the first place.
Interestingly, there's one language out there which regularly benchmarks better than C++, and it's called FORTRAN
It doesn't in real life. In practice, most of the production code written in C++ performs better than code written to solve the same problems in FORTRAN.
I own a business dedicated to optimizing numerical and scientific code (including computer vision, your job), and we can beat FORTRAN any day. For naive code, it might be slightly better, but when you care about performance, you're going to want to be able to describe precisely how to maximize usage of the hardware. FORTRAN lacks both the low-level access needed for low-level optimization and the high-level access necessary to build higher-order parallelization and work distribution algorithms.
FORTRAN capabilities to make the most of modern hardware are relatively poor, in spite of OpenMP or OpenACC solutions.
Not all scientific computing is governed by LAPACK. Even for the cases where it is, there are better numerical methods and parallelization schemes out there, it's actually possible to beat MKL in special cases.
Pretty much all scientific computing benefits from vectorization. All that's needed to use it is that the code performs the same operation on multiple values of data (SIMD).
Slashdot Mirror
None of the software your described requires more work on the UI than the rest.
Image processing, simulation and spatialization in particular are domains requiring intensive computing, potentially involving some advanced algorithmics and math, which are much more challenging to engineer than writing glue code for user interaction.
You, sir, are part of the cancer destroying the UI of perfectly fine applications.
If your frontend requires more work than your backend, then your app doesn't do anything useful.
Maybe in the USA, but don't forget other countries have a sane healthcare system.
A decent laptop costs $3,000, not $300, especially if you intend to use it 8+ hours/day.
How is the error rate compared to General Practitioners? Surely you don't believe those guys never say any inaccuracy do you?
That approach requires synchronous processing, all messages must be handled and they must be handled in order. It is extremely latency sensitive and would lead to lags.
Seriously, I don't think I could have made a worse one even if I tried.
How about giving some useful information, or maybe something that would actually be newsworthy?
"New Chrome version with new features"
OMG! Who knew this version thingies meant they added features!?
It's not fundamentally different than programming DSPs but for floating point. The Cell isn't that exotic.
Killer robots allow to solve conflicts without sacrifice.
Even for simple games, skilled players do all of the winning. I consistently win at Mario Party for example.
Playing online with consoles requires a dedicated subscription. I never quite understood why I should pay to be allowed to use my internet connection, and I suppose a lot of other people like me cannot play online with their console.
Knapsack is NP-complete.
Is the thing that prevents from going to cloud
Printing with food has actually some pretty interesting applications: arbitrary shapes and sculptures that are edible + new dishes that are not possible with traditional techniques.
I didn't realize this sort of thing prevented vectorization, that might indeed be true.
You still avoid the problem by writing it as this: (verbose, you might want to investigate another option)
T in0 = in[i];
T in1 = in[i+1];
T in2 = in[i+2];
T in3 = in[i+3];
out[i] = in0;
out[i+1] = in1;
out[i+2] = in2;
out[i+3] = in3;
It's my opinion that for algorithms to vectorize well, you need to design them with vectorization in mind. It's easier to do that when you program it explicitly.
I contribute to a library that provides an abstraction layer for SIMD (SSE, AVX, Altivec, etc.) called Boost.SIMD and that is currently part of the larger NT2 library, with plans of getting it included into Boost.
There are other C++ libraries which provide similar abstraction layers.
Just write your code in a way where the compiler does not need to make guesses about who aliases who.
Just load it once explicitly, problem solved.
i.e. instead of
out1[i] = in[i];
out2[i] = in[i];
write
T value = in[i];
out1[i] = value;
out2[i] = value;
This way, even if the compiler doesn't know that in and out1 don't alias, you only load once and not twice.
This is the kind of optimization (it's called scalarization) that FORTRAN compilers will be able to perform reliably, and people have been using it to justify that FORTRAN is a superior language to C++.
You should vectorize, unroll and pipeline explicitly if you really want it to happen. In C++ it's not hard with the proper tools, and it can be done generically and portably.
Of course when I'm speaking of FORTRAN compilers, I mean Intel and SGI.
And they're not even really better than GCC or Clang in many cases.
It wins when you compare trivial syntactically equivalent code.
The point in that when you use C++, you can do more than that.
There is a mechanism to annotate aliasing, it's the restrict keyword. It's not usable in all scenarios though. C++ compilers are pretty good at aliasing analysis now, so they should manage to deal with it without any annotation.
Nevertheless if you really care about this, just perform memory loads and stores explicitly in your code instead of relying on optimizations removing the redundant memory loads you shouldn't have performed in the first place.
This is literally the first time I hear of 'backpeddling', so your statement appears unfounded.
Why weren't you running Openwrt?
It doesn't in real life.
In practice, most of the production code written in C++ performs better than code written to solve the same problems in FORTRAN.
I own a business dedicated to optimizing numerical and scientific code (including computer vision, your job), and we can beat FORTRAN any day. For naive code, it might be slightly better, but when you care about performance, you're going to want to be able to describe precisely how to maximize usage of the hardware. FORTRAN lacks both the low-level access needed for low-level optimization and the high-level access necessary to build higher-order parallelization and work distribution algorithms.
FORTRAN capabilities to make the most of modern hardware are relatively poor, in spite of OpenMP or OpenACC solutions.
Huh? Webkit *is* Chrome.
R&D software engineers are not subject to IT managers.
Not all scientific computing is governed by LAPACK. Even for the cases where it is, there are better numerical methods and parallelization schemes out there, it's actually possible to beat MKL in special cases.
Pretty much all scientific computing benefits from vectorization. All that's needed to use it is that the code performs the same operation on multiple values of data (SIMD).