WTF? I can't tell if this is spam or needs moved or closed.

 

WTF? I can't tell if this is spam or needs moved or closed.

lol.......

 

http://forums.ngemu.com/pcsx2-official-forum/113815-pcsx2-ps2-power-question.html
READ

 

I cant wait for i7's, and to see what kind of speed improvements QuickPath gives.

It will do pretty much nothing for PCSX2 because PCSX2 doesn't really gain much from reduced memory latency and increased memory bandwidth, also AMD CPUs have had the equivalent to "QuickPath" for ~4 years, and are slower in PCSX2. Nehalem @ 3ghz will perform a bit better than a 3ghz E8400 in PCSX2 but don't expect a big difference, and it will be much slower than a E8400 @ 4.0-4.5ghz for sure.

From reviews so far, Nehalem heat is too high to overclock much beyond 3.8ghz without too high of temperatures, hardocp even reported 80'c temps under water cooling @ 3.8ghz, where as E0 revision E8x00 chips can handle ~4.2-4.5ghz with moderate air cooling.

Chances are i7 will actually be worse for PCSX2 than a core 2 duo, when both are overclocked.

 

I've really liked what Intel has done with the Core 2 line, and I cant wait for i7's, and to see what kind of speed improvements QuickPath gives. Should be a fun future for Hardware! (and with Windows 7 coming out (of which build 6801 has been really fun to play with) a fun future for software as well!).

What are other peoples thoughts?
(thoughts on the i7, its effect on emulation, QuickPath, or hell, even Windows 7)

So far, its still optimized for 2 cores in particular (AFAIK). Use of ht and addtiional cores could benefit, but not the the point that it'd be as significant as you expect (unless optmized by the pcsx2 team, and coding for multiple -higher than 2- cores isnt all that easy)

 

Getting that kindof implementation would require a hell of alot of work. Hell, just getting quad core support in there would be alot of work, let alone that AND hyperthreading. Very unlikely to see it anytime in the foreseeable future if at all.

 

If I remember right, ref said the biggest problem with multiple cores is keeping it all syncronized. Right now the only thing that runs on the second core is the graphics plugin because most of it can be done asyncronously, the other components that are expensive to emulate (VU units) are very tightly coupled to the other processors. You'd very likely waste so much time trying to keep it all emulated correctly that you'd end up hurting performance, not helping.

You'd be passing semaphores around like crazy trying to make sure every core is on the same page and executing the right code. If one of them gets out of synch the whole thing comes crashing down.
So to answer your question, yes they have though of it. But it's really friggin hard to code something as complicated as an emulator to properly run on multi-core setups, and it's asking a lot of the devs who are doing this in their spare time.

 

WTF? I can't tell if this is spam or needs moved or closed.

What? How is it spam... Im talking about perfectly on topic subjects... kinda...

http://forums.ngemu.com/pcsx2-official-forum/113815-pcsx2-ps2-power-question.html
READ

I read that, thats actually what made me want to start this topic. I knew about that, but this is different, this is looking to the future, wondering what can be done with the newer hardware thats about to come out. I know whats involved already.... doesn't answer my question of what happens when there is access to that much power...

It will do pretty much nothing for PCSX2 because PCSX2 doesn't really gain much from reduced memory latency and increased memory bandwidth, also AMD CPUs have had the equivalent to "QuickPath" for ~4 years, and are slower in PCSX2.

When I mentioned QuickPath I meant more just in general the applied to PCSX2. Im just hopping that QP gets done a bit better then HyperTransport...

If I remember right, ref said the biggest problem with multiple cores is keeping it all syncronized. Right now the only thing that runs on the second core is the graphics plugin because most of it can be done asyncronously, the other components that are expensive to emulate (VU units) are very tightly coupled to the other processors. You'd very likely waste so much time trying to keep it all emulated correctly that you'd end up hurting performance, not helping.

You'd be passing semaphores around like crazy trying to make sure every core is on the same page and executing the right code. If one of them gets out of synch the whole thing comes crashing down.
So to answer your question, yes they have though of it. But it's really friggin hard to code something as complicated as an emulator to properly run on multi-core setups, and it's asking a lot of the devs who are doing this in their spare time.

Hmm your right (and your right, the devs have done amazing things with this to this point).
But just, theoretically speaking (this is speculation, remember. This hole topic is meant to be what COULD be) if they had built a specific version mean to take advantage of the power, of being able to do that many things at once... well.. hmm.
Have each core doing one task that each of the PlayStation's processor would usually have done. then have another core (separate entirely) running just constant checks to make sure everything is syncing up, and if its not to correct it. Im aware that it would be stupidly hard to code, but it is possible correct? And something like this would be more efficient in all, then trying to do it all on one (or even two cores) I would think.
The basic idea Im getting at here is: Splitting the job up into smaller sections, and having each core emulate each section, while having a separate core set to run constant checks to make sure the others are in sync, do people think that is possible?
Also, would something like that work better, then having the same possessor just trying to emulate everything at once, with all the information being passed to the processor one bit at a time.
And all that... ignoring the difficulty involved in coding it (once again, yes Im aware of how hard it would be to code something like that, or even what its taken to get this far, and (twice already) I've said how much I respect the devs for what they have done this far. But Im not asking how to code... how much work it takes to code.. Im talking about the future of hardware and what impacts it will have on a project like this. Im also aware that hardware and software go hand in hand for something like this... but still)
So?

 

Have each core doing one task that each of the PlayStation's processor would usually have done. then have another core (separate entirely) running just constant checks to make sure everything is syncing up, and if its not to correct it. Im aware that it would be stupidly hard to code, but it is possible correct? And something like this would be more efficient in all, then trying to do it all on one (or even two cores) I would think.
The basic idea Im getting at here is: Splitting the job up into smaller sections, and having each core emulate each section, while having a separate core set to run constant checks to make sure the others are in sync, do people think that is possible?

Keeping all of the cores in synch is an extrememly expensive operation, and this added overhead may very likely balance out any performance increase you would see by using multiple cores.
Even if all the checks are done by another core, it still has to stop all the other cores to do the check. I don't even know how this could be done, and the performance penalties of this is huge.

Coding it to run on multiple cores isn't very difficult. Coding it so that 3 cores don't sit idle while the 4th does all the work is significantly harder. Coding it so that it runs at full-speed is, as you put it, stupidly hard.

 

Your thinking way too ahead. Current C2D speeds (2.6-4ghz+) are already sufficient, it is simply the code that needs some further development, meaning it would be better to spend time optimizing for dual cores than it would to simply re-write and rely on more beefy hardware to get the job done. This would also allow people who don't have the cash for a 500$ processor to use pcsx2 (there's already enough threads in the forums where people with P4s whine about speed issues).

As you said yourself, the devs have done an excellent job thus far, and the majority of mainstream titles run just as smooth as on a PS2, which just shows how its now simply down to optimizing the code rather than waiting for better hardware. Sure extra speed would benefit, but almost all the speed issues and whatnot can be fixed in the coding. Take Kingdom Hearts 2 for example, the game runs smooth as lube on my 3ghz Core2 with 16x AA and all the other frills, but slows down occasionally to slideshow speeds due to a rendering issue in the VU rec (correct me if I'm wrong); to fix this, sure I could wait for PC hardware to reach insane speeds which will give my gfx card frame-diarrhea trying to keep up with the triple digit fps, but it would be much more efficient time wise and resource wise to just optimize the code for the hardware which the majority of us have now (dual cores) that are perfectly capable of doing the job, rather than praying that Intel or AMD yields an uber processor within this decade and then spend time re writing to take advantage of it. This is all assuming that multi-threading the emulator is in fact easy, which it is not.

On a side-note, very few people will be using Nehalem in the foreseeable future (new socket type AFAIK, meaning not many people will be upgrading, unless its one of the few that have been waiting on its release to rebuild), so revamping the entire project just for the rare few who do would be a waste as most users using the emu already have a modern C2D or AMD X2 and would be unlikely to upgrade soon. Most people won't see the incentive in upgrading either way, since overclocking is a much less expensive option, and with things like CUDA and CTM being developed, even graphical applications won't need the CPU boost.

 

Your thinking way too ahead. Current C2D speeds (2.6-4ghz+) are already sufficient, it is simply the code that needs some further development, meaning it would be better to spend time optimizing for dual cores than it would to simply re-write and rely on more beefy hardware to get the job done. This would also allow people who don't have the cash for a 500$ processor to use pcsx2 (there's already enough threads in the forums where people with P4s whine about speed issues).

As you said yourself, the devs have done an excellent job thus far, and the majority of mainstream titles run just as smooth as on a PS2, which just shows how its now simply down to optimizing the code rather than waiting for better hardware. Sure extra speed would benefit, but almost all the speed issues and whatnot can be fixed in the coding. Take Kingdom Hearts 2 for example, the game runs smooth as lube on my 3ghz Core2 with 16x AA and all the other frills, but slows down occasionally to slideshow speeds due to a rendering issue in the VU rec (correct me if I'm wrong); to fix this, sure I could wait for PC hardware to reach insane speeds which will give my gfx card frame-diarrhea trying to keep up with the triple digit fps, but it would be much more efficient time wise and resource wise to just optimize the code for the hardware which the majority of us have now (dual cores) that are perfectly capable of doing the job, rather than praying that Intel or AMD yields an uber processor within this decade and then spend time re writing to take advantage of it. This is all assuming that multi-threading the emulator is in fact easy, which it is not.

On a side-note, very few people will be using Nehalem in the foreseeable future (new socket type AFAIK, meaning not many people will be upgrading, unless its one of the few that have been waiting on its release to rebuild), so revamping the entire project just for the rare few who do would be a waste as most users using the emu already have a modern C2D or AMD X2 and would be unlikely to upgrade soon. Most people won't see the incentive in upgrading either way, since overclocking is a much less expensive option, and with things like CUDA and CTM being developed, even graphical applications won't need the CPU boost.

Hmmm, Im going to have to agree with pretty much everything there. Thats pretty much what I was looking for from this topic I guess.
And yeah, the i7's will be using a new socket, and new Mobo type in general (thanks to QuickPath).
Well, as long as the Dev's keep going on the track there on now, I suppose there's no need to bother with the future, as Im sure everything will end up good in the end.
So, to all the PCSX2 devs out there: Keep up the amazing work!

 

Hmmm, Im going to have to agree with pretty much everything there. Thats pretty much what I was looking for from this topic I guess.
And yeah, the i7's will be using a new socket, and new Mobo type in general (thanks to QuickPath).
Well, as long as the Dev's keep going on the track there on now, I suppose there's no need to bother with the future, as Im sure everything will end up good in the end.
So, to all the PCSX2 devs out there: Keep up the amazing work!

Maybe in a decade or so there will be a PCSX3 project? who knows. The PS2 emulator is going reasonably fast considering the PS1 emulators are still being polished.

I'm curious as to what direction Intel/AMD will take once the thereotical manufacturing limit of 32nm is reached though. Though IMHO, the other hardware bits need to be developed faster. Perhaps a more dynamic/multimedia approach in PC architecture would be better, since how many people buy a PC for word processing these days? But then, i guess that's why the XBOX360 and PS3 was made xD.

 

PCSX2 could benefit from a tech that speeds up the synching of threads among cores.

 

...Nehalem @ 3ghz will perform a bit better than a 3ghz E8400 in PCSX2 but don't expect a big difference, and it will be much slower than a E8400 @ 4.0-4.5ghz for sure.

From reviews so far, Nehalem heat is too high to overclock much beyond 3.8ghz without too high of temperatures, hardocp even reported 80'c temps under water cooling @ 3.8ghz, where as E0 revision E8x00 chips can handle ~4.2-4.5ghz with moderate air cooling.

Chances are i7 will actually be worse for PCSX2 than a core 2 duo, when both are overclocked...

Wow, speak of the devil of obviousness... Of course a 4+ghz overclocked C2D would beat a stock Core i7 CPUs :doh:

Also Hardocp tested the Core i7 at 3.80Ghz with the stock intel cooler (worst cpu cooler for overclocking) and that one failed/gave error

 

Wow, speak of the devil of obviousness... Of course a 4+ghz overclocked C2D would beat a stock Core i7 CPUs :doh:

Also Hardocp tested the Core i7 at 3.80Ghz with the stock intel cooler (worst cpu cooler for overclocking) and that one failed/gave error

The point was to show that i7 won't create any miracles in PCSX2 and is basically going to perform about as what we already have access to, and possibly worse.

Yes in the hardocp review Nehalem failed on the stock cooler, but it was also a very hot 83'c on the thermalright cooler (which is generally regarded as one of the best air cooling solutions available), and 80'c on their water cooling unit. It hints that much more than 3.8ghz isn't going to be very viable and it will likely end up slower in PCSX2 than an overclocked E8x00 E0.

 

No point in buying E8xx if your planning to keep it overclocked at above 4ghz for 24/7 usage, much better to spend money on a decent 65nm chip. From what the hardware enthusiast forums show, electron migration is a major wolfdale killer when a high overclock is left for a few months. Specially for those optimists who ignore the 1.325v limit on the packaging and refer to the supposed 1.45v on some remote Intel online spec sheet instead.

Sure people will always point to the articles that proclaim a 4ghz on stock volts, but the only reason those are outnumbering the complaints are because nobody enjoys posting articles about how they fried a 100$ chip due to their own incompetence.

But then, I've only had a play with the C0 revision myself, so maybe Intel fixed the boo boos in E0.

...Nehalem @ 3ghz will perform a bit better than a 3ghz E8400 in PCSX2 but don't expect a big difference, and it will be much slower than a E8400 @ 4.0-4.5ghz for sure.

I was sure there was a comparison between a 2.8ghz i7 engineering sample and a E8500 floating around somewhere a while ago, and the i7 actually performed 20% faster (would definitely be noticeable when encoding or doing photoshop/gaming work ). So theoretically, you would only need to OC a i7 400mhz or so to be on par with a OCed wolfdale. Besides that though, the initial price of Nehalem CPUs will be insane since AMD isn't bringing out any competition, so E7 and E8 will still be mainstream for quite a while.

 

I was sure there was a comparison between a 2.8ghz i7 engineering sample and a E8500 floating around somewhere a while ago, and the i7 actually performed 20% faster (would definitely be noticeable when encoding or doing photoshop/gaming work ). So theoretically, you would only need to OC a i7 400mhz or so to be on par with a OCed wolfdale.

I wasn't saying Wolfdale is equivalent in performance with Nehalem in other tasks, I know it's much faster in pretty much everything, just not so much PCSX2 because it's actual architecture performance benefits over Wolfdale have shown to not effect PCSX2 performance at all in previous benchmarks in PCSX2. The raw computational power is what matters in PCSX2, not memory access latency and bandwidth.


Also Intel's spec sheets say 1.4v+ greatly decreases lifespan for wolfdales, they don't say it's acceptable. They list 1.3625v as the highest acceptable voltage for normal lifespan, which for the majority of chips is enough to hit ~4ghz (mine is a C0, sitting at 4080mhz with 1.35v 100% stable). E0 wolfdales overclock better (~200-300mhz more) with less voltage requirement, but also have increase cache latency, so in typical performance it's slightly slower clock for clock compared to C0, but higher clockrate makes up for it.

 

The point was to show that i7 won't create any miracles in PCSX2 and is basically going to perform about as what we already have access to, and possibly worse.

Yes in the hardocp review Nehalem failed on the stock cooler, but it was also a very hot 83'c on the thermalright cooler (which is generally regarded as one of the best air cooling solutions available), and 80'c on their water cooling unit. It hints that much more than 3.8ghz isn't going to be very viable and it will likely end up slower in PCSX2 than an overclocked E8x00 E0.

Cpu stress testing programs are usually a lot more hotter that running an application that utilize all the core. The average temperature when using all the core I got was around +10 degrees celsius more, and in total that under 60 C. The author also mentioned that the pc ran for days and it was stable even at 80 C.

 

What are other peoples thoughts?
(thoughts on the i7, its effect on emulation, QuickPath, or hell, even Windows 7)

Its quite tough to make the emulator take advantage of hyper threading....ref would get mad if that is planned to be implemented

 

Maybe Core i7 will bring chances for the Playstation 3's emulator.

 

wat.....we have finished ps2 emulation already and then ur thinking of ps3 emulation

 

I will say by the time Playstation 3's emulator project begins the 1º generation of core i7 will be long dead, with grave inscription "Rest in Pieces". Maybe what will help, will be Windows 7 that will have a much smaller Kernel that will make it lighter OS.

 

tldr;

Anyway, Core i7 does help with PCSX2 moreso than Core 2, but at which part... I don't think that's significant for the general public.

 

Code doesn't need to be written to support hyperthreading. It is transparent to the program (except for the OS's CPU scheduler, so it won't put two threads on the same physical core and leave the other core idle). Coding for hyperthreading is the same as for general multithreading (multi-core or even multi-CPU, except there will probably be NUMA issues involved for multi-CPU and I'm not sure if the application has control over that).