These are chat archives for uwhpsc-2016/uwhpsc-2016

17th
May 2016
natwall27
@natwall27
May 17 2016 18:40
@cswiercz , when you have availability during office hours, do you mind looking at my code for simps_parallel_chunked? I am working on trying to debug it.
nishalad95
@nishalad95
May 17 2016 18:41
@cswiercz When you have a chance, would you mind looking at my integrate.c on github, - I have sent you a private message with a couple questions that I have
Chris Swierczewski
@cswiercz
May 17 2016 18:58

Office Hours - Start

@jasheetz Thank you for sending a message to SMC. Interesting stuff about cgroups.
@natwall27 @nishalad95 Are your repos updated?
@nishalad95 I'll start with @natwall27
@nishalad95 Answering here since it's a "public" question: Static vs. dynamic work sharing is just about when the work is split up. In the former the splitting is done at compile time. In the latter, the work sharing is determined as the work is being done. My guess is that dynamic will be slower.
nishalad95
@nishalad95
May 17 2016 19:06
ok thank you! I think that makes sense now. Also - what should we expect for the num_threads = N problem size, should we be expecting the run time to be faster or slower?
Chris Swierczewski
@cswiercz
May 17 2016 19:08
Wow! That's a lot of threads, especially if N ~ 2**9 or greater. Because thread information is stack allocated I doubt the stack is large enough to accommodate that many threads.
So to directly answer your question, at a certain point the amount of overhead to manage threads becomes much greater than the amount of work they are asked to do. In this homework, you should only be dealing with num_threads = 1, 2, 4, and 8.
nishalad95
@nishalad95
May 17 2016 19:15
ok! I've think I've misinterpreted the meaning of the argument in schedule ( static/dynamic [,chunk])
Chris Swierczewski
@cswiercz
May 17 2016 19:26
The schedule() directive is just about work-sharing amongst the declared number of threads. That is, "how many iterations at a time should each thread process before moving on to the next "chunk" of iterations?"
Big hint: This has big contiguity of memory access performance issues.
Chris Swierczewski
@cswiercz
May 17 2016 20:05

Office Hours - End

alyfarahat
@alyfarahat
May 17 2016 21:01
@cswiercz , just to verify my understanding, chunk_size holds the number of consecutive iterations sequentially processed by a thread, is this correct?