| |
Dano
Registered: Jul 2004
Posts: 231 |
WinVice 3.1 speed/performance on Ultrabooks?
Currently i am coding on an Asus UX32VD Ultrabook (which should have some like an Intel Core i7-3517U 1.9 GHz in it). As of WinVice3.1 using x64 with FastSid does not work correctly anymore. Visuals yes, but Sound sometimes totally goes south (no filters and such).
From the Vice people i was told to use ReSid as FastSid is not supported anymore.
Now my problems start: With using ReSid WinVice drops to like 24fps on my system. Using x64sc with Resid gives me like 8fps.
Looking at procmon it seems like one core is maxed out as CPU load never goes over 24% (the graphs show a different picture as none seems to be properly used).
My workhorse laptop at the office can run x64+resid nicely and properly, but okay it got way more power than my ultrabook will have.
Somehow i got the feeling that my system (Win10 Creators) is not really working properly anymore.
That's why i am asking here.. Any of you guys got a laptop compareable to mine and how's WinVice working on your system? Or what are the general performance reports for WinVice3.1?
Before i go into the ordeal of doing a complete re-install i would like to hear what other experience with WinVice currently. If it's problem on my side, or if it's just how well WinVice works on lower spec (sort of) laptops.. |
|
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
On my surface pro, my Dual Core i5 and Vice 3 and reSID are a no go...
Try Game Mode on it. Your ultra book could be hitting thermals? |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
it is what it is. = slow.
maybe try to go back to earlier vice versions. |
| |
Trash
Registered: Jan 2002
Posts: 122 |
With my lenovo (16gb ram, Core i5 Skylake) Win 10 creators everything is works fine with 3.1 and resid. However on my stationary i7 skylake and 64gb ram I experience similar problems as you... |
| |
Dano
Registered: Jul 2004
Posts: 231 |
Thought about thermals, but it seems to clear of that.
Just Firefox with some 12 Tabs makes then fan go on.. ^^
Thought about going back aswell, but honestly i would rather prefer accurate emulation. Interestingly enough fps stay up as much as possible when there's not much happening on the screen. With some action fps drop down low..
Else i must disable sound for dev'ing until i get some decent laptop again. ^^ |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
putting ReSid on its own thread would really help too.
Somebody in VICE dev suggested we need a GPU based version. |
| |
soci
Registered: Sep 2003
Posts: 479 |
It is just getting more easily maintainable and correct now.
Once for 2.4 I cared a little to optimize speed, memory use and start-up time. There was some strange fun to try running it on old junk and see how it could perform better.
Then the direction changed. Old hardware and platform support is planned to be removed and X64 will be phased out in favour of the SC version. A lot of stuff I did will be stripped out as a clean-up. You know, there's no need for a redundant "fast paths" if the normal path handles the same case just as well just slower. Well I've added a lot of "crap" in name of performance which hinders maintainability in the long run.
Therefore worrying over it's performance is a complete waste of time. I've found better things to do and there's no turning back. Anyone can join to try to improve it, but I can tell it's going to be an uphill battle of conflicting interests.
On the other hand improving maintainability is good. I'm just wondering how the gained flexibility will be used for something in the future. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
what soci said - if you want performance, use x64 from VICE 2.4, enable fastsid, disable CRT emulation -> problem solved.
"putting ReSid on its own thread would really help too."
no it wouldnt. ReSID is being synced to the emulation every half cycle - putting it in a seperate thread would not only a lot of ugly code to maintain just that - the overhead would also make it slower in the end. there is not much that can be parallelized in a cycle exact emulator, unfortunately.
the one thing that could be done to speed up emulation considerably would be doing GLSL based CRT emulation (like micro64 does). however, there is tons of other stuff to be done under the hood (ie what soci said) before any of this will happen. |
| |
Dano
Registered: Jul 2004
Posts: 231 |
kudos for all the efforts in x64sc as it really looks neat and tidy and correct to my eye.
got a lenovo t540p here which perfoms well with it. not sure on how much power MORE this one has. internet says it got a Intel Core i7 4700MQ.
brings me back to my question on if x64(sc) from winvice 3(.1) should run on my i7 ultrabook at a 50fps or if there's something else on my system that must cause that slowdown. well i'm no n00b and i don't see anything particular that could cause the slowdown, but it might be there if others confirm to have it running normally on their (equal) systems.
so, to me, it would interesting on what power is/may be needed to drive x64 and x64sc with resid at a constant 50fps. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
a lot with the inability to run at stable 50fps is due to the terrible sound- and sync- code that needs to be deleted and rewritten.
IMHO any i5/i7 should be able to do it fine. my good old amd64 could do it even (ok, with 2.4) :) |
| |
algorithm
Registered: May 2002
Posts: 705 |
Any i3/i5/i7 device with the exception of perhaps a first generation ULV device (e.g i5 520um) should run Vice 3.1 x64sc at full framerate. Even on an Atom Cherrytrail z8700 (GPD Win) it runs fine. 50fps (or near enough)
The I5 3317u (On your device) is enough for vice 3.1 although there has been some severe throttling on some devices
I would probably check the settings in power options. make sure processor max performance is not set to 99% (This will disable turboboost). With adequate cooling, turboboost speeds should hopefully be maintained longer. |
| |
soci
Registered: Sep 2003
Posts: 479 |
As Groepaz said you need to trade off accuracy for performance.
The performance hit is mostly due to default settings changes for 3.0 which were done with the intention of exposing the more accurate emulation features over "half assed" but faster versions.
The point was that it's not possible to optimize for everyone, but at least the defaults should be something "sensible".
Which does not mean it fits exactly your use case or hardware out of the box. It's needs to be tuned.
For coding CRT emulation is counter productive anyway, I switch it off.
Sound I never turn on unless it's needed. Same with true drive emulation, most of the time device traps will do.
When coding mostly calculation heavy effects without tricky timing there's no point running it on X64SC.
If VICE was compiled with memory map or debugging it's going to be slow, so I only use it when really needed for something.
3.x got a little heavier independent of settings, but it's not all that bad yet as it seems. |
| |
Kruthers
Registered: Jul 2016
Posts: 21 |
Seems most of the hardware mentioned here should not really be an issue as my 6 year old Athlon II can run the latest Vice, maxed out, solid frame rate, without even using up one core.
However I notice that sometimes Vice gets in a "state" where framerate really drops, as low as 5fps, and it gets stuck there. Sometimes it happens on startup but mostly its random or possibly related to system load. Anyway, doing pause (alt-p), waiting a few seconds for the system to settle, then unpausing seems to clear it up.
Maybe on some systems Vice starts up in that "stuck" state and needs a chance to catch its breath? *shrug* Course, I'm seeing this behavior under Linux and there could be a world of differences, but figured it was worth mentioning anyway... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
Quote:the terrible sound- and sync- code that needs to be deleted and rewritten. |
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
2.4 is superior to 3.1 when it comes to linking a demo.
* In 3.1 warp mode can only be turned on after 4-5 seconds while booting up (makes it really booring when linking demos and you want to prototype stuff on disk quickly).
* Warpmode doesnt seem to work while the c-64 i/o is busy
* Warpmode is alot slower compared to 2.4
* There seem to be a random startup delay even tho i have the "random startup delay" turned off. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
all of this can be reverted by changing the settings to the defaults 2.4 used (while loosing precision of course) |
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
groepaz, trust me i tried :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
everyone is free to believe whatever he wants, of course. (-warp on commandline actually works, for example. no need to wait whatsoever) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Warp works fine, also on autostart, the UI doesn't get updated right away, so it may appear warp isn't on yet, or warp is still on after loading. |
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
groepaz: so which settings do i edit to fix these issues:
* Warpmode doesnt seem to work while the c-64 i/o is busy
* Warpmode is alot slower compared to 2.4 |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I'm not groepaz, but:
Warp works in 3.1 while the C64 does I/O, albeit slower than 2.4, since 2.4 defaulted to TDE off while 3.1 defaults to TDE on, which means more accurate emulation, sacrificing speed.
If I remember correctly 2.4 also defaulted to non-CRT emulation and FastSID for SID emulation as opposed to 3.x which used CRT emulation and ReSID by default, the biggest bottlenecks in performance, but adding a lot of accuracy.
Then, as Soci mentioned, the codebase was updated removing some speed-hacks but making the code more maintainable. Since there aren't a lot of active VICE devs right now, making sure the code is maintainable with a small team is more important than all sorts of hacks to speed up emulation slightly.
Lastly, disabling cpu-history support and debugging support during compilation will speed up VICE slightly. But the biggest bottleneck I'm aware off is still the SID and CRT emulation coupled with less-than-ideal synchronisation code, which isn't trivial to fix.
So, to get 2.4-like performance: disable CRT, set SID to FastSID, compile without cpu-history/debug (the default for configure), disable True Drive Emulation, enable device traps and hope stuff still works. |
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
Compyx: i have tried all that but i still dont get any improvements. (im basically running with identical settings as 2.4).
I guess i have to wait for warp speed optimizations before i switch to a new Vice version.
-m |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
you can wait forever for "warp speed optimizations" because that will never happen. what will be optimized is accuracy of the emulation. no idea why you would prefer crappy emulation either =)
the difference you see might be because of the SID emulation settings, which have been changed to be more accurate too. (and I/O being busy is not connected to warp speed at all - except perhaps that more accurate emulation needs more CPU) |
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
I guess i stay with 2.4 forevvaaaa! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
guess you dont need accurate CIA emulation or VIC timing for scrolling bitmaps and/or color cycling :) |
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
you guess to much. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
anyone who prefers warp speed over accurate emulation certainly doesnt hit the limits. at all :) |
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
oh come on, just fix the damn warpspeed instead of trolling about vice settings. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
there is nothing to fix, except for emulation bugs. |
| |
soci
Registered: Sep 2003
Posts: 479 |
I still can get 311% warp on my faster Pentium II-400 while running my recently released scroller part.
What I've noticed is that resampling is still active while in warp mode. This is sort of counter intuitive as one might think that the sound is off as there's nothing audible. Actually it isn't and it's eating cycles as usual, and much more since 3.x changed resampling defaults.
Turn off sound for real or tune back resampling to "fast". Then likely you'll get much better performance for testing stuff in warp. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: I still can get 311% warp on my faster Pentium II-400 while running my recently released scroller part.
What I've noticed is that resampling is still active while in warp mode. This is sort of counter intuitive as one might think that the sound is off as there's nothing audible. Actually it isn't and it's eating cycles as usual, and much more since 3.x changed resampling defaults.
Turn off sound for real or tune back resampling to "fast". Then likely you'll get much better performance for testing stuff in warp.
I.e. there are things to fix. Everything not related to updating internal state can be disabled in warp mode and thus improve performance.
I.e. no sound rendering, no bitmap rendering, no filters etc etc. |
| |
Slajerek
Registered: May 2015
Posts: 63 |
In my C64 Debugger which I plan to release soon I added option to switch off SID emulation completely when in warp mode. This *seems* to not destroy emulation, as the ReSID cycle is synced back to CPU just a while after returning from warp. Anyway - the warp got huge speed improvement. This is a crude hack, but it seems it is acceptable in most cases. By the way I think it's high time for me to post some patches to the Vice too :-) I'll post my outcomes within next few weeks. |
| |
Dano
Registered: Jul 2004
Posts: 231 |
@Slajerek: can't wait for the release. your debugger got SO SO vital to my development cycle.
@Compyx: thanks for info, will give it a try. as dennis told me you said that FastSID won't be supported anymore. it's strange that WinVice3.1 sounds worse there with some of our tunes than i think 2.4 did. Always used FastSID while working on Reluge. And Tobias' latest 2 tunes sound like
utter crap on FastSID now.
Tobias told me to use a filter bias auf -2500 which is better to his ears than the default +500.
@Pantaloon: i am completely with you there. Sometimes we need to warp to certain locations and points in our products.
Getting a little offtopic here, but 2 things i noticed while dev'ing the last months:
- Sometimes Vice doesn't autostart the file it's given upon starting. Closing and redoing the Compile+Start solves this usually latest after like 2 tries.
- On Windows sometimes the Mousepointer gets hooked/invisible and you can't Mouse-Interact with Vice anymore (f.e. moving the window). Only Solution until now was to delete the config file and re-set all my custom settings (like debug-borders).
Coming back to my problem i usually notice that the Vice Display FPS slow down the more is happening on screen. Frankly speaking screen action should not have effect on Vice Perfomance?! Having stuff like flashing/debug Bordercolors makes Vice drop in FPS like hell. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
Quote:Turn off sound for real or tune back resampling to "fast". Then likely you'll get much better performance for testing stuff in warp.
...and it also _does_ effect acuracy of the emulation. no not just in terms of output - actual test programs will then fail. and thats why the default was changed.
dano: of course when more things happen, more CPU is used. thats why comparing warp speeds in the basic startup screen is a silly exercise :) |
| |
Raf
Registered: Nov 2003
Posts: 343 |
Quote: In my C64 Debugger which I plan to release soon I added option to switch off SID emulation completely when in warp mode. This *seems* to not destroy emulation, as the ReSID cycle is synced back to CPU just a while after returning from warp. Anyway - the warp got huge speed improvement. This is a crude hack, but it seems it is acceptable in most cases. By the way I think it's high time for me to post some patches to the Vice too :-) I'll post my outcomes within next few weeks.
Your patches will be then skipped like Polish cartridges emulation developed within www.c64power.com xD |
| |
Dano
Registered: Jul 2004
Posts: 231 |
@groepaz: does cpu action have such an impact on emulation? would have thought that VIC & SID display stuff takes about 80% of the emulation power.
when talking of warp-speeds on startup:
quite some time i have the phenomenon that Vice doesn't fall back into normal mode after having (auto-)started the file given. then i have to manually un-warp emulation. can't pinpoint to when things happen like this as i 99% of my dev work just do the F7 in sublime which does compile and start vice after that. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
Quote:Your patches will be then skipped like Polish cartridges emulation developed within www.c64power.com
when the patches make test programs fail that work without the patch, then they will be rejected. obviously, i hope.
Quote:quite some time i have the phenomenon that Vice doesn't fall back into normal mode after having (auto-)started the file given. then i have to manually un-warp emulation.
didnt see that behaviour for a long time - is that with the original kernal? any cartridges active? |
| |
Dano
Registered: Jul 2004
Posts: 231 |
Quote: Quote:Your patches will be then skipped like Polish cartridges emulation developed within www.c64power.com
when the patches make test programs fail that work without the patch, then they will be rejected. obviously, i hope.
Quote:quite some time i have the phenomenon that Vice doesn't fall back into normal mode after having (auto-)started the file given. then i have to manually un-warp emulation.
didnt see that behaviour for a long time - is that with the original kernal? any cartridges active?
Quote:
Quote:quite some time i have the phenomenon that Vice doesn't fall back into normal mode after having (auto-)started the file given. then i have to manually un-warp emulation.
didnt see that behaviour for a long time - is that with the original kernal? any cartridges active?
orignal kernel, but got a retro replay or an action replay set as default freezer cartridge.
after pressing F7 the programm loads.
or nothing happens in some cases. just a normal blinking cursor then. |
| |
soci
Registered: Sep 2003
Posts: 479 |
Quoting danoComing back to my problem i usually notice that the Vice Display FPS slow down the more is happening on screen. Frankly speaking screen action should not have effect on Vice Perfomance?! Having stuff like flashing/debug Bordercolors makes Vice drop in FPS like hell.
Be careful with what you wish for. I'm sure there's more than one way to achieve exactly that... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
Quote:orignal kernel, but got a retro replay or an action replay set as default freezer cartridge.
after pressing F7 the programm loads.
so, basically PEBCAK then :) to make that work reliable, use -keybuf to put a F7 keypress into keyboard buffer after reset (and after a suitable timeout). the autostart mechanism doesnt know about cartridges, nor anything that isnt the original kernal. |
| |
Dano
Registered: Jul 2004
Posts: 231 |
Quote: Quote:orignal kernel, but got a retro replay or an action replay set as default freezer cartridge.
after pressing F7 the programm loads.
so, basically PEBCAK then :) to make that work reliable, use -keybuf to put a F7 keypress into keyboard buffer after reset (and after a suitable timeout). the autostart mechanism doesnt know about cartridges, nor anything that isnt the original kernal.
Quote:orignal kernel, but got a retro replay or an action replay set as default freezer cartridge.
after pressing F7 the programm loads.
so, basically PEBCAK then :) to make that work reliable, use -keybuf to put a F7 keypress into keyboard buffer after reset (and after a suitable timeout). the autostart mechanism doesnt know about cartridges, nor anything that isnt the original kernal.
that pretty much NOT explains why it's working at times.
srsly, it happens, then it not happens, .... not happens, happens.. and be sure i tried various things like waiting less, waiting more. yet still if i do it 10 times the same way it can work a random number 0..10.
ofcourse it's easy to blame the user for doing <<RANDOM>> thing wrong instead of finding a solution. guess my collegues can be happy that i am not such a type of coder..
apart from the fact that i don't want to check the compile script or have "compile with f7" and "compile without f7". blabla. welcome to the world of working around quirks because the reason is not to be found or wanted to be found.. ^^ |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
the reason is that autostart uses specific timing constraints. it works sometimes and sometimes not because the timing you press F7 with is not always the same.
and if you dont want to use the solution that actually works... ok. dont blame the emulator for it though, thats just silly =P |
| |
Dano
Registered: Jul 2004
Posts: 231 |
ah yes, then it makes totally sense why the problem occurs at times with instant f7 pressing or waiting with pressing f7 for a longer time (>10 seconds that is).
and i must admit lame me doesn't know how vice detects when to switch off warp-mode after loading a file.
but honestly this too is offtopic as it was not about "non-existant" vice bugs but rather vice performance (tipps).
thanks again at soci and compyx for comprehensive informations. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
If you are on Windows, note that VICE can trap all mouse clicks, so if you have something in the clipboard, and right click somewhere you will paste it into the keyboard buffer.. this can wreck havoc on Autostart, or not depending on when you click and what the emulator is doing etc makes it somewhat random. |
| |
Dano
Registered: Jul 2004
Posts: 231 |
Went through settings and disabled the render filter to none. Switched SID to 8580 Resid. This currently gave me a variable FPS value between 45 to 52 fps. Funny enough emulation speeed variied from 95% to 105% even with emulation speed to 100% normal.
Setting the render filter to "CRT" gave me something like 12fps to 20fps.
On x64 that is.
Does "double size" and "double scan" have much of an effect in VIC emulation?
x64sc is on 68% speed and 15fps.. |
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: Went through settings and disabled the render filter to none. Switched SID to 8580 Resid. This currently gave me a variable FPS value between 45 to 52 fps. Funny enough emulation speeed variied from 95% to 105% even with emulation speed to 100% normal.
Setting the render filter to "CRT" gave me something like 12fps to 20fps.
On x64 that is.
Does "double size" and "double scan" have much of an effect in VIC emulation?
x64sc is on 68% speed and 15fps..
Are you sure certainly that your CPU is not throttling? I can even run X64SC (Winvice 3) on a Z8700 based atom laptop with no slowdowns. (And that includes Resid on and double screen/pal emulation) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
by far the most CPU is wasted in resid and CRT emulation - all the rest is pretty irrelevant. you shouldnt have that sort of performance problems in any case. |
| |
Dano
Registered: Jul 2004
Posts: 231 |
@algorithm: got a decent hint for me to check upon throttling and current cpu speeds and such? got such a feeling myself, but up to now my findings didn't bring up a proof for that..
in windows itself the energy settings are re-set to max power. |
| |
algorithm
Registered: May 2002
Posts: 705 |
You can try using HW monitor and monitoring temperatures before you run Vice and during. This will show you the multipliers as well as temperatures of the CPU cores.
Usually during boot/reboot, there is more cpu activity. Leave it for a few minutes, run hwmonitor, monitor the multiplier/temperatures, then run vice. Indication of throttling is when the temperatures go up (and multipliers are at a high state) then multipliers reducing after.
For some users, turning off turboboost (set 99% under cpu max speed in power settings) can help (even at non-turbo, your CPU should still have (Just about) sufficient power to run x64sc at 50fps. |
| |
soci
Registered: Sep 2003
Posts: 479 |
Quote: Quote:the terrible sound- and sync- code that needs to be deleted and rewritten.
This is likely only a problem on Win32. According to a quick search the Sleep function used currently is only as good as the timer tick which is rumoured to have a 64 Hz resolution.
First I would say this function in the arch code should be replaced with something better before going for a complete rewrite of the generic part. Maybe just putting a NtSetTimerResolution call somewhere might also do the trick.
I don't seem have sync problems on Linux but that's not a fair comparison as this OS got rid of the fixed 100/1000 Hz ticks many years ago... |
| |
Dano
Registered: Jul 2004
Posts: 231 |
Algorithm has won the cup for me!
Have been google'ing on "ux32vd throttling" and it seems there is a bug in intel's DPTF windows 10 driver.
before using cpu-z it showed that my cpu speed was locked to 998mhz due to throttling. doing a restart gave it back up to 1900mhz resulting in 39fps in x64sc with resid and crt.
doing a downgrade to the windows8 DPTF drivers resulted in a clockspeed of 2800mhz giving me the full power of the laptop back. resulting in constant 50fps at 100% speed in vice.
summing up: in my case it has not been windows but faulty (intel) drivers on my laptop causing the slowdown.
me will keep an eye on that if there's throttling again with not locking the processor there after cool down.
and it's good to see that it was not just just a feeling that the laptop performed below par. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
soci: depending on what sound system i use, i can reproduce various problems on linux as well... the core problem is how the timing is derived using a different source than how many samples have been played. that way you never get the timing right and keep meandering around a point that is "almost right" - which is why the fps goes up and down, for example. |
| |
Slajerek
Registered: May 2015
Posts: 63 |
Yes, it plays very wrong. |
