Agreed, but for some reason folks still tend to have alot of problems doing it.Quote:
Originally Posted by TheCPUWizard
I hear quite a bit about people who find mt coding too hard, or don't see the benefits over st programming.
Printable View
Agreed, but for some reason folks still tend to have alot of problems doing it.Quote:
Originally Posted by TheCPUWizard
I hear quite a bit about people who find mt coding too hard, or don't see the benefits over st programming.
I see you "ducked" answering the questions about a specific scenario in my previous post... :rolleyes: ;)Quote:
Originally Posted by Arjay
No interest in answering.Quote:
Originally Posted by TheCPUWizard
Well I've Voted Yes (past 6 months).. My current project is using mutiple cores, however only small sections of the application does so..
Most of the application is linear and user speed dependent. but there are pieces that are CPU slaves .. IE ..
Once a transaction has been completed, the following steps need to be completed
1) Store Info Via Serial on a token.
2) Save Transaction Info in Sql DB..
3) Print Reciept.
4) Adjust sales stats (sql)
5) reset for new transactiion
Well 1 - 4 can all be done together, #5 can be done when all are complete (or more specifically when #1 is done)
My development system has a duo core, and starting a few worker threads at this point does show a marked increase in 2nd core usage..
At the moment this is the only muticore code that i'm using, Implimented 2 months ago..
Gremmy..
Each can be done at the same time, if you send each task to a different message pump, running on multiple processors as available. The print receipt queue would only process when something was ready in the queue.
That is at least a start, but what I have been referring to is MUCH finer grained. Lets look at the sample steps you posted and see what potentials there may be.Quote:
Originally Posted by GremlinSA
Important disclaimer: Since I am using Gremmy's sample some of these are "contrived" and most likely would not make sense from a practical standpoint using current common hardware (but may make sense within a few years). I am going to pretend that this work is being done on the server side and that small improvements in time would have an impact that would not exist for a client application where a human was waiting...
Lets look at the "Store Transaction into DB" step. This involves (typically)
[indent]
1) Create a Command Instance
2) Create Parameter Instances
3) Prepare the Command (often implicitly)
4) Create a connection (from a pool)
5) Execute the command
[/quote]
What would happen if there were alreat a number of (blocked) threads which had a command object already created and waiting for parameters. Then when it comes time to execute, the thread was awakened, and in parallel established the parameters whil the connection was being "refreshed" then executed the command, returned the result,and at a lower priority "freshened" itself before blocking.
Or the printing the reciept, where multiple threads were queued and ready to do formatting of the appropriate sections/fields...
---
On a 4,8,16 core machine (all currently available) these would (potentially) provide a benefit. But more importantly by controlling the number of threads processing specific types of work, the potential for blocking on a resource can be greatly reduced.
This approach is very much in keeping with Scott Meyers comment from the early 1990's of "Program in the Future Tense". The current approach to parallel computing seems much more to be "I dont need it now, so I will not worry about it till I do". IMPO, this will result in many software application being delivered TODAY that will not effectively make use TOMORROW's hardware without a complete system re-write.
CpuWiz..
I get exactly what your saying here..
After reading this thread i was looking at the project and found at least 7 other places where i posibly speed things up a little, by using multiple cores..
IE... Checking contents of previous mentioned Token ...
1) Open View Form.
2) Reset Treeview (used to show the 7 different groups of info stored on Token.)
3) Read info from Token
4) Parse and Load in to Treeview.
This could also use a pre-prep'd (blocked)thread to proccess #3, while #1 & 2 proccess in the main thread .. at which time in the main thread we wait for the token read to complete, and then do #4....
The Pre-Prep'd thread used in #3 would acctualy get alot of work, as 90% of the project relys on reading and writing these tokens..
Comming from a VB background, I never really worked with threading, and now with .NET a lot of doors have opened..
Unfortunatly with the very tight schedule that i'm sitting on, i dont have enough time to play with an idea, and see it all the way through to the end...
However i do plan to take the time when the project is done, to further study multi-coring my applications..
Did a project last week using Powershell 2.0 CTP. :thumb:
I had to rename a file if it existed, then copy over a 100MB+ sized file.
Every time I ran the script, I kept getting an error on the copy line, after the rename line.
I tried setting flags to hold it back, but it kept crashing, saying PROCESS IN US.
I woke up the next day, after thinking about it. PS must be using threads.
I searched the docs online, and found a -force parameter on the rename line.
It created the lock that I was trying to code the night before, and everything worked well.
My current project would be an ideal candidate for parallel processing across multiple cores. The project looks for similar objects in four areas of the image. The same code base is used for each area and therefore it should be possible to farm each one off to a core. Our spec is highly time constrained and this could be useful in extracting more processing time for each area from the system.
Unfortunately this is not going to happen until I get the chance remove all the 'static' variables the previous coder used in the analysis code. He had the habit of never to "Program in the Future Tense". :mad:
On the theme of synchronisation, we don't use any mutexes/critical sections in our code as this can lead to priority inversions which muck up the carefully crafted timing and thread priorities. We generally rely on a combination message passing, state machines and positional tracking (on the conveyor) to ensure non-concurrent read/writes to data.