OSDev.org

hi,

as many of you guys know that we are moving towards multicore computers, and writing programs for this new kind
of computers probably will change, has any of you guys wrote such program?
I'm not talking about writing a normal threaded-program
so what troubles did you face?

Regards

abuashraf wrote:hi,

as many of you guys know that we are moving towards multicore computers, and writing programs for this new kind
of computers probably will change, has any of you guys wrote such program?
I'm not talking about writing a normal threaded-program
so what troubles did you face?

Regards

Ive always thought of a cpu as something we send a script to describe what we want it to act like, something that mimics an object.

We have a language for us to describe our objects.. and a language to describe to tell the CPU how to mimic our objects.

We don't really need to concern ourselves with multi cores in how we describe our objects, and i'm not sure we really -want- to in our language to describe how to mimic our objects.

Except that none of our compiled languages naturally supports multicore.

gerryg400 wrote:Except that none of our compiled languages naturally supports multicore.

Well, if we are describing objects, how exactly could we make one instance of that object run on mulitple cores?

We could select which core to mimic this object when available, or we can run more than one object at once.

Aside from what is/would be an ideal situation. In practice working with multicores comes down to somehow writing a program that efficiently does multiple things at the same time. Depending on what you want to do that varies from running multiple instances of your program loosly coupled by some server that dishes out jobs to a multi-threaded program riddled with mutexes.

The first category is quite easy to write, extends well to systems consisting of many individual pc's only connected with network cables, and is quite capable of giving high throughput. However, do not expect it to respond well to task that consist of small units (< 1 second). The last option can be a lot more difficult to write, as you have to worry about things like deadlock and race conditions. Be prepared to run into hard to find bugs when you try it. It can however be very good latency wise as well as throughput wise, because communication is a lot faster. It depends on the situation what is more usefull. In a (web)server you probably want to use the second, but when doing really big calculations the first might be the more effective solution.

Both require you to put some serious thought in how to divide the task at hand across multiple threads, and that can be easy or hard depending on what it is. Stuff inherently parallel is usualy easier to put in suitable form than stuff that is not.

Hope this answers your question

In response to cxzuk,
Objects are data, they aren't run. We manipulate them, but the way that every language on this globe does that is still not parallel. Thinking of a program as telling the cpu how to mimic a certain object is in my opinion not a good analogy, it creates too much confusion with object oriented programming, and is just not the way most programs actually work.

davidv1992 wrote:Aside from what is/would be an ideal situation. In practice working with multicores comes down to somehow writing a program that efficiently does multiple things at the same time. Depending on what you want to do that varies from running multiple instances of your program loosly coupled by some server that dishes out jobs to a multi-threaded program riddled with mutexes.

Id like to argue that both are actually the same thing. Two "programs" is just two objects just like two "threads" are two objects.

davidv1992 wrote:The first category is quite easy to write, extends well to systems consisting of many individual pc's only connected with network cables, and is quite capable of giving high throughput. However, do not expect it to respond well to task that consist of small units (< 1 second). The last option can be a lot more difficult to write, as you have to worry about things like deadlock and race conditions. Be prepared to run into hard to find bugs when you try it. It can however be very good latency wise as well as throughput wise, because communication is a lot faster. It depends on the situation what is more usefull. In a (web)server you probably want to use the second, but when doing really big calculations the first might be the more effective solution.

A good rule to follow id like to just say is to keep optimisations out of design. They tend to be target specific and cause problems in maintenance. But they do need to be in our code that is sent to the processor. Something not so easy with current languages.

davidv1992 wrote:Both require you to put some serious thought in how to divide the task at hand across multiple threads, and that can be easy or hard depending on what it is. Stuff inherently parallel is usualy easier to put in suitable form than stuff that is not.

Objects can be made up of other objects in a nested fashion, but tend to require step by step linking. Treat a thread as an object instance and hopefully it'll be a bit easier to debug/code etc

davidv1992 wrote:Hope this answers your question

In response to cxzuk,
Objects are data, they aren't run. We manipulate them, but the way that every language on this globe does that is still not parallel. Thinking of a program as telling the cpu how to mimic a certain object is in my opinion not a good analogy, it creates too much confusion with object oriented programming, and is just not the way most programs actually work.

Objects are not just data, They contain code aswell.

im glad you said that, and your probably right. Languages don't support it. But i have been currently experimenting with assembly object files. Keeping the objects separate and the information of the boundaries.

To run in parallel or front-load can only be done in the context the objects are in, which is what describes the links between the objects, and currently we as programmers do not do this well enough (fault of the languages?).

A few languages aside, in most objects don't contain code, their descriptor (the class) contains code that specifies how certain interactions modify the object, but in my opinion that is not part of the object. In that perspective a lot of our programs aren't objects in that sense, because they take some input and produce some desired effect (output). In that sense your view is incomplete. I might overestimate this a bit because of the fact that my background is mostly in competition programming, but I've always thought of the objects/classes abstraction as usefull, but having limitations.

