We are evaluating some old code that was written as part of our math
library.
This code uses some optimizations that I'm not sure are necessary or
safe, but is a source of debate between my coworkers.
Method 1 includes a temporary storage varriable at class scope.
Method 2 includes a temporary storage varriable at method scope.
Method 3 includes a temporary static storage varriable at method scope.
Are any of the methods better than the others in terms of speed and
thread safety?
I don't believe method 1 or 3 are thread safe, but I think method 2 may
be too slow for a high-performance library. Is there a method 4 that
we should evaluate?
As an aside, I can't find in the standard where static is addressed in
terms of a member function. Is it true that a static varriable within
a member function exists for all instances?
/// ---- method 1
class vector {
....
private:
vector tempVector;
};
vector::somefunction() {
// writes to tempVector as temporary storage
}
/// ---- method 2
class vector {
....
};
vector::somefunction() {
vector tempVector;
// writes to tempVector as temporary storage
}
/// --- method 3
class vector {
....
};
vector::somefunction() {
static vector tempVector;
// writes to tempVector as temporary storage
} 7 2260
Chad Zalkin wrote: We are evaluating some old code that was written as part of our math library. This code uses some optimizations that I'm not sure are necessary or safe, but is a source of debate between my coworkers.
Method 1 includes a temporary storage varriable at class scope. Method 2 includes a temporary storage varriable at method scope. Method 3 includes a temporary static storage varriable at method scope.
Are any of the methods better than the others in terms of speed and thread safety?
This question is _better_ asked in a newsgroup that actually deals with
threading: comp.programming.threads. C++ does not have support, not does
it have any definitions of, threading. The program is assumed to be
single-threaded in C++ standard.
Now, when talking about threads it is essential to identify the data that
can be changed. You didn't say how many threads are accessing what part
of data at some point.
I don't believe method 1 or 3 are thread safe, but I think method 2 may be too slow for a high-performance library. Is there a method 4 that we should evaluate?
As an aside, I can't find in the standard where static is addressed in terms of a member function. Is it true that a static varriable within a member function exists for all instances?
A static object is a static object regardless of what scope it's in. It's
essentially a singleton.
/// ---- method 1
class vector { ... private: vector tempVector;
You simply _physically_ cannot have an object that contains an instance of
its own type.
};
vector::somefunction() {
Does this one have any return value type?
// writes to tempVector as temporary storage
It is generally _unknown_ here what storage duration 'tempVector' has,
since its storage duration is the same as that of '*this' object. (All
that assuming that the type of 'tempVector' is _not_ the same as the
object that contains it)
}
/// ---- method 2 class vector { ... };
vector::somefunction() { vector tempVector; // writes to tempVector as temporary storage
This is the most "thread-safe", largely because in many threading models
(if not all), automatic variables are "per-thread".
} /// --- method 3 class vector { ... };
vector::somefunction() { static vector tempVector; // writes to tempVector as temporary storage
This is the _least_ "thread-safe", since static objects are usually shared
between all threads.
}
To sum up: method 2 is generally thread-safe, method 3 is generally not,
and nothing can be said about method 1.
V
Chad Zalkin wrote: We are evaluating some old code that was written as part of our math library. This code uses some optimizations that I'm not sure are necessary or safe, but is a source of debate between my coworkers.
Method 1 includes a temporary storage varriable at class scope. Method 2 includes a temporary storage varriable at method scope. Method 3 includes a temporary static storage varriable at method scope.
Are any of the methods better than the others in terms of speed and thread safety? I don't believe method 1 or 3 are thread safe, but I think method 2 may be too slow for a high-performance library. Is there a method 4 that we should evaluate?
What makes you think that accessing a variable at local scope is slower
than that at class scope?
The narrower the scope the easier it is for the compiler to optimise.
If there is no requirement for the temporary variable to have scope
outside of a function, don't do it. Declare objects as late as
possible, and with the narrowest scope possible.
Be sure to use initialisation rather than assignment wherever possible.
If the object has a constructor, use an initialisation list. When
instantiating the object, use initialisation rather than default
construction and assignment.
You haven't really described how this temporary object is actually
initialised, how it is used, and why you think it is an optimisation
technique.
I mean, what is the alternative that you suppose is slower?
Ben Pope
--
I'm not just a number. To many, I'm known as a string...
Victor Bazarov wrote: /// ---- method 1
class vector { ... private: vector tempVector;
You simply _physically_ cannot have an object that contains an instance of its own type.
};
Yes, but one could use a pointer for tempVector.
If the class vector contains other dynamically allocated members,
this might be a performance improvement over method 2
(assuming that each thread maintains its own instance of vector).
Stephan
Chad Zalkin wrote: We are evaluating some old code that was written as part of our math library. This code uses some optimizations that I'm not sure are necessary or safe, but is a source of debate between my coworkers.
Method 1 includes a temporary storage varriable at class scope. Method 2 includes a temporary storage varriable at method scope. Method 3 includes a temporary static storage varriable at method scope.
Are any of the methods better than the others in terms of speed and thread safety? I don't believe method 1 or 3 are thread safe, but I think method 2 may be too slow for a high-performance library. Is there a method 4 that we should evaluate?
In theory you might require that the thread provides the temp. vector
(in analogy to localtime, localtime_r)
vector::somefunction(vector& tempVector);
However this will only be useful if the tempory vector is used outside
the class vector and not an implementation detail of
vector::somefunction().
Regards, Stephan br****@osb-systems.com
Open source rating and billing engine for communication networks.
Victor Bazarov wrote: Chad Zalkin wrote: We are evaluating some old code that was written as part of our math library. This code uses some optimizations that I'm not sure are necessary or safe, but is a source of debate between my coworkers.
Method 1 includes a temporary storage varriable at class scope. Method 2 includes a temporary storage varriable at method scope. Method 3 includes a temporary static storage varriable at method scope.
Are any of the methods better than the others in terms of speed and thread safety?
This question is _better_ asked in a newsgroup that actually deals with threading: comp.programming.threads. C++ does not have support, not does it have any definitions of, threading. The program is assumed to be single-threaded in C++ standard.
Now, when talking about threads it is essential to identify the data that can be changed. You didn't say how many threads are accessing what part of data at some point.
I don't believe method 1 or 3 are thread safe, but I think method 2 may be too slow for a high-performance library. Is there a method 4 that we should evaluate?
As an aside, I can't find in the standard where static is addressed in terms of a member function. Is it true that a static varriable within a member function exists for all instances?
A static object is a static object regardless of what scope it's in. It's essentially a singleton.
/// ---- method 1
class vector { ... private: vector tempVector;
You simply _physically_ cannot have an object that contains an instance of its own type.
};
vector::somefunction() {
Does this one have any return value type?
// writes to tempVector as temporary storage
It is generally _unknown_ here what storage duration 'tempVector' has, since its storage duration is the same as that of '*this' object. (All that assuming that the type of 'tempVector' is _not_ the same as the object that contains it)
}
/// ---- method 2 class vector { ... };
vector::somefunction() { vector tempVector; // writes to tempVector as temporary storage
This is the most "thread-safe", largely because in many threading models (if not all), automatic variables are "per-thread".
} /// --- method 3 class vector { ... };
vector::somefunction() { static vector tempVector; // writes to tempVector as temporary storage
This is the _least_ "thread-safe", since static objects are usually shared between all threads.
}
To sum up: method 2 is generally thread-safe, method 3 is generally not, and nothing can be said about method 1.
V
In defence of my own sanity, method 1 was not meant to include itself.
Let's all imagine that the tempVector is now of type foo in all
methods.
The part that I forgot to mention in my haste was that more than one
method will use the temporary storage:
class vector {
void add(); // needs temporary storage
void sub(); // needs temporary storage
void dot(); // needs temporary storage
};
class tempStorage
{
public:
// some data members
};
Now, let's ignore the threadding issue since it is OT.
If add(), sub(), and dot() all need to store some temporary data during
their runtime,
is it more efficient to store this data at class level (constructing
and destructing once per object) or at function level (constructing and
destructing once per function call; potentially many more times).
Since add(), sub(), and dot() do not call each other, storing the data
at class level becomes possible. (But then the thread issue comes into
play...)
What are the pro's and con's of scoping at each level? What can I
trust the compiler to be allowed to optimize? What can I do to help
the compiler optimize?
Thanks for any insight!
Chad Zalkin wrote: In defence of my own sanity, method 1 was not meant to include itself. Let's all imagine that the tempVector is now of type foo in all methods.
The part that I forgot to mention in my haste was that more than one method will use the temporary storage:
class vector { void add(); // needs temporary storage void sub(); // needs temporary storage void dot(); // needs temporary storage };
class tempStorage { public: // some data members };
Now, let's ignore the threadding issue since it is OT.
If add(), sub(), and dot() all need to store some temporary data during their runtime, is it more efficient to store this data at class level (constructing and destructing once per object) or at function level (constructing and destructing once per function call; potentially many more times).
Well, you forgot something:
Class level: Contruction once. Assignment for each function call.
Function level: Construct & initialisation once per call.
Since add(), sub(), and dot() do not call each other, storing the data at class level becomes possible. (But then the thread issue comes into play...)
Indeed. And although you don't need to construct the object, you do
need to assign to it, which may or may not be faster than constructing
and initialising.
Don't forget that it's in automatic storage, not heap... so the memory
is already "allocated".
What are the pro's and con's of scoping at each level? What can I trust the compiler to be allowed to optimize? What can I do to help the compiler optimize?
As I said, declare variables as late as possible and in as narrow scope
as possible, prefer initialisation to assignment.
Not only do you help the compiler optimise, by narrowing what it has to
look at, but you also fix thread issues.
The only way you'll know if this works in your situation is by profiling.
Ben Pope
--
I'm not just a number. To many, I'm known as a string...
Chad Zalkin wrote: [..] Let's all imagine that the tempVector is now of type foo in all methods.
The part that I forgot to mention in my haste was that more than one method will use the temporary storage:
class vector { void add(); // needs temporary storage void sub(); // needs temporary storage void dot(); // needs temporary storage };
class tempStorage { public: // some data members };
Now, let's ignore the threadding issue since it is OT.
If add(), sub(), and dot() all need to store some temporary data during their runtime, is it more efficient to store this data at class level (constructing and destructing once per object) or at function level (constructing and destructing once per function call; potentially many more times).
<triallawyer>
Objection: leading!
</triallawyer>
It all depends on how much it takes to construct that object and how big
it actually is. You are forgetting an important element of performance:
make your objects smaller. If you store anything at the object level, you
make it bigger. It may not have effect on the performance in this
particular area of your program, but somewhere else... Which leads me to
another point: do not attempt to optimize before you have a chance to
measure the performance and conclude _whether_ and _where_ the actual
optimization is needed.
Since add(), sub(), and dot() do not call each other, storing the data at class level becomes possible. (But then the thread issue comes into play...)
What are the pro's and con's of scoping at each level? What can I trust the compiler to be allowed to optimize? What can I do to help the compiler optimize?
Two rules are at play here, I believe. (1) The tighter the scope the
easier it is to optimize and maintain, and (2) Premature optimization is
the root of all evil.
V This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jonathan Burd |
last post by:
Greetings everyone,
Here is a random string generator I wrote for an application
and I'm wondering about the thread-safety of this function.
I was told using static and global variables cause...
|
by: Alexander Fleck |
last post by:
Hi,
I' ve to make a software module thread safe.
I know how to realize that and what' re the main topics of thread safety.
But I don' t know how thread safety can be tested. I read about a test...
|
by: The Crow |
last post by:
for example i have static readonly SqlParameter and i want to clone them at
runtime. as clone operation will not write to SqlParameter object, just
reading, should i lock that object during read...
|
by: bazzer |
last post by:
hey,
im trying to access a microsoft access database from an ASP.NET web
application in visual basic 2003.NET. i get the following error when i
try running it:
Server Error in...
|
by: Warren Sirota |
last post by:
Hi,
I've got a method that I want to execute in a multithreaded environment
(it's a specialized spider. I want to run a whole bunch of copies at low
priority as a service). It works well running...
|
by: fniles |
last post by:
I am using VB.NET 2003 and a socket control to receive and sending data to
clients.
As I receive data in 1 thread, I put it into an arraylist, and then I remove
the data from arraylist and send it...
|
by: paul.hester |
last post by:
Hi all,
All of the classes in my DAL are static, with constants defining the
stored procedures and parameters. I've been having some problems with
my site which makes me wonder if there's a...
|
by: arun.darra |
last post by:
Are the following thread safe:
1. Assuming Object is any simple object
Object* fn()
{
Object *p = new Object();
return p;
}
2. is return by value thread safe?
|
by: Graham Wideman |
last post by:
Folks:
Can anyone tell me what controls php's "thread safety" feature?
I have an installation where phpinfo() is showing Thread safety: enabled,
whereas I need it disabled in order to work...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
|
by: Aliciasmith |
last post by:
In an age dominated by smartphones, having a mobile app for your business is no longer an option; it's a necessity. Whether you're a startup or an established enterprise, finding the right mobile app...
|
by: giovanniandrean |
last post by:
The energy model is structured as follows and uses excel sheets to give input data:
1-Utility.py contains all the functions needed to calculate the variables and other minor things (mentions...
|
by: NeoPa |
last post by:
Hello everyone.
I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report).
I know it can be done by selecting :...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM)
Please note that the UK and Europe revert to winter time on...
|
by: nia12 |
last post by:
Hi there,
I am very new to Access so apologies if any of this is obvious/not clear.
I am creating a data collection tool for health care employees to complete. It consists of a number of...
|
by: isladogs |
last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, Mike...
| |