Programming for dual core

damnyanks

Howdy,

Not done any development for a while. Am curious

If I write an application in Java or C++ for a dual core CPU is it possible to pass various tasks to a different core?

If so how would I do this with Java? (which is what I'd rather use!) Or is it possible with .net

Would imagine its quite possible with c++

Thanks

shepherd

This should get you started:
http://www.javaworld.com/javaworld/jw-04-1996/jw-04-threads.html

damnyanks

Thanks,

I understand threads. But is that what is used to specify what core to use on a CPU or is that even possible? Does the CPU just pass on whatever information to the other core, if indeed that is even how it works.

What to write something effective for my CPU which is a "dual core" its a lot of number crunching.

rsynnott

Any half-decent operating system will distribute threads across processors in a sensible way. For two cores, divide your processor intensive task into at least two threads (assuming your task gains more from being split up than it loses from comms overhead between threads, of course). What exactly are you trying to do?

There's no standard way to control thread/processor allocation programatically, and nor should there be.

Torak

rsynnott wrote:

There's no standard way to control thread/processor allocation programatically, and nor should there be.

I wouldn't usually comment on your statement, as you are usually quite helpful, but in this instance you could at least explain why

rsynnott wrote:

and nor should there be.

is true.

@OP the reason that this is true is that the OS (and for that matter the hardware and your compiler) knows far more about the code that is executing than you or your program know. Now that said on an extremely small program or a small subset of a program you might be able to know as much, but not more.

This is a good thing as it means that you can see the advantage of hardware, compiler and os improvements without changing your code.

Your code will automatically use the cores in the most efficient way that is allowed (subject to how the code has been implemented, i.e as stated if there are multiple threads of execution each doing a chunk of a complicated calculation, then it easier for the os to allocate the processing more efficiently).

nuttz

rsynnott wrote:

For two cores, divide your processor intensive task into at least two threads

The number of threads used in your program does not depend on the number of processors available for use but on the what suits the workload of your program.

rsynnott wrote:

There's no standard way to control thread/processor allocation programatically, and nor should there be.

In Java, the JVM determines which thread gets time on the processor.

As for Mr Synnott's assumption that a thread should not/cannot be allocated to a processor is a bit silly. Both Linux and Windows support binding processes to a processor.

rsynnott

nuttz wrote:

The number of threads used in your program does not depend on the number of processors available for use but on the what suits the workload of your program.

He mentions that he is doing "number crunching". Although I could certainly be wrong, I assumed that this meant processor-intensive batch work. It is often sensible when doing such things to deliberately (and artificially) split the work into multiple threads or processes. (Raytracers tend to do this, for example).

nuttz wrote:

In Java, the JVM determines which thread gets time on the processor.

As for Mr Synnott's assumption that a thread should not/cannot be allocated to a processor is a bit silly. Both Linux and Windows support binding processes to a processor.

Please re-read. Note use of word standard. Thank you. And while certainly possible, it is almost never appropriate to do it programmatically (for an ordinary general-purpose multiprocessor).

nuttz

rsynnott wrote:

it is almost never appropriate to do it programmatically (for an ordinary general-purpose multiprocessor).

Are you serious? Think about what you are saying. To say it is never appropriate is a bit naive in my humble opinion.

leeroybrown

As pointed out above the OS you are running on is normally best placed to make the decision but if you want to look at this 'processor affinity' is what you're looking for. The linux 2.6 kernel and the Win32/Win64 kernel should (and probably others) allow you to do this programatically if you want to do so from a C or C++ application. To my knowledge there is no way of setting affinity within the JVM.

rsynnott

nuttz wrote:

Are you serious? Think about what you are saying. To say it is never appropriate is a bit naive in my humble opinion.

Again, read. Each. Word. Carefully. "almost never" is not the same as "never". Now, in general, the only case where it would be appropriate to try to second-guess the operating system on this would be where you you know exactly what your program is going to be running on, where you know that it'll be the only thing running there, and so on. You'd also need to know that the program would only be run by a privileged user, and so on. There's more of a case for external setting of processor affinities by a system administrator, though.

And there's no such thing as a humble opinion, obviously.

nuttz

rsynnott wrote:

Now, in general, the only case where it would be appropriate to try to second-guess the operating system on this would be where you you know exactly what your program is going to be running on, where you know that it'll be the only thing running there, and so on.

You would consider this as almost never?

rsynnott

nuttz wrote:

You would consider this as almost never?

It's an 'almost never' for commercial software. It's a possible but improbable for special-purpose software. For embedded things and so on, fair enough, but you're moving away from general-purpose multiprocessor there anyway.

nuttz

rsynnott wrote:

It's an 'almost never' for commercial software. It's a possible but improbable for special-purpose software. For embedded things and so on, fair enough, but you're moving away from general-purpose multiprocessor there anyway.

general-purpose multiprocessor?? - do you not realise that quad core machines are due next year, the topic we are discussing is very much an aspect of programming languages which has come back to the forefront, thus Sun's concurrency improvements in JDK5.

Your definition of "commercial" obviously differs from the standard definition. I recommend you gain some actual commercial experience before inflicting your misguided opinions on others with regards to concurrent programing with enterprise computing or personal computing. There are obvious gains for game developers for optimising for quad core architectures as well as for business.

rsynnott

In general, you should not try to second-guess the operating system on this. If you wish to nudge threads towards different processors, you can always creatively use priorities. I really can't see companies releasing software on the basis that it will work 1% faster on some particular given quad-core chip, and potentially far worse on everything else.

If nothing else, on the home user front, Microsoft apparently intends to encourage people to use a non-privileged account for normal work in the next version of their operating system; most other operating systems already do so. I'm moderately certain that non-privileged users can't mess with thread affinities.

Mutant_Fruit

For a normal application, i can't think of a good reason why you would programatically force a specific thread to run on a specific core. I can think of some very very common scenarios when that would be the worst thing you can do, and some very uncommon ones where it might help a bit.

For example, take your ordinary Seti@Home/Folding@Home/whatever fanatic. They run their @Home program on CORE2, at high/realtime priority. Joe Bloggs the programmer decided that he wants 1/2 his program to run on CORE1 and 1/2 on CORE2, so he programmatically set that to happen. Of course, now his program will suffer severely as it will get practically no time on CORE2.

One way around that would be to give his program high priority on CORE2. But then you have the problem, what if the @Home fanatic runs on CORE1. Now both cores have CPU intensive tasks running at High/Realtime priority. The computer grinds to a halt.

Now, lets pretend we let windows take care of managing which thread runs on which core. CORE2 still runs @Home on high priority, but CORE1 now can run both Thread1 and Thread2 off Joe Blogg's program. Thats "A Good Thing" (tm). Now when the @Home program finishes, one of Joe Blogg's threads will move to core2, giving him the performance he wants.

I'd go one step further than "almost never" and i'd say "never except for very specific applications". I can't think of one good reason to do this on a regular home PC.

damnyanks

Thanks for all the help. The application will run some statistic / finance models as part of a grid. Of course the grid at first will have a very limited amount of CPU's (16)

MrPinK

nuttz wrote:

There are obvious gains for game developers for optimising for quad core architectures as well as for business.

As you have already stated, the number of threads used in your program should not depend on the number of processors available but on what suits the workload of the program. Designing specifically for quad core is putting a cap on future performance. You want to be able to see improvements when 8 cores come around. Scalable is the new fast.

PhantomBeaker

nuttz wrote:

general-purpose multiprocessor?? - do you not realise that quad core machines are due next year, the topic we are discussing is very much an aspect of programming languages which has come back to the forefront, thus Sun's concurrency improvements in JDK5.

Two points strike me on this:

1/ I read RSynnott's comment about moving away from general-purpose multiprocessor as being "Not an application specific chip". Taking your example of a 4-core processor - is this one that you plug into a home PC? In which case, I'd say that it IS a general-purpose multi-processor because it's not built for a very specific purpose - i.e. it's not application specific, it's not designed to be embedded in a calculator. It's not designed to play a crappy little game on your watch. It's designed to crunch whatever you throw at it. In which case a quad-core processor is still general purpose, just with more power.

2/ To the OP, reading your latest post, if you're looking at getting a grid done, I suggest you look at grid computing frameworks from the outset. There are a few already out there... and some are even free. The reason I say it is, if you're planning on expanding your program later to use more CPUs, you have two options. You can either hardcode in more code to handle the extra CPUs, which makes it non-scalable, or you can write some code that will spread it out over n processors where n is only known at run-time. To me that sounds like a pain, and is a problem already solved by grid computing architectures that are out there.

Aoife

stevenmu

Ok there's two completely different things being discussed here. One is multi-threaded/multi-processor computing and the other is grid computing, two very different beasts. The first is one single complete self contained system with multiple processing units which the work load can be distributed over, the other is seperate systems (which may or may not contain multiple processing units) connected via some communication mechanism which the workload can be distributed between.

Both archetectures require a completely different approach.