No

Actually I just posted in another thread as I've been messin' with DOSBOX using VC++ 9.0 Professional Edition (and will probably toy with VS 2010 next week sometime) or Watcom C++.

I was just saying the same thing... Be pretty cool to use Multiple Core's at least isolating video I/O to one core essentially making one core be the video card emulator. Really depends on DosBox's architecture as to how painful it might be to make into a reality and I have not explored much of DOSBox's code at this point in time. With a Tri/Quad Core CPU again depending on the software architecture things could get really interesting (and possibly nasty!) having for example one core deal with nothing but CPU emulation, another with Video and sound while a third deal with the arbitration or "glue" / Bios emulation etc. If I had to "guess" probably end up being faster than the machines of the day at least on a "blank box"... aka a computer where the cores are not already in use by other processes... There are not heaps of applications out that use multiple cores and how Vista / Win 7 utilize cores is fairly minimal and quite undocumented in many regards.

However, what is rather known is things are not going to stay that way. Part of the "future purpose" of multiple cores is to arbitrate / segment what a "computer is". That is to say the plans are and have been in place for years to have a merging of digital technologies... So we can be computing while out "Home information center" is feeding TV's, on and on and on by utilizing unified I/O mechanisms, shared assets (drives, ram etc) and multi-cores / core arbitration.

One of the interesting facets of the multiple core debacle is Manufacturer's of the processors thought developers would jump all over the new possibilities (Parallel processing for example). In military, science, server based application they have but for the commercial consumer industry it's not really happened. Many reasons. Game industry for PC's used to drive alot of new development techniques and development houses are focused on revenues not innovation. Revenues mean they need cater to the X-Box, PS/3 to assure revenues .vs. the PC. The PC is essentially Third (even fourth) in line when considering revenues or "second" in the case of games created for say X-Box 360 / PC.

So much of gaming builds are done through third party or in house scripting engines its not like it used to be so the thought of multi-core development innovation in the game industry is near nil.

Be pretty cool to use Multiple Core's at least isolating video I/O to one core essentially making one core be the video card emulator. Really depends on DosBox's architecture as to how painful it might be to make into a reality and I have not explored much of DOSBox's code at this point in time.

This seems dubious since the original DOS architecture was single-threaded, and allowed arbitrary access to the video hardware. In other words there is nothing to stage or defer, at any point any piece of code executing can manipulate the frame buffer. And actually displaying the framebuffer on pretty much any modern machine isn't time consuming.

having for example one core deal with nothing but CPU emulation, another with Video and sound while a third deal with the arbitration or "glue" / Bios emulation etc.

You would be stalled constantly on all threads, because you can't safely make an assumption that any other thread won't affect your input data set. You can't take a single threaded execution model and just slice it up.

evenues mean they need cater to the X-Box, PS/3 to assure revenues .vs. the PC. The PC is essentially Third (even fourth) in line when considering revenues or "second" in the case of games created for say X-Box 360 / PC.

Both the Xbox and PS3 are highly threaded architectures btw. Code on them is typically very threaded unless the game simply doesn't need much performance.

-Frob

Will we need a corecatcher?!

Multi-core support would be pretty useful for Voodoo emulation, but I can't really think of anything else that it would be of much use for.

would be pretty useful for Voodoo emulation

It would be pretty useful for solving the world peace problem as well.

Quote:
Be pretty cool to use Multiple Core's at least isolating video I/O to one core essentially making one core be the video card emulator. Really depends on DosBox's architecture as to how painful it might be to make into a reality and I have not explored much of DOSBox's code at this point in time.

This seems dubious since the original DOS architecture was single-threaded, and allowed arbitrary access to the video hardware. In other words there is nothing to stage or defer, at any point any piece of code executing can manipulate the frame buffer. And actually displaying the framebuffer on pretty much any modern machine isn't time consuming.

True enough. As I noted, I have not looked at any DOSBOX code at all so I have no idea how DB handles video. I can however see where your statement of being stalled on threads would be common. I know DB uses SDL and again, have'nt looked at a lick of it either as far as source code goes.

Quote:
Revenues mean they need cater to the X-Box, PS/3 to assure revenues .vs. the PC. The PC is essentially Third (even fourth) in line when considering revenues or "second" in the case of games created for say X-Box 360 / PC.

Both the Xbox and PS3 are highly threaded architectures btw. Code on them is typically very threaded unless the game simply doesn't need much performance.

