Okay.. everyone seems to be getting shiny new computers with dual or quad core. Most allegro games are single core and not exactly taxing modern CPU's.

Nonetheless... one of my research projects may be to create a multi-core model for game programming. I can't say too much (not sure who's IP /what is involved) but the user of the library will certainly have to figure out dependencies between tasks and figure out what tasks in the first place. The library will handle the rest

As just a thing of curiosity.. how interested are you "hobbyists" in doing a little extra work needed to exploit multi-core? I figure a lot of you would rather not deal with the complexity and would probably rather just use simple stuff like parallel STL with parallel for loops.

How have you done your multi-core and what sort of library would you like??? Do you even care?

Most stuff I make isn't complex enough to tax one core, let alone 4.

The goal of my project is to never let a core sit idle. It is quite possible using parallel loops that one task simply takes longer than all others. Then you're left with 1 cpu busy and several idling. It is also possible that there are loops with only one or two items in them and they can be run separately from everyone else.

The primary goal is to keep all cpu's as busy as possible.

edit:

Timers Fixed in allegro5

Perhaps. I would argue that such tasks are rare, and when they do happen they can be internally parallelized themselves. I think regardless of the methodology used, if the types of tasks are constantly being changed the utilization of the cpu can only get so high... in the end the user will have to step in and alter the algorithms as needed.

Well if you put a rest() inside it will not eat up 100% of CPU time.

The question is what will be the performance gain on multi-core systems and what will be the performance loss on single core systems.

I am currently writting a multithreaded test that I will put there and in my a.cc members page.

We will see if there are any benefit or not.

EDIT:

Got it baby :-P

The test:
A simple loop with a cireclefill at mouse position
At each loop the program down the color for each pixel

How it works:
Label 1
The main loop post a semaphore for each computing thread
Each thread have a part of the screen to compute
The main loop wait for each thread to post back a semaphore
Goto 1

Results:
1 thread : 18 fps
2 thread : 35 fps

I must close some running apps for the result to be meaningfull. Source / binaries / screenshot will be uploaded after wash ;-) ( me , not the code ;-) )

EDIT:
If someone want to test ( binaries are windows only but it should be easy to compile)
ThreadProcessingSrc
ThreadProcessingWindowsBinaries

Run the program from a command line with the number of thread you want passed as first argument.

Example: t_blur.exe 1

test running:
{"name":"594430","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/a\/aa0f8a954224c267a5fb2b11c83c813b.jpg","w":800,"h":625,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/a\/aa0f8a954224c267a5fb2b11c83c813b"}

Hell, that was funny !

EDIT:

Benchmarking without having azureus downloading (still) unlicensed manga in background is better ;-)

Final Results:

1 thread , 19 to 21 Fps
2 thread , 38 to 40 Fps
3 thread , 38 to 40 Fps
...
I got the same result with 50 threads than with 2. There must be some little difference but I do not see it as I used the millisecond part of QueryPerformanceCounter.

For information, the test is running in 32 bit windowed directX mode, and my computer have a core 2 duo @ 2 Ghz, 2 G DDR2 , Geforce 8600 with 512 MB dedicated memory.

Could you develop that part, because it is working there

I was assuming that putpixel was acting as me doing line[ x + bmp -> h * y] = newcolor.

Perhaps it is really different when using video bitmap, but as I use memory bitmap, what's the heck ?

Don't be so harsh with yourself, Peter. It happens to work because I am lucky and I choosed memory bitmap without thinking at it.

The fact is that I saw the evidence ( memory vs video ) just after reading your previous post

Have a good day Peter, knowing that I am as crappy as you before drinking my morning coffee, it can not be something else than a good day ;-)

EDIT:
I played with the proggy some few hours, and now I have just achieved a software blur (only looking at the four direction around a point).

With 1 thread it is running at:
8 Fps in DirectX Fullscreen 1280x800x32
17 Fps in DirectX Fullscreen 800x600x32
28 Fps in DirectX Fullscreen 640x480x32
119 Fps in DirectX Fullscreen 320x200x32

With 2 thread it is running at:
16 Fps in DirectX Fullscreen 1280x800x32
34 Fps in DirectX Fullscreen 800x600x32
53 Fps in DirectX Fullscreen 640x480x32
201 Fps in DirectX Fullscreen 320x200x32

Rey Brujo was there last evening to make some test, but as he have an old computer, there was no nice result except the fact that the thing was working on his single core processor.

I am thinking of collision management processed the way I did with pixel per pixel effect. If I have enough time under my hands, I will try something.

Edit: Could not resist to post the 320 x 200 shot ;-)
http://www.allegro.cc/files/attachment/594440

I don't think there will be a silver bullet to add parallelism to games same way there is none for programs.

you get a lot of speed out of just parallelizing loops using standard worker threads. plenty of languages can do this more or less automatically for you. common loop structures likewise, mapreduce is one such example. Haskell+extensions can automatically parallelize it (mapreduce is taken from functional programming, time to upgrade guys?).

the problem today isn't parallelizing, the problem is debugging and reasoning about it. this is why if you need really heavy threading then you go for a language meant for it, such as erlang. these also tend to scale better.

Make a Mandelbrot set generator where each core does pixel modulo x, like if you have two cores, one core does the even x pixels, and the other does the odd x pixels. Well, since we have SSE now, have one core doing four pixels at once in even rows, and the other the odd rows.

My understanding is that GPU's do one thing to many pixels.. kinda like SIMD on steroids.

Well, personally, I think that only a fanatic would want to truly tax their CPU with their own programming. Personally I'd want to get as much out of my CPU while using as little of its resources as possible, so unless there's some way using multi-core in an Allegro-made game would enhance gameplay, compatibility, or efficiency, I'd have to go against it.

I'd say switching to OpenGL will give you a dozen times better and faster results, and isn't nearly as difficult as using a multi-processor environment efficiently.