- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Now that Intel has begun shipments of the first dual-core, four-thread desktop processors, I thought it would be interesting to see how application developers were planning on taking advantage of multicore processors. I know that I've been seeing increased interest from customers about how Intel compilers and tools can help with multicore.
To take advantage of multicore, you want to make your application multithreaded, so that independent tasks can run in parallel. The compilers support OpenMP, which is an industry-standard approach to specifying parallel behavior in Fortran (and C) applications, and they also support automatic parallelization, though that won't get all the benefits of user-directed parallelism.
Intel also offers tools such as the Intel Thread Checker to help make sure that your application doesn't have deadlocks or other improper thread behavior.
Have you taken advantage of multithreading already? Which options and tools did you use? How did it work for you? If you haven't yet added multithreading to your application, are you considering doing so? What questions do you have about it?
I started this thread in the Linux section, but the topic also applies to Windows users and I invite everyone to join in.
Message Edited by sblionel on 04-13-2005 03:22 PM
링크가 복사됨
3 응답
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Get really depressed that you are halving my memory bandwidth. :-(
I run mostly MPI applications and I am not sure what we are going to do. Do we encourage users to ignore the multi-core and treat them like processors? It will take some education to explain to them to request twice as many processors to get any added benefit from the new platform. Now not only are the codes running slower because of reduced memory bandwidth, but some codes don't scale as well and will run even less efficient because I have to use 2x cores to get to where I was with the previous, single-core, technology.
We can try using an OpenMP/MPI hybrid model, but that takes work to maintain and most users aren't going to want to do that (even if they know how). We can also use auto-parallelization, but will that be as efficient on a per node basis then doing it by hand? If we this then we have to hide the fact that there are multiple cores per socket, and really confuse the users.
Change is always hard, but we will get through it. I don't mind the programming change so much, except for issues when supporting users who aren't computer/computational scientists. They just want their results. My biggest concern is memory bandwidth. Maybe fully-buffered DIMMS will help in the future, but when is Intel putting that on the roadmap (outside of NDA of course)?
When will the memory bandwidth of future processors be at the same
(or better) flop per (MB/s) as we have today?
Craig
I run mostly MPI applications and I am not sure what we are going to do. Do we encourage users to ignore the multi-core and treat them like processors? It will take some education to explain to them to request twice as many processors to get any added benefit from the new platform. Now not only are the codes running slower because of reduced memory bandwidth, but some codes don't scale as well and will run even less efficient because I have to use 2x cores to get to where I was with the previous, single-core, technology.
We can try using an OpenMP/MPI hybrid model, but that takes work to maintain and most users aren't going to want to do that (even if they know how). We can also use auto-parallelization, but will that be as efficient on a per node basis then doing it by hand? If we this then we have to hide the fact that there are multiple cores per socket, and really confuse the users.
Change is always hard, but we will get through it. I don't mind the programming change so much, except for issues when supporting users who aren't computer/computational scientists. They just want their results. My biggest concern is memory bandwidth. Maybe fully-buffered DIMMS will help in the future, but when is Intel putting that on the roadmap (outside of NDA of course)?
When will the memory bandwidth of future processors be at the same
(or better) flop per (MB/s) as we have today?
Craig
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Steve,
I have been still using CVF 6.6 and I have a couple of questions.
1. Can I take advantage of a dual processor in CVF6.6
2. Can quickwin programs take advantage of dual processor or does one have to write a Win32 program with different threads
3. Can you show me a sample example where a calculation loop is expedited by using dual processor. What I mean is how is the calculation algorithm written to use two processors simultaneously within one program. Does this mean a loop is broken into two parts and submitted to each processor and then the answers are combined. What if each next step is dependent on the previous step and I cant break it into two.
As you can understand I am a real novice in this but we are at a point where we need to speed up our calculations to do some real time feedback analysis.
Is there an option in the project settings to make it use a dual processor. Is that setting only in IVF (I can then make a case to purchase that)
Any help would be appreciated.
Thanks
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
CVF does not have support for multiprocessing. You can write your own threading code if you want. QuickWin applications already use threads to a limited extent - one for the user interface and one for the execution thread.
Intel Fortran supports OpenMP, which is the industry-standard way of developing multithread applications. In the simplest scenario, you use the !$OMP DO directive as follows:
This says to execute the body of the do loop in parallel. OpenMP provides many directives for controlling the parallel execution, how variables are shared (or not) across threads, etc.
Intel Fortran also offers automatic parallelization, which does not require any source changes, though it is not as effective as proper use of OpenMP. CVF does not support either of these.
Intel Fortran supports OpenMP, which is the industry-standard way of developing multithread applications. In the simplest scenario, you use the !$OMP DO directive as follows:
!$OMP DO
do i=1,1000
... body of do loop
end do
!$OMP END DO
This says to execute the body of the do loop in parallel. OpenMP provides many directives for controlling the parallel execution, how variables are shared (or not) across threads, etc.
Intel Fortran also offers automatic parallelization, which does not require any source changes, though it is not as effective as proper use of OpenMP. CVF does not support either of these.
