Multicore Programming
-
http://www.embedded.com/design/multicore/208803064?pgno=1[^] good article i thought. Just out of interest, how many plan to/ or are modifying software architecture to fit the evolving hardware we live in. i am not sure it is worth compartmentalising everything into worker threads just yet but give it a few years(maybe months :(( ) it might be a std software model
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction." -Albert Einstein
-
http://www.embedded.com/design/multicore/208803064?pgno=1[^] good article i thought. Just out of interest, how many plan to/ or are modifying software architecture to fit the evolving hardware we live in. i am not sure it is worth compartmentalising everything into worker threads just yet but give it a few years(maybe months :(( ) it might be a std software model
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction." -Albert Einstein
DownUnderDev wrote:
Just out of interest, how many plan to/ or are modifying software architecture to fit the evolving hardware we live in.
I'm developing an application that has to process some geometric data. So far, I've not developed a multithreaded architecture, but all the components that process the data are thread-safe. The type of processing can be easily split across multiple cores, but I don't want to add that bunch of complexity unless I'm sure I need it. In other words, I'll first test the performance of the application and then decide whether or not to modify the algorithms so they use multiple threads. At any rate, I designed the architecture so that this is easy achievable.
If you truly believe you need to pick a mobile phone that "says something" about your personality, don't bother. You don't have a personality. A mental illness, maybe - but not a personality. - Charlie Brooker My Photos/CP Flickr Group - ScrewTurn Wiki
-
http://www.embedded.com/design/multicore/208803064?pgno=1[^] good article i thought. Just out of interest, how many plan to/ or are modifying software architecture to fit the evolving hardware we live in. i am not sure it is worth compartmentalising everything into worker threads just yet but give it a few years(maybe months :(( ) it might be a std software model
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction." -Albert Einstein
Nice article. I consider threading when writing any code, but generally only actually utilise multiple threads for a few tasks where the performance gain is large. Anything taking more than a second or two I normally do with a background worker to keep the GUI responsive. Depending on the use case of the feature depends on if a progress bar is displayed and other actions prevented, or if the user can continue doing other things. I generally find that most tasks are bound by some other factor than CPU time though. More often than not it's disk access or network access that prevent things being done quicker, so normally good caching is more beneficial than threading. Obviously, this depends on the kind of software you are writing.
Simon
-
http://www.embedded.com/design/multicore/208803064?pgno=1[^] good article i thought. Just out of interest, how many plan to/ or are modifying software architecture to fit the evolving hardware we live in. i am not sure it is worth compartmentalising everything into worker threads just yet but give it a few years(maybe months :(( ) it might be a std software model
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction." -Albert Einstein
It is often not important to actually have your code run on multiple processors, apart form making the design complex in the extreme, I know, I have been writing multip proc code kernel drivers for 10 years, there isnt actually much benefit. You might be surprised but think about it. If your application had the entire processor it would run just fine. So what does slow it down? Well, its all the other requests to run on the chip, especially kernel requests ahich always take precedence over user mode, particularly IO such as network traffic. So a better system would be to have the kernel on one processsor and user mode on another. Oh, and MSN on a third....
Morality is indistinguishable from social proscription
-
It is often not important to actually have your code run on multiple processors, apart form making the design complex in the extreme, I know, I have been writing multip proc code kernel drivers for 10 years, there isnt actually much benefit. You might be surprised but think about it. If your application had the entire processor it would run just fine. So what does slow it down? Well, its all the other requests to run on the chip, especially kernel requests ahich always take precedence over user mode, particularly IO such as network traffic. So a better system would be to have the kernel on one processsor and user mode on another. Oh, and MSN on a third....
Morality is indistinguishable from social proscription
yes it would be good if you could build a software model that enumerated the hardware resources then set affinties of certain tasks to certain resources. so kernal mode functionality never got in the way of user mode functionality etc. hopefully one day can get away from custom platforms a start writing device drivers for WinCE or something fun like that test out a few things.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction." -Albert Einstein
-
http://www.embedded.com/design/multicore/208803064?pgno=1[^] good article i thought. Just out of interest, how many plan to/ or are modifying software architecture to fit the evolving hardware we live in. i am not sure it is worth compartmentalising everything into worker threads just yet but give it a few years(maybe months :(( ) it might be a std software model
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction." -Albert Einstein
DownUnderDev wrote:
Just out of interest, how many plan to/ or are modifying software architecture to fit the evolving hardware we live in.
Ironically, I came from the super-computer era, with an Onyx 2000 - 16-processor at my disposal I began this silly 3D business I do back in the 90's. Although I moved to the PC, I never could get a decent threading model that didn't overload one poor CPU, so we never got to a single core architecture. Now that PC's are multi-core, I can parade my architecture as planned for the future of multi-core and multi-threaded systems. I am reasonably sure I can handle cores up to 16 because I have been there. At the moment because of the speed of the cores, I doubt I could get enough work to go past 4, but I keep proposing work that will bring it up to about 8 to 16 knowing that future will come.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
Nice article. I consider threading when writing any code, but generally only actually utilise multiple threads for a few tasks where the performance gain is large. Anything taking more than a second or two I normally do with a background worker to keep the GUI responsive. Depending on the use case of the feature depends on if a progress bar is displayed and other actions prevented, or if the user can continue doing other things. I generally find that most tasks are bound by some other factor than CPU time though. More often than not it's disk access or network access that prevent things being done quicker, so normally good caching is more beneficial than threading. Obviously, this depends on the kind of software you are writing.
Simon
Simon Stevens wrote:
Obviously, this depends on the kind of software you are writing.
This is the most important part. Knowing and understanding your bottleneck, your options, and need is extremely important. If you don't know how to measure an IO bottleneck, chances are you wouldn't know how to cache the IO anyhow. Threading generally means you are creating data rather than passing it around. Computationally you can still fill a multi-core machine, although it is obvious by some of the replies this is forgotten or deliberately ignored. A gaming model is my favorite example since physics is computationally expensive, as is graphics and advanced AI methods. Flocking behavior might rely on IO as a model primarily for one entity, and AI flocking response models react the other input, either as a flight, fight, or follow behavior. As you build up computationally intensive operations, eventually they all get IO'd to the graphics, so caching is still very important, but algorithmic operations on those other cpu intensive operations can get heavy on a single core if you don't think about your architecture. The latter being the key you mentioned. Knowing what you have, what you need, and what to do with it, understandng your architecture and design in response to needs is the key to meeting multi-core capability. Some software like heavy user response will respond fine with minor threading and still never fill a single core -- there is just not enough computation to ever do so, that is fine to stay that way.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
http://www.embedded.com/design/multicore/208803064?pgno=1[^] good article i thought. Just out of interest, how many plan to/ or are modifying software architecture to fit the evolving hardware we live in. i am not sure it is worth compartmentalising everything into worker threads just yet but give it a few years(maybe months :(( ) it might be a std software model
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction." -Albert Einstein
DownUnderDev wrote:
Just out of interest, how many plan to/ or are modifying software architecture to fit the evolving hardware we live in.
I have been doing multicore programming since the late 1990s with all of my medical imaging applications. In the beginning I was using multiple threads that were triggered by events but now I am using mainly thread pools.
John
-
Simon Stevens wrote:
Obviously, this depends on the kind of software you are writing.
This is the most important part. Knowing and understanding your bottleneck, your options, and need is extremely important. If you don't know how to measure an IO bottleneck, chances are you wouldn't know how to cache the IO anyhow. Threading generally means you are creating data rather than passing it around. Computationally you can still fill a multi-core machine, although it is obvious by some of the replies this is forgotten or deliberately ignored. A gaming model is my favorite example since physics is computationally expensive, as is graphics and advanced AI methods. Flocking behavior might rely on IO as a model primarily for one entity, and AI flocking response models react the other input, either as a flight, fight, or follow behavior. As you build up computationally intensive operations, eventually they all get IO'd to the graphics, so caching is still very important, but algorithmic operations on those other cpu intensive operations can get heavy on a single core if you don't think about your architecture. The latter being the key you mentioned. Knowing what you have, what you need, and what to do with it, understandng your architecture and design in response to needs is the key to meeting multi-core capability. Some software like heavy user response will respond fine with minor threading and still never fill a single core -- there is just not enough computation to ever do so, that is fine to stay that way.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
I agree. I frequently see questions in forums saying things like "how to a create a gazillion threads to speed up my file copy operation?". The important thing is to know where your program is slowest. I generally write in the simplest possible way first, then profile the app, then improve the biggest bottle necks with whatever technique is most appropriate for the causes of any slowdowns. (I saw your post on your new PC for CUDA stuff. Now that looks very cool. Extreme parallel processing :-D .)
Simon
-
http://www.embedded.com/design/multicore/208803064?pgno=1[^] good article i thought. Just out of interest, how many plan to/ or are modifying software architecture to fit the evolving hardware we live in. i am not sure it is worth compartmentalising everything into worker threads just yet but give it a few years(maybe months :(( ) it might be a std software model
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction." -Albert Einstein
The sort of work I do all the benefit is in the UI or database layer which is in turn controlled by 3rd party component and library writers. I *rarely* need to toss anything on to another thread so I'm hoping the benefits will be automatic as we move to newer versions of those libraries. I'm just guessing but I think that's where the majority of benefit is going to be for multicore specific coding. I don't see the average programmer *really* needing to think about this stuff much in the near term future.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
-
I agree. I frequently see questions in forums saying things like "how to a create a gazillion threads to speed up my file copy operation?". The important thing is to know where your program is slowest. I generally write in the simplest possible way first, then profile the app, then improve the biggest bottle necks with whatever technique is most appropriate for the causes of any slowdowns. (I saw your post on your new PC for CUDA stuff. Now that looks very cool. Extreme parallel processing :-D .)
Simon
Simon Stevens wrote:
(I saw your post on your new PC for CUDA stuff. Now that looks very cool. Extreme parallel processing
I have even gotten more positive response since my last upgrade at home. My last home computer was the very first dual core chip released by AMD. I think I scored 2.0 or there abouts because multi-core was evil and threading was the bane of all programmers. :) I moved up a point since then. :laugh:
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
DownUnderDev wrote:
Just out of interest, how many plan to/ or are modifying software architecture to fit the evolving hardware we live in.
Ironically, I came from the super-computer era, with an Onyx 2000 - 16-processor at my disposal I began this silly 3D business I do back in the 90's. Although I moved to the PC, I never could get a decent threading model that didn't overload one poor CPU, so we never got to a single core architecture. Now that PC's are multi-core, I can parade my architecture as planned for the future of multi-core and multi-threaded systems. I am reasonably sure I can handle cores up to 16 because I have been there. At the moment because of the speed of the cores, I doubt I could get enough work to go past 4, but I keep proposing work that will bring it up to about 8 to 16 knowing that future will come.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
wow we come from different worlds ha ha i think my first commercial job was with the PIC16C53 and ASM a little less power in my hands :-\
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction." -Albert Einstein
-
wow we come from different worlds ha ha i think my first commercial job was with the PIC16C53 and ASM a little less power in my hands :-\
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction." -Albert Einstein
DownUnderDev wrote:
wow we come from different worlds ha ha i think my first commercial job was with the PIC16C53 and ASM a little less power in my hands
well, I didn't start there... I started as an accountant, if you leave off gardening and phone sales and flipping burgers and making DQ deserts to put myself through school and buy things in high school (my family was poor, but the children were industrious, shall we say...). My first job was accounting programming, doubling as a fill-in accountant as needed. I jumped to engineering using multithreaded communication models, user interface, data mining and prediction I used in my job and moonlighting. Even then my first assignment was text based user interfaces, I moved on to 2GUI and 2 graphing application, and some minor 2D mapping. From there I jumped into 3D because no one else understood it. I had done a high school science fair project on 3D graphics and its future in application of everyday life, demonstrating some likely uses such as landscape modeling, city planning, and traffic collision avoidance and traffic jam prevention. Given we as human beings "see" in 3D my goal was to present things in the most natural way to allow our own instincts to serve as part of the UI. I still am to this very day. :)
-
http://www.embedded.com/design/multicore/208803064?pgno=1[^] good article i thought. Just out of interest, how many plan to/ or are modifying software architecture to fit the evolving hardware we live in. i am not sure it is worth compartmentalising everything into worker threads just yet but give it a few years(maybe months :(( ) it might be a std software model
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction." -Albert Einstein
Ours has been multi-threaded for years. Of course, just recently, we get to really find out how thread-safe it all is :omg: