Jump to content

  • Log In with Google      Sign In   
  • Create Account

iMalc

Member Since 05 Mar 2004
Offline Last Active Dec 13 2015 01:49 AM

Posts I've Made

In Topic: C++11 template question

03 December 2015 - 12:50 AM

Of course, those of us who write firmware will not go through all this trouble just to get the size, we just straight use the ARRAY_SIZE definition to save precious clock cycles ;)

Sounds like you don't realise that constexpr methods are evaluated at compile time and as such have no run-time penalty whatsoever. And if that's not enough, the int template argument is also determined at compile time.
Identical assembly is generated to the code with macros, but without the headache macros bring.

 

When people writing firmware do this sort of thing it's actually typically because they're stuck using an ancient compiler written at a time when templates were either unheard of, or were still in their infancy.


In Topic: Confusion with smart pointers

26 October 2015 - 12:28 AM

 


I've almost never called std::move on a unique_ptr myself; that should be mostly called by container classes e.g. vector in a normal program, and I you wouldn't often be writing a container.
In a normal program if you have to transfer ownership between unique_ptrs, you'll often find yourself doing so by detaching from one unique_ptr, and attaching to another, most likely across a function call boundary.

 

That's exactly when std::move should be used.

 

Well sure, if the function signature takes a unique_ptr directly as one of the arguments. Kinda forgot that obvious case as I've almost never been in that situation. I deal mostly with code where the interface in the middle is a C interface, e.g COM, and that sort of thing.


In Topic: Confusion with smart pointers

25 October 2015 - 02:27 PM

As you are no doubt aware, in C++ it is preferable to avoid new and delete in your program. Modern C++ provides some nicer ways to achieve this with unique_ptr:

 

Instead of this:

std::unique_ptr<Random> SP(new Random());

Use this:

 

auto SP = std::make_unique<Random>();

I've almost never called std::move on a unique_ptr myself; that should be mostly called by container classes e.g. vector in a normal program, and I you wouldn't often be writing a container.

In a normal program if you have to transfer ownership between unique_ptrs, you'll often find yourself doing so by detaching from one unique_ptr, and attaching to another, most likely across a function call boundary.


In Topic: vector push_back creates error when multi threading

03 October 2015 - 02:33 PM

And ideally, you pass the mutex as a parameter.

 

Statics/globals are the enemy of multi-threading, and having that singular mutex pretty much ensures that you are not, in fact parallelising much of anything.

Or the better option would be for this doit function to be a member function instead, and the mutex is a member variable.

That way the caller can't pass in the wrong mutex.


In Topic: Is it possible to optimize this? (keeping a small array in registers)

28 September 2015 - 01:55 AM

Possible ideas that haven't been mentioned yet:

Consider switching Arrays of structures to structures of arrays.

Consider adding prefetch inline assembly language instructions or intrinsics.

You may be able to calculate partial sums of the values in the dist array, keeping track elsewhere which portions of the array have been touched, or heaven forbid you update the sum upon every change to an item in the dist array if it changes rarely.

Okay I'm starting to get in the territory of wild asz guesses now. Context is key. The more context we have, the more optimisations we can apply. There are plenty of things I could suggest, but they would only work under specific conditions which you have not specified. The less info you provide, the more you lose out. You're making this challenge like doing keyhole surgery blindfolded. But here's the kicker... you can't know what we will need to know in order to pick the best ideas. Really, your only option is to be as open as possible and provide as much contextual information as you can.

 

Believe me I've done plenty of micro-optimisation. If you've heard of John Carmack's famous parallel divide where you get the floating point perspective divide essentially for free as it is done in parallel with integer instructions... well I've managed to achieve exactly that directly in carefully crafted C++ code, without having to resort to inline asm, but I digress.

 

I've also seen the problem of summing up all values in an array being parallelised in such as way as to actually gain performance by summing up into more than one variable at once, then summing those at the end. I think this was somewhat compiler specific. This should jog someone else's memory to fill in the details for you.


PARTNERS