|
Nov
29 |
|
answered | UDP multicast client does not see UDP multicast traffic generated by tcpreplay |
|
Feb
16 |
|
comment |
'new' and 'delete' is not as scalable as intel thread building block scalable_malloc/free by the way, I tested Hoard, and I am really not doing advertisement for tbb. but from the results, tbb is about twice ~ four times faster than Hoard. |
|
Feb
16 |
|
awarded | Commentator |
|
Feb
16 |
|
comment |
'new' and 'delete' is not as scalable as intel thread building block scalable_malloc/free I read the documentation of ThreadAlloc library, the mystery part to me is that mutex is held for the reason that makes multi-thread running slow. but I really doubt that, because if mutex is the reason, then running code like "for (size_t i = 0; i < 10000000;++i) char * p = new char[100]; delete p;" in multiple threads on multi-processor platform would be definitely solwer, but it's actually faster. another puzzle to me, in any case, it should be as fast, how come it's even faster. |
|
Feb
16 |
|
comment |
'new' and 'delete' is not as scalable as intel thread building block scalable_malloc/free Thanks a lot for your comments, could you please tell me where I can find an artical that explainning this in detail? yet there is still a mystery part which is that "if I call 'new' and 'delete' in a tight loop before starting running the algorithm, the overhead of 'new' and 'delete' is gone." is there an explannation for this? |
|
Feb
15 |
|
asked | 'new' and 'delete' is not as scalable as intel thread building block scalable_malloc/free |
|
Feb
15 |
|
comment |
More threads, slower the speed, even when there are enough CPU cores it needs to be "for (size_t i = 0; i < 100000; ++i)", if the number is too small like 10000, it doesn't work, myterier and myterier, huh |
|
Feb
15 |
|
comment |
More threads, slower the speed, even when there are enough CPU cores I was wrong, 'new' is the problem, yet it still remain mystery to me. because if I add following code in each thread and make them run first, then the processing time of each thread remains the same while I increase thread number. for (size_t i = 0; i < 10000; ++i) { char * str = new char [100]; delete str; } |
|
Feb
15 |
|
answered | Performance difference for multi-thread and multi-process |
|
Feb
15 |
|
comment |
More threads, slower the speed, even when there are enough CPU cores I don't think new is the problem. because when each thread needs to run longer, the time remains the same when thread number increases from 1 to 4. I did a litter search on google, someone else had the similar question, during his tests, multi-processes was much faster than multi-threads when running totally indepent algorithms on each thread/processe. there was an article explainnign this, but unfortunately, I can't find that article |
|
Feb
13 |
|
comment |
More threads, slower the speed, even when there are enough CPU cores I also did a simple test, run "new char[100]" for 1 million times in 1 thread and in 4 threads, respectively. the time is the same which should mean that 'new' is not the problem. maybe? I am not sure. too many mysteries. |
|
Feb
13 |
|
comment |
More threads, slower the speed, even when there are enough CPU cores I used valgrind (callgrind) to run my application, the result of callgrind is presented with percentage numbers, so if one thread calls ten methods, the result would be method1 consumes 10% of the total time, method2 consumes 20% of the time. The results barely change when I increased thread number from 1 to 4 which means time spent on every call increased by the same percentage, if there is contention, I should be able to see that certain methods consumes more time. if 'new' is the problem, I should be able to see 'new' operations consumes more time, but I didn't |
|
Feb
13 |
|
comment |
More threads, slower the speed, even when there are enough CPU cores I used valgrind (callgrind) to run my application, all I can see is that the timing increases for every call. |
|
Feb
13 |
|
comment |
More threads, slower the speed, even when there are enough CPU cores is there a way to detect contention? does 'new' operation count as "contention on system calls"? |
|
Feb
13 |
|
comment |
More threads, slower the speed, even when there are enough CPU cores I understand that. but in my case, each thread should be able to run on different core, and there is no race condition at all. all threads should just run as fast as when there is only thread running, shouldn't they? |
|
Feb
10 |
|
asked | More threads, slower the speed, even when there are enough CPU cores |