You state also that the design should not contain optimizations. I couldn't disagree more with you. If there is any place where there should be carefull consideration of performance it would be in the design, because a better optimized design (ie using different algorithms/datastructures) doesn't make it that much harder to maintain, whilst having the potential of giving massive speedups, whilst code optimization usualy isn't as effective, and usually does mean that maintainance is a lot harder.

Especially in the design of parallel processing programs, you really should think about how work is distributed, because a wrong choice there could seriously hamper your programs ability to really use all of the available processing power.

From your last post I also get the impression that you think of code and design as being one and the same. Although for simple programs this can be a reasonable way to think about it, for larger programs I would suggest making the design seperate from the code, documenting it seperately and so on. This makes thinking about it a lot easier, and seperates the high-level overview of how things interact from the actual details of how each piece does it's job.

The awful reality is that parallel programming is hard, and it is our job to make it perform well. Sure, certain modifications to compilers and languages certainly could make some of the work a little bit easier, but the really hard part, the deciding of who does what, will always be the domain of the programmer. A compiler simply will never have the information to properly decide on those issues.

davidv1992 wrote:A few languages aside, in most objects don't contain code, their descriptor (the class) contains code that specifies how certain interactions modify the object, but in my opinion that is not part of the object. In that perspective a lot of our programs aren't objects in that sense, because they take some input and produce some desired effect (output). In that sense your view is incomplete. I might overestimate this a bit because of the fact that my background is mostly in competition programming, but I've always thought of the objects/classes abstraction as usefull, but having limitations.

Working from such a low level i think has made you mix the two alittle. Objects are made up of data and methods. When they hit the lower level they may indeed only be functions that modify data, but the two levels are very separate.

davidv1992 wrote:You state also that the design should not contain optimizations. I couldn't disagree more with you. If there is any place where there should be carefull consideration of performance it would be in the design, because a better optimized design (ie using different algorithms/datastructures) doesn't make it that much harder to maintain, whilst having the potential of giving massive speedups, whilst code optimization usualy isn't as effective, and usually does mean that maintainance is a lot harder.

I don't believe a different algorithm (or basically a different design) is an optimisation. But yes, I guess what i call optimisations you call code optimisations.. An example;

I used to code some bits for the GP32 handheld. I had read and was told that if my loops counted downward i would save x% for each iteration.. So i spend several hours writing all my algorithms to work with counting backwards.

In the end it seemed that this "optimisation" was written in the 80's, manufacturing of the chips had made the ALU so fast that other parts where slower than what I was improving. I was left with hard to read and maintain code and for next to no gain.

I can see XOR reg, reg instead of reg = 0 heading a similar way.

davidv1992 wrote:Especially in the design of parallel processing programs, you really should think about how work is distributed, because a wrong choice there could seriously hamper your programs ability to really use all of the available processing power.

From your last post I also get the impression that you think of code and design as being one and the same. Although for simple programs this can be a reasonable way to think about it, for larger programs I would suggest making the design seperate from the code, documenting it seperately and so on. This makes thinking about it a lot easier, and seperates the high-level overview of how things interact from the actual details of how each piece does it's job.

Ive been active in the forum about languages etc for a while, i believe current code does not equal design... But that poses the question, what exactly is code for?

I hope you can also see this question also arises with having separate code and separate design.

Theres been some great work in trying to make code = design. After all thats the whole point of object orientated languages. I support Data-Context-Interaction, but its implementation is currently on-top of language ideas. (C++ uses templates).

For me, ASM(/FORTH) should be code, and the next language should be design.

davidv1992 wrote:The awful reality is that parallel programming is hard, and it is our job to make it perform well. Sure, certain modifications to compilers and languages certainly could make some of the work a little bit easier, but the really hard part, the deciding of who does what, will always be the domain of the programmer. A compiler simply will never have the information to properly decide on those issues.

"Who does what" is thinking in objects. Id love to give a parallel program example a try, can you think of a simple example to implement?

I think your view of optimizating is a little limited. The cold hard reality is that design optimizations are usually the where the real speedup can be gained, and even code optimizations might benefit from a different design. For example, consider the following
and the operation that is done most on these structures is scanning a very big array to find which have a certain age. It can give quite a bit of speedup using two seperate arrays for the names and ages instead of an array of structs, because now we only need to fetch every employees age from main memory into the cache, instead of having to fetch both and effectively wasting 50% of our cache. However, this optimization involves a significant change in our design. The graphics programming black book contains more of these kind of examples.

As to your question of what is code for, it is very simply our instructions to the computer on HOW to do what we want, it contains all the little details neccesary for the computer to know. I usually let design come to it's own both in the way I structure the different source files in their respective directory's and describing it in seperate text files, mostly intended for finding out where certain stuff is and/or should be located.

I don't think the main goal of object oriented programming is to unify code and design. Yes it allows some different ways of looking at things, but most of the time design is still done in class diagrams and flowcharts or whatever you might call em. It does however allow you to better reflect the design in the code, and can be a helpfull tool to avoid code duplication.

It might indeed be interesting to compare how we program parallel programs, but there aren't any good ideas in the top of my head right now. I'll give it a bit of thought if you think it might also be interresting.