Is there a convenient API call that tells me the maximum system concurrency? (I.e. maximum number of threads that can actually be executed at the same time - CPU count, core count, that stuff.)
Is there a convenient API call that tells me the maximum system concurrency? (I.e. maximum number of threads that can actually be executed at the same time - CPU count, core count, that stuff.)
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
It's probably a little bit awkward to get the info there, but /proc/cpuinfo contains the information you are after.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Something along the lines of
?Code:cat /proc/cpuinfo | grep vendor_id | wc -l
The grep is so that I get one line for every info block.
Yeah, possible, but as you say, awkward.
I need this to size a thread pool. (One thread per CPU - it's a CPU-centric thing, no I/O at all.) There has to be some function for it.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Yes, that looks about right.
Here's a link that shows different lines for doing either including or excluding hyperthreads - scroll down about halfway.
http://www.wcurtispreston.com/phpBB2...b46ead795fa879
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Well, thanks. I found GetCPUCount in the wxWidgets source, and they parse /proc/cpuinfo too.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
There's also "sysconf(_SC_NPROCESSORS_CONF)".
You may want to use "sched_getaffinity()" since that'll tell you what your process is allowed to run on.
gg
Thanks, these look interesting.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
There's an entry in /proc/sys/kernel/threads-max, may be that is what is needed ?
Regards,
Amit Sahrawat
I would have thought that's the "max number of threads ALLOWED", which is slightly different than "the number of threads that won't share a processor".
Edit: googline that /proc thingy, it shows that "regular" vaues in that is 2047 or bigger - so not really the "number of threads you may want to start without competing for processors", but rather a system-wide limit for how many CAN EXIST in the system [and it's changeable, if you wish to increase/decrease it to allow more or save some kernel memory space respectively].
--
Mats
Last edited by matsp; 11-22-2007 at 03:53 AM.
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Yeah, I doubt that 2^30 threads are really going to be useful
After examining the problem I'm currently working on more closely, I've realized that threads won't be an improvement after all. Thanks anyway.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
2^30, eh? That's quite some number - I guess this is a 64-bit system with plenty of memory, then?
A fairly common thing - it's often easy to say "It will be faster if we multithread it", only to find that when you ACTUALLY try to do that, it doesn't gain nearly as much as you thought, because it's too reliant on previous results produced by another thread or some such. Converting a single threaded app to multithreads is often not as easy as people think when they first look at multithreading [not saying that you didn't know this].
After examining the problem I'm currently working on more closely, I've realized that threads won't be an improvement after all. Thanks anyway.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
It is, but it's also a brain fart. 2^14 is the number I meant.
Actually, my thought was, "Hey, I can split this loop into blocks for different threads, and they won't need any synchronization at all."A fairly common thing - it's often easy to say "It will be faster if we multithread it"
Problem is that it's an inner loop, and the threads must wait for each other at the end of each iteration of the outer loop, and since the inner loop ought to be pretty tight, even this simple sync cost might still outweigh the gain.
New plan is to SIMD the hell out of it.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I don't see how OpenMP could avoid synchronization.
Integer SSE.Which instruction set are you going to use for this?
Just some background info. This is for a university class in low-level optimization. We have a pretty much given algorithm and we're supposed to make it as fast as possible. Target architecture is an Intel Core2 Duo.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
It doesn't. I just wondered if you considered using it (beacuse GCC seems to support it since 4.2) and why/why not before you came up with the SIMD idea.
Are there GCC extensions like for MSVC or do you port to assembler? I'm just asking out of general interest.