Jump to content
  • Advertisement
Sign in to follow this  
vesoljc

multi cpu emulator

This topic is 5409 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

is there such a thing? so that it could emulate more cpu units (naturally slower) from one? like, a Ghz machine could emulate a 4way 100mhz system. it seems kinda logical that the emulated cpus would be the same architecture as the one running the emualtor. ohh, i do hope that in case this topic is not in the right spot, mods will fix it ;)

Share this post


Link to post
Share on other sites
Advertisement
no b/c multiple CPUs means _parallel_ processing. you can't parallel process on a single threaded CPU. a multi-tasking operating system like windows/linix/macOS is as close as you can get. they handle multi-threading by timeslicing the CPU between active threads, but they can't actually run 2 threads at exactly the same time. a processor only has a limited number of shall we say input streams on any single thread CPU only one thread can own those inputs at any given time. the new "hyper-threaded" CPUs allow multiple threads to own the inputs thus effectively makin the CPU into 2 CPUs.

-me

Share this post


Link to post
Share on other sites
Wouldn't a multithreaded app behave the same on both a single and dual-CPU system, excepting that on the parallel setup it will run considerably faster?

Aren't parallel-processor programs in essence multithreaded apps?
Ah! Sometimes I hate using a very-high-level language... [crying]

Share this post


Link to post
Share on other sites
Quote:
Original post by Mushu
Wouldn't a multithreaded app behave the same on both a single and dual-CPU system, excepting that on the parallel setup it will run considerably faster?


no because only one thread is ever active at any given instance in a single processor setup. on a multi-processor setup multiple threads are actually executing code at exactly the same time. it is possible to have a stable multi-threaded app on a single processor that will die on a multi-CPU setup because of this.

Quote:
Original post by Mushu
Aren't parallel-processor programs in essence multithreaded apps?
Ah! Sometimes I hate using a very-high-level language... [crying]


yes, they are multithreaded apps otherwise they would only run on one CPU.

-me

Share this post


Link to post
Share on other sites
While it's true that you can never actually process instructions for all 4 processors at once, emulating a system that involves more than one processor can work, and it has been implemented for many systems. All you need is the information on how long it takes each instruction to execute, on all the processors involved. You then do a timesharing thing, where you do a few cycles on one processor, then switch to another and do a few cycles there, than another, etc. This is of course a lot slower than just emulating one processor, because you have to respect all tbese timings, or else the system might fall down in a smoldering heap, and you have to switch back and forth all the time. If the two processors rely on each other heavily, it can be a nightmare to manage, but it's possible. The Sega Saturn is a good example of a dual-processor system that has been emulated (all be it badly so far).

Share this post


Link to post
Share on other sites
so called paralell execution can still be faked, the "only" trouble i see, is when two or more threads actually do something together. and even then these operations could be prolonged, so that "main" cpu has time to process everything. or not?

Share this post


Link to post
Share on other sites
That's what the timesharing thing fixes. If you have two processes running on two different chips, but they never actually interact, you don't have to worry about managing the timing at all, because even if they run totally out of sync, they'll never affect each other. All the complecations arize when the two threads as they were rely on each other, and the fix for that is literally going back and forth between the chips, cycle for cycle if needs be. If you're about to execute an instruction that takes 16 cycles on one chipset, you go to the other chipset and execute 16 cycles worth of instructions on it, then switch back and do that instruction. You then check the next instruction, and so on. You can keep the chips in perfect sync, but you incur a very significant overhead for doing so.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!