|
ok... here's one thought i have for our app
(a) Assign processor affinity to a calc job (exe, kicked started by another exe/calc controller) based on user
(b) Assign processor affinity to a calc job (exe, kicked started by another exe/calc controller) based on calculation type
I don't think .NET framework or Windows can make that decision for you...
dev
|
|
|
|
|
Clifford Nelson wrote: the current generation of languages such as C++, C#, Java really are not designed to handle all these cores
somebody banned the use of threads? :S
|
|
|
|
|
No, but threads suck. They're only actually good at handling completely independent parallel workloads that run for a relatively long time - and there are almost none of those, not in the average app anyway.
|
|
|
|
|
I agree, and it is mostly because writing scalable code that runs on separate CPU threads is not a trivial task, unless you use frameworks like OpenCL(C++), TPL(.NET), and Scala(JVM) in combination with the languages mentioned in the OP's post xD
Then there are other cool bits like C++ AMP and CUDAfy.NET for writing C++/C# code that scales and runs on GPU threads.
|
|
|
|
|
I like "Thread sucks" part but can't agree with your comment on that there's no need for threads.
we do real time apps where screens can't freeze up, so many times, we send a job to background thread pool (calc, data fetch...etc) so UI remains responsive. Until the thread job is done, data comes back to UI thread where it's binded to UI synchronously.
dev
|
|
|
|
|
devvvy wrote: but can't agree with your comment on that there's no need for threads.
Well if you put it like that, I don't agree with myself either 
Like you say, they're nice for asynchronous programming too. This was a thread about 48 cores and how they might be used though - threads suck in the context of keeping all those cores fed.
|
|
|
|
|
That is not a language feature, that is a framework feature. You could say that async is a language feature, so maybe in that case. What you want is a language to state the program so that its parallellism can be determined and used. If the language was truly parallel friendly you would not even have to think about threads or background, or anything like that. That you do is the problem.
|
|
|
|
|
Thread is an OS feature, not a framework feature. System.Threading.Thread just happens to use kernel32::CreateThread to implement the required functionality.
Using the same logic, we shouldn't use C# to add 1 plus 1 because Int32 is declared and implemented in CLR and not a C# feature xD
|
|
|
|
|
What do you mean by C# not being designed to handle all the cores? As of .NET 4, parallel programming in C# became relatively straight forward. Link[^].
|
|
|
|
|
Even TPL CTP1 worked like a charm in 3.5 ^^
|
|
|
|
|
C# has some tools to help from the TPL, but it does not automatically handle multiple cores. It requires some programmer intervension, and it is not C# that does this, but the framework.
|
|
|
|
|
Indeed it does, but if you use TPL and the other features of the framework then you have multi core capability. Your post seemed to suggest that you couldn't do this right now, which is why I posted.
|
|
|
|
|
Agreed, I could have stated it better. LINQ with TPL is a great case of providing a way to easily put in parallelism. But to use all those cores effectively for most for most programs would require a applications to be broken up into a hell of a lot of tasks, and the programmer would have to do a lot of work to figure out what could be done in parallel. Many scientific applciations would be fairly easy, but most applications this is not the case.
|
|
|
|
|
Clifford Nelson wrote: But to use all those cores effectively for most for most programs would require
a applications to be broken up into a hell of a lot of tasks, and the programmer
would have to do a lot of work to figure out what could be done in parallel
Indeed. There are a lot of applications where this could be done, but the big issue is that a lot of developers aren't aware of the nuances of parallel programming, so they end up doing it badly (or they don't do it at all).
|
|
|
|
|
As I stated I could have stated it better. It was right to post since it managed to bring out the issues with wording in my original statement. My Master's Degree was in Computer Engineering, so I became familiar with the issues of massively parallel computers. Programming Crays is not easy, nor any of the other massively parallel computers. That is why we have not seen a lot of them. 240 cores
|
|
|
|
|
I learned the craft of parallelism when I was working in the Oil and Gas industry many years ago. You had to do it right, or the consequences could be disastrous.
|
|
|
|
|
I never had to do it, but read enough about the problems.
|
|
|
|
|
As stated earlier, TPL is a framework feature, not really a language feature. You still have to state it instead of inferring it. Things are getting better, but still to use massive parallelism would require a lot more work. The async keyword may make a difference. What TPL does so well is throttle things so that the system does not start thrashing due to too many threads. What you want is not to even have to worry about it, like now with memory management.
|
|
|
|
|
|
Those threads are separate programs. Yes you can run separate programs easily on different threads, the OS handles that, and the applications are independent. Of course trying to coordinate all these programs efficiently would be a problem since would have to use cross application communication. Now I want to parallelize every aspect of your specific application so that your one application will effectively use 240 cores, or even a million cores. Good Luck. If you can do it then they should hire you to program the Titan, you obviously are perfect for the job since you must be an Einstein.
C++ is really not much different from C# (or C for that matter). It is the framework generally that provides access to the treading. Yes with 4.5 there is the async keyword, but that is really it. Unsafe is realive. Perfect programming would make any "unsafe" code safe.
If you had 240 cores, do you think your current PC software would be using them efficiently? That is the issue.
|
|
|
|
|
|
I suspect that things will morph with time. We are already seeing it with things like LINQ. Programmers cannot deal with the details of threads and be efficient. Just like they could not deal with Memory Management and be efficient; Using Garbage Collection produces overhead that could be eliminated if people did thier own memory management.
|
|
|
|
|
Terrence Dorsey wrote: we could finally do things that take way too much processing power today," said Patrick Moorhead, an analyst with Moor Insights and Strategy
and what are these "things" that M. Patrick Dickhead analyst at dick insights "could finally do" ? Does he have any plan for launching a rocket but is symptomatically blocked due to the lack of power of his iphone????
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^]
|
|
|
|
|
One processor can do the work and 47 processors can do garbage collection! 
|
|
|
|
|
Windows Phone 8 is here, and with it comes new and exciting devices, along with more markets and languages, making it easier than ever to build great apps for a larger audience. See what’s new in the SDK. Download it today and get started building your WP8 apps.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