Absolutely, but... the standard code model for the consoles is highly tethered to the fixed architecture of the boxes. It favors that type of platform so as developers / development houses use/create/modify scripting engines for a more RAD environment in creating the games.

On PC's hardware evolution in video marches on as it does with CPU's etc. The game industry used to be the driving factor in PC's towards innovation especially. This has waned as Publishers revenues get focused more unto the consoles. It has in fact become so bad over the last 10 years that Walmart for example can dictate to publishers what acceptable and not for their shelves in packaging etc. Large boxed games went away due almost singularly due to Walmart "We wont carry the stuff it takes up too much floor space .vs. revenues that space should deliver".

Point all being, the only entities in the console markets that are providing "innovation" of code / platform tend to be universities using them for things they were never intended to be used for.

In the PC market, multiple cores are utilized by server technologies, scientific applications and quite a bit of vertical market .vs. commercial consumer market applications. Rendering solutions, manufacturing, scientific etc. Not so much by gaming which used to be the innovator.

While there are still avid PC gamers that exist it is a market on the wane and probably be doa within a few years of the next wave of consoles.

This is sad.

Games I like to play challenge me and the stuff just isnt found on consoles. Good Flight Sims, Silent Hunter, Strategy Games etc. Certainly the consoles are capable of running many such applications but they now sit vertical market. Yet, some things do quite well... If I were a Nancy Drew fan I'd be set for life 😀

I have looked into the issue, since it seems to come up occasionally. I used a game for this which is rather cpu-intensive to emulate. It is Archimedian Dynasty. I put the taskmanager beside the DOSBOX window to watch both of them.

Okay, i know. DOSBOX does only use one core. If that is so, then someone please tell me why does it have 12 threads? It always runs 12 threads. Nothing one changes in dosbox.conf could change that. The multicore load balancer of windows will distribute the load quite evenly as i have noticed. And rightly so. Distributing load means distributing threads between the cores. Does anyone please know what each of the threads does? One thread for the emulated CPU, one for the video card and so on... ?

All emulated devices have to run in parallelism for games to not run very choppy. Thus several threads are needed. Even on a single core. Or would you say otherwise? And yes, i know true DOS cannot run on multiple cores. Very possible that a game itself does use one of the threads. It has to. So it seems the other threads are used for the emulated devices.

I also noticed, the discussion seems to run rather theoretically in all threads on the forum regarding multithreading. Some wish DOSBOX to use multiple cores. But it does! Nothing bad about that, actually. Others say it doesn't. No threats made. I only say i have tried it and i have seen it.

Okay.

But please view these screenshots.

The dosbox main thread does all the work. The other threads are some auxiliary threads created by DirectSound etc. Also, multiple threads doesn't automatically mean parallel execution. If the threads access shared resources protected from concurrent access often, the threads will be waiting for access to that resource instead of doing useful work. Also, the operating system scheduler can distribute a single thread over multiple cores - but you will get an average 50% utilization of each core, which can be seen from your picture.

Thanks for the clear answer. How did you get the dosbox properties? Very interesting.

So the main thread does all the work. Does a thread cause any load at all by simply waiting for access to shared resources?

Also, multiple threads doesn't automatically mean parallel execution.

I could almost have guessed it, but didn't know that for sure.

Also, the operating system scheduler can distribute a single thread over multiple cores

How does it work?

Then why do archivers like 7-zip and winrar have a checkbox for multithreading?

What ripa probably meant to say is that a single thread can "jump" from one core to another, depending on where the scheduler puts it. Since the timeslices are way too short (10ms) to be able to see this in realtime, you can only observe that each core is used roughly half the time. But that still means that only 1 thread is doing most of the work and things are not running in parallel (or the cpu usage would be >1/no_of_cores).
Some of the stuff is threaded. Most notably, SDL runs the mixer in it's own thread, probably some timer runs in it's own thread as well. But these don't do much work.
There are some things that try to be threaded...the mt32 unofficial patch tries to thread the processing, also my direct3d output is threaded.

Is it possible to utilize all cores thoroughly by jumping the thread between them? How well does this work?

But then, having four cores doesn't mean 4-fold performance. Has it improved with todays cpus?

Is it possible to utilize all cores thoroughly by jumping the thread between them?

Please stop posting crap like this. Especially posting pictures about Multithreading-checkboxes from other applications.

What good would it do to jump cores? Since it wouldn't use the cores in parallel there is nothing to gain

Thread closed

Search the forums for similar threads.