1
General Discussion about just::thread / Re: thread::hardware_concurrency static Member Function
« on: November 28, 2008, 07:02:05 PM »
issue resolved in build 0.5 v
Kenneth
Kenneth
News:
just::thread V1.8.0 for Windows, Linux and MacOSX Released
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
General Discussion about just::thread / Re: std::vector<std::thread> example from Concurrency in action
« on: November 28, 2008, 06:48:04 PM »
I would agree with you on this point. so what we would need is a move aware vector list. can you post links to the necesary information so if i were to persue development of a move aware container like vector or a custom array class. I would at least have the information to do so.
Kenneth
Kenneth
3
General Discussion about just::thread / Re: std::vector<std::thread> example from Concurrency in action
« on: November 25, 2008, 06:01:13 PM »
the above sample would still not work. what I have found that works if I use a raw array pointer of std::thread *ptr_threads = new std::thread[ num_threads - 1 ].
the only draw back is that I have to remember to clean it up with delete [] ptr_threads.
Kenneth
the only draw back is that I have to remember to clean it up with delete [] ptr_threads.
Kenneth
4
General Discussion about just::thread / Re: is it possible to tell a thread to wait without using a lock
« on: November 25, 2008, 05:57:39 PM »
well, I have done it. I have a bench mark on using concurrency with how just::thread can effect how the Mersienne Twister psuedorandom number generator can benefit from multi threading.
the the application is running in debug on vista ultimate x64 on a AMD Athlon 64 x2 Dual core 4200+ clocked at 2.21 ghz with 4 GB Ram.
the first concurrency test runs using 4 threads to simulate the ~performance of an x4 processor though I expect the results to be better. then I disable concurrency which shuts down the extra threads and only leaves the main thread of execution. then I re-enable the threaded execution which creates threads of execution based on hardware concurrency which is 2 on my computer.
here are the results:
generating 20,000,000 random numbers using hardware concurrency!
plus two threads simulate x4 core processor.
2.23366 seconds
generating 20,000,000 random numbers using main thread of execution!
2.45851 seconds
generating 20,000,000 random numbers using hardware concurrency!
2.42844 seconds
generating 20,000,000 random numbers using main thread of execution!
2.42402 seconds
generating 20,000,000 random numbers using hardware concurrency!
2.30001 seconds
generating 20,000,000 random numbers using main thread of execution!
2.43711 seconds
generating 20,000,000 random numbers using hardware concurrency!
2.35871 seconds
as you notice in the above sample the main thread of execution out performed the threaded only once out of all the iterations of generating 20 million random numbers. the majority of the time the threaded implementation of the random number generator out performed the syncronous version of the algorithm.
Kenneth
P.S. Anthony your advice on how to handle the thread control was key in getting this performance. though I am not using a while loop to control the wait. I use an if statement because the only time the threads will ever wake up is when a call is made to generate();
the the application is running in debug on vista ultimate x64 on a AMD Athlon 64 x2 Dual core 4200+ clocked at 2.21 ghz with 4 GB Ram.
the first concurrency test runs using 4 threads to simulate the ~performance of an x4 processor though I expect the results to be better. then I disable concurrency which shuts down the extra threads and only leaves the main thread of execution. then I re-enable the threaded execution which creates threads of execution based on hardware concurrency which is 2 on my computer.
here are the results:
generating 20,000,000 random numbers using hardware concurrency!
plus two threads simulate x4 core processor.
2.23366 seconds
generating 20,000,000 random numbers using main thread of execution!
2.45851 seconds
generating 20,000,000 random numbers using hardware concurrency!
2.42844 seconds
generating 20,000,000 random numbers using main thread of execution!
2.42402 seconds
generating 20,000,000 random numbers using hardware concurrency!
2.30001 seconds
generating 20,000,000 random numbers using main thread of execution!
2.43711 seconds
generating 20,000,000 random numbers using hardware concurrency!
2.35871 seconds
as you notice in the above sample the main thread of execution out performed the threaded only once out of all the iterations of generating 20 million random numbers. the majority of the time the threaded implementation of the random number generator out performed the syncronous version of the algorithm.
Kenneth
P.S. Anthony your advice on how to handle the thread control was key in getting this performance. though I am not using a while loop to control the wait. I use an if statement because the only time the threads will ever wake up is when a call is made to generate();
5
General Discussion about just::thread / is it possible to tell a thread to wait without using a lock
« on: November 25, 2008, 01:55:35 AM »
I am not sure if I understand the unique_lock very well. I have this scenerio with the MT algorithm.
I have determined that there is no gain to the algorithm if the generate method has to initialize the threads every time before twisting the array[ 624 ].
I am taking an approach were the contructor creates the threads at the time that the CRandomMT is instantiated. I assign a block of the array to each thread. then I want each thread to stay running for the lifetime of the CRandomMT random number generator. I also want the threads to wait until I queue them to twist there block of the array. then once they are done wait again until they are queued to do it again.
each block of the array is isolated from another block of the array.
does a unique_lock provide this functionality or does it behave differently?
Kenneth
I have determined that there is no gain to the algorithm if the generate method has to initialize the threads every time before twisting the array[ 624 ].
I am taking an approach were the contructor creates the threads at the time that the CRandomMT is instantiated. I assign a block of the array to each thread. then I want each thread to stay running for the lifetime of the CRandomMT random number generator. I also want the threads to wait until I queue them to twist there block of the array. then once they are done wait again until they are queued to do it again.
each block of the array is isolated from another block of the array.
does a unique_lock provide this functionality or does it behave differently?
Kenneth
6
General Discussion about just::thread / which header can I find std::ref in?
« on: November 24, 2008, 04:47:37 AM »
I am exploring the Mersenne twister algorithym implementing it is a parallel algorithym. I need to pass some pointers into the thread and I was wondering which header contains std::ref ?
Kenneth
Kenneth
7
General Discussion about just::thread / Re: std::vector<std::thread> example from Concurrency in action
« on: November 22, 2008, 02:21:27 AM »
Does the below code satisfy the condition with vector? it compiles but I have not executed the code at this time.
std::vector<std::thread> threads( num_threads - 1 );
std::vector<T> results( num_threads );
// iterate the thread array and send chunks of data into the threads
iterator block_start = first;
for( unsigned long i = 0; i < ( num_threads - 1 ); ++i )
{
iterator block_end = block_start;
std::advance(block_end, block_size);
threads = std::move( std::thread( //<-- this compiles
accumulate_block<iterator, T>(),
block_start,
block_end,
std::ref( results ) ) );
block_start = block_end;
}
std::vector<std::thread> threads( num_threads - 1 );
std::vector<T> results( num_threads );
// iterate the thread array and send chunks of data into the threads
iterator block_start = first;
for( unsigned long i = 0; i < ( num_threads - 1 ); ++i )
{
iterator block_end = block_start;
std::advance(block_end, block_size);
threads = std::move( std::thread( //<-- this compiles
accumulate_block<iterator, T>(),
block_start,
block_end,
std::ref( results ) ) );
block_start = block_end;
}
8
General Discussion about just::thread / Re: unresolved external symbol
« on: November 21, 2008, 09:28:57 PM »
Issue Resolved
9
General Discussion about just::thread / Re: thread::hardware_concurrency static Member Function
« on: November 21, 2008, 09:07:14 PM »
Anthony,
I just installed .4 beta and this situation has not been resolved yet. I would suggest the GetNativeSystemInfo function found in the kernel32.dll. when I use this in place of hardware_concurrency I am getting accurate count of processor cores.
Kenneth
I just installed .4 beta and this situation has not been resolved yet. I would suggest the GetNativeSystemInfo function found in the kernel32.dll. when I use this in place of hardware_concurrency I am getting accurate count of processor cores.
Kenneth
10
General Discussion about just::thread / std::vector<std::thread> example from Concurrency in action
« on: November 21, 2008, 06:46:43 PM »
Error 4
error C2558: class 'std::thread' : no copy constructor available or copy constructor is declared 'explicit'
f:\program files (x86)\microsoft visual studio 9.0\vc\include\vector line 1211
I recently aquired your book and was reading through. and I tried using a std::vector with the just::thread class.
Kenneth
error C2558: class 'std::thread' : no copy constructor available or copy constructor is declared 'explicit'
f:\program files (x86)\microsoft visual studio 9.0\vc\include\vector line 1211
I recently aquired your book and was reading through. and I tried using a std::vector with the just::thread class.
Kenneth
11
General Discussion about just::thread / unresolved external symbol
« on: November 20, 2008, 07:25:46 PM »
Error 1
error LNK2019: unresolved external symbol "public: void * __thiscall std::thread::native_handle(void)"
(?native_handle@thread@std@@QAEPAXXZ)
referenced in function "public: __thiscall CParallel::CParallel(void)" (??0CParallel@@QAE@XZ)
I was building a constructor that isolates the threads to a specific cpu core.
then recieved the above error while linking
error LNK2019: unresolved external symbol "public: void * __thiscall std::thread::native_handle(void)"
(?native_handle@thread@std@@QAEPAXXZ)
referenced in function "public: __thiscall CParallel::CParallel(void)" (??0CParallel@@QAE@XZ)
I was building a constructor that isolates the threads to a specific cpu core.
then recieved the above error while linking
12
General Discussion about just::thread / Re: break error on t.join()
« on: November 19, 2008, 10:54:36 PM »
between the two cases I had tried unique_lock and lock_guard I may have pasted the stack trace for unique lock. both were expressing the same symptoms.
Vista Ultimate x64
MSVC 2008 standard SP 1
Vista Ultimate x64
MSVC 2008 standard SP 1
13
General Discussion about just::thread / Re: thread::hardware_concurrency static Member Function
« on: November 19, 2008, 10:44:34 PM »
amd x2 processor with 4 GB of memory running on vista ultimate x64
the below code I have found is far more accurate on my system. it uses the GetNativeSystemInfo found in the kernel32.dll and returns 2 for the dwNumberOfProcessors everytime. to be honest based on the code below I have never ran GetSystemInfo on my computer because GetNativeSystemInfo has been successfull every time I have ran this code.
typedef void (WINAPI *PGNSI)(LPSYSTEM_INFO);
ZeroMemory( &SysInfo, sizeof( SYSTEM_INFO ) );
PGNSI pGNSI;
pGNSI = (PGNSI)GetProcAddress(GetModuleHandle(TEXT("kernel32.dll")), "GetNativeSystemInfo");
if( pGNSI != NULL )
{
pGNSI( &SysInfo );
} else GetSystemInfo( &SysInfo );
the below code I have found is far more accurate on my system. it uses the GetNativeSystemInfo found in the kernel32.dll and returns 2 for the dwNumberOfProcessors everytime. to be honest based on the code below I have never ran GetSystemInfo on my computer because GetNativeSystemInfo has been successfull every time I have ran this code.
typedef void (WINAPI *PGNSI)(LPSYSTEM_INFO);
ZeroMemory( &SysInfo, sizeof( SYSTEM_INFO ) );
PGNSI pGNSI;
pGNSI = (PGNSI)GetProcAddress(GetModuleHandle(TEXT("kernel32.dll")), "GetNativeSystemInfo");
if( pGNSI != NULL )
{
pGNSI( &SysInfo );
} else GetSystemInfo( &SysInfo );
14
General Discussion about just::thread / thread::hardware_concurrency static Member Function
« on: November 19, 2008, 09:39:58 PM »
based on the documentation you mentioned that this should return the number of processors.
so I was expecting it to return '2'. I was surprised to recieve the number '2036182'.
which leads to the question of how that number was picked and why?
Kenneth
so I was expecting it to return '2'. I was surprised to recieve the number '2036182'.
which leads to the question of how that number was picked and why?
Kenneth
15
General Discussion about just::thread / break error on t.join()
« on: November 19, 2008, 07:35:22 PM »
// this project was created using VS 2008 C++ win32 console application, with pre-compiled header checked.
this was happening with _JUST_THREAD_DEADLOCK_CHECK being defined in the _preprocessor in properties
I was trying to run the test to verify it was installed and working.
the output of this has been the following:
"hello from the main thread"
nothing else. either the thread is being deadlocked or something is happening that I am not aware of.
// Parallel_1.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <thread>
#include <mutex>
std::mutex io_mutex;
void greeting(const char* message)
{
std::lock_guard<std::mutex> lk(io_mutex);
std::cout << message << std::endl;
}
int _tmain(int argc, _TCHAR* argv[])
{
std::thread t( greeting, "hello from another thread" );
greeting("hello from the main thread");
t.join(); //<-- this is where an error is occuring
return 0;
}
here is the call stack:
> msvcr90d.dll!_NMSG_WRITE(int rterrnum=10) Line 198 C
msvcr90d.dll!abort() Line 59 + 0x7 bytes C
msvcr90d.dll!terminate() Line 130 C++
Parallel.exe!__jss::stack_trace::build_trace_from() + 0x40 bytes
Parallel.exe!__jss::stack_trace::stack_trace() + 0x42 bytes
Parallel.exe!__jss::mutex::lock() + 0x2e bytes
Parallel.exe!std::unique_lock<std::mutex>::unique_lock<std::mutex>(std::mutex & m_={...}) Line 261 C++
Parallel.exe!CLock::CLock(std::mutex & _m={...}) Line 19 + 0xf bytes C++
Parallel.exe!greeting(const char * message=0x010daab0) Line 16 + 0xd bytes C++
Parallel.exe!__jss::__invoke1<void,void (__cdecl*)(char const *),char const *>::operator()(void (const char *)* & __func=0x010c177b, const char * & __a1=0x010daab0) Line 15 + 0xf bytes C++
Parallel.exe!__jss::__invoker1<void,void (__cdecl*)(char const *),char const *>::operator()() Line 79 C++
Parallel.exe!__jss::thread_data<__jss::__invoker1<void,void (__cdecl*)(char const *),char const *> >::run() Line 94 C++
Parallel.exe!std::`anonymous namespace'::thread_start_function() + 0x50 bytes
msvcr90d.dll!_callthreadstartex() Line 348 + 0xf bytes C
msvcr90d.dll!_threadstartex(void * ptd=0x000e53e0) Line 331 C
kernel32.dll!7566e3f3()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!7708cfed()
ntdll.dll!7708d1ff()
this was happening with _JUST_THREAD_DEADLOCK_CHECK being defined in the _preprocessor in properties
I was trying to run the test to verify it was installed and working.
the output of this has been the following:
"hello from the main thread"
nothing else. either the thread is being deadlocked or something is happening that I am not aware of.
// Parallel_1.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <thread>
#include <mutex>
std::mutex io_mutex;
void greeting(const char* message)
{
std::lock_guard<std::mutex> lk(io_mutex);
std::cout << message << std::endl;
}
int _tmain(int argc, _TCHAR* argv[])
{
std::thread t( greeting, "hello from another thread" );
greeting("hello from the main thread");
t.join(); //<-- this is where an error is occuring
return 0;
}
here is the call stack:
> msvcr90d.dll!_NMSG_WRITE(int rterrnum=10) Line 198 C
msvcr90d.dll!abort() Line 59 + 0x7 bytes C
msvcr90d.dll!terminate() Line 130 C++
Parallel.exe!__jss::stack_trace::build_trace_from() + 0x40 bytes
Parallel.exe!__jss::stack_trace::stack_trace() + 0x42 bytes
Parallel.exe!__jss::mutex::lock() + 0x2e bytes
Parallel.exe!std::unique_lock<std::mutex>::unique_lock<std::mutex>(std::mutex & m_={...}) Line 261 C++
Parallel.exe!CLock::CLock(std::mutex & _m={...}) Line 19 + 0xf bytes C++
Parallel.exe!greeting(const char * message=0x010daab0) Line 16 + 0xd bytes C++
Parallel.exe!__jss::__invoke1<void,void (__cdecl*)(char const *),char const *>::operator()(void (const char *)* & __func=0x010c177b, const char * & __a1=0x010daab0) Line 15 + 0xf bytes C++
Parallel.exe!__jss::__invoker1<void,void (__cdecl*)(char const *),char const *>::operator()() Line 79 C++
Parallel.exe!__jss::thread_data<__jss::__invoker1<void,void (__cdecl*)(char const *),char const *> >::run() Line 94 C++
Parallel.exe!std::`anonymous namespace'::thread_start_function() + 0x50 bytes
msvcr90d.dll!_callthreadstartex() Line 348 + 0xf bytes C
msvcr90d.dll!_threadstartex(void * ptd=0x000e53e0) Line 331 C
kernel32.dll!7566e3f3()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!7708cfed()
ntdll.dll!7708d1ff()
Pages: [1] 2