energy usage

Pagina 2/4
1 | | 3 | 4

Van rolandve

Master (218)

afbeelding van rolandve

25-04-2020, 15:02

Manuel wrote:
rolandve wrote:
Emphy wrote:

You may want to check which renderer is being used (in the video options). On my laptop (i5), cpu usage lowers from 30% to around 15% when I select sdlgl instead of sdl.

This Mac build does not have the option for SDLgl or SDL.

Did you see my post? You can check these settings in the OSD menu or using the console (e.g. set renderer)

I am not sure who this reply was for: the OSD I have, does not offer the choice for renderer. I have to use the console for that. Using the console with set renderer SDLgl-pp gives a blink (screen refresh) and the energy usage drops another 2% so running at 2x its still 11% energy usage.


and link because picture not visible
my OSD

Van rolandve

Master (218)

afbeelding van rolandve

25-04-2020, 15:17

With the same settings, except scanline: 0 my cpu usage is 4.5% in pause mode. This thread wasn't about cpu usage, it was about battery usage. I've been looking at the GPU's in my system and it seems the Radeon 5500M is the one that gets the load when openMSX runs. That would make sense. The radeon is a energy hungry card, that you better only use when on power.
Sadly enough, Apple offers no option to temporarily disable the Radeon card. Apple only offers the option to disable the Intel UHD Graphics 630...

Based on this, I think my question has been answered and the openMSX team has hopefully enjoyed this discussion.

Van ducasp

Champion (304)

afbeelding van ducasp

25-04-2020, 15:22

Crying

rolandve wrote:

This is a hard one: the energy usage of openMSX is really high. It burns laptop batteries dry in an hour, which is no fun if you're like me, using MSX while sitting in a lazy chair enjoying the fact that MSX can do games without the need for a mouse.
It easily peaks at 30% (of an i9 at 2.4 ghz) while just waiting for user input in a OpenMSX boosted TurboR with IDE. This scales nicely with the machine, because my previous MBP had an i7 and that also burned at 30%.

I understand this is not a bug, nor that its really high on a priority list ( I guess), but perhaps you could put some breaks in the code that burns the energy. I understand I have no clue about the architecture of openMSX so it might even not be possible. I only have some tips from my job. In VB.Net I sometimes write code that loops in some kind of wait-state (because not everything is an event) and the code become a CPU-hog, burning energy. Some sleeps x ms/doevents, etc at that point performs miracles. Perhaps, this is a possibility?

Thanks

Your topic starts on a wrong assumption... There is no such thing as an idle MSX, those computers are from an era that power savings and idle states were not something considered.

As such, no matter if you are sitting at the dos prompt or basic prompt or if running a loop of calculations, there are lots of processes running and vdp still is calculating lines and pixels and doing interruptions, z80 is crunching data all the time, and so on.

So, OPENMSX is cpu intensive for a reason, it will calculate states and transitions as much as possible, thus resulting in high cpu usage, as all processes are host cpu dependent.

The only way I see to lower your cpu usage is to use a simpler emulator that doesn't strive for perfection as much, like fmsx build in libreto, it doesn't try to be as perfect, thus, doesn't check so much things at pixel or line level, and cpu resources used are less. Probably emulating a lower specced MSX on OpenMSX will help as well, do you need a Turbo-R wit v9990 and moonsound to play knightmare? But just the fact you are using a machine with those include two cpu intensive emulations, wasting battery.

Let's say OpenMSX would try to determine when those chips are idle and when they are not, this would cause a problem of latency and introduce bugs, which might be fixed and worked around, but again, that would work again the strive for perfection motto...

Obviously I'm not part of OpenMSX team, but that is my 2 cents and understanding. Tongue

Van rolandve

Master (218)

afbeelding van rolandve

25-04-2020, 15:47

ducasp wrote:

Crying

rolandve wrote:

This is a hard one: the energy usage of openMSX is really high. It burns laptop batteries dry in an hour, which is no fun if you're like me, using MSX while sitting in a lazy chair enjoying the fact that MSX can do games without the need for a mouse.
It easily peaks at 30% (of an i9 at 2.4 ghz) while just waiting for user input in a OpenMSX boosted TurboR with IDE. This scales nicely with the machine, because my previous MBP had an i7 and that also burned at 30%.

I understand this is not a bug, nor that its really high on a priority list ( I guess), but perhaps you could put some breaks in the code that burns the energy. I understand I have no clue about the architecture of openMSX so it might even not be possible. I only have some tips from my job. In VB.Net I sometimes write code that loops in some kind of wait-state (because not everything is an event) and the code become a CPU-hog, burning energy. Some sleeps x ms/doevents, etc at that point performs miracles. Perhaps, this is a possibility?

Thanks

Your topic starts on a wrong assumption... There is no such thing as an idle MSX, those computers are from an era that power savings and idle states were not something considered.

As such, no matter if you are sitting at the dos prompt or basic prompt or if running a loop of calculations, there are lots of processes running and vdp still is calculating lines and pixels and doing interruptions, z80 is crunching data all the time, and so on.

So, OPENMSX is cpu intensive for a reason, it will calculate states and transitions as much as possible, thus resulting in high cpu usage, as all processes are host cpu dependent.

The only way I see to lower your cpu usage is to use a simpler emulator that doesn't strive for perfection as much, like fmsx build in libreto, it doesn't try to be as perfect, thus, doesn't check so much things at pixel or line level, and cpu resources used are less. Probably emulating a lower specced MSX on OpenMSX will help as well, do you need a Turbo-R wit v9990 and moonsound to play knightmare? But just the fact you are using a machine with those include two cpu intensive emulations, wasting battery.

Let's say OpenMSX would try to determine when those chips are idle and when they are not, this would cause a problem of latency and introduce bugs, which might be fixed and worked around, but again, that would work again the strive for perfection motto...

Obviously I'm not part of OpenMSX team, but that is my 2 cents and understanding. Tongue

Funny how people always know what people assume, regardless of whether that's true. Second, I never assumed that idle means doing nothing: even current machines, where low energy is relevant, crunch numbers all the time. It was about: some routines (seem to) use a lot of energy and perhaps, some smart redesign can reduce the energy usage, just a suggestion for an improvement. As it turned out: cpu usage was not related to the energy because Mac OS prefers the dGPU over the intel integrated card.

And yes, this beast of a machine is overpowered for continuously running the turbo pascal compiler (not knightmare!), but it compiles fast.

Van pgimeno

Master (176)

afbeelding van pgimeno

25-04-2020, 15:52

Another setting that influences power usage is set accuracy.

I've noticed that a Turbo-R consumes a lot more CPU than a Philips NMS-8250; perhaps it has to do with the emulated sound hardware and the recently added accurate YM2413 core, not sure. Or perhaps the R800 emulation.

Van hamlet

Scribe (3104)

afbeelding van hamlet

25-04-2020, 15:51

Quote:

And yes, this beast of a machine is overpowered for continuously running...

That's good. The faster your computer works, the faster you can turn it off. This also saves energy. Tongue

Van rolandve

Master (218)

afbeelding van rolandve

25-04-2020, 15:57

hamlet wrote:
Quote:

And yes, this beast of a machine is overpowered for continuously running...

That's good. The faster your computer works, the faster you can turn it off. This also saves energy. Tongue

It's day and the sun is bright, I am currently selling power, not buying Smile

Van ducasp

Champion (304)

afbeelding van ducasp

25-04-2020, 16:10

rolandve wrote:
ducasp wrote:

Crying

rolandve wrote:

This is a hard one: the energy usage of openMSX is really high. It burns laptop batteries dry in an hour, which is no fun if you're like me, using MSX while sitting in a lazy chair enjoying the fact that MSX can do games without the need for a mouse.
It easily peaks at 30% (of an i9 at 2.4 ghz) while just waiting for user input in a OpenMSX boosted TurboR with IDE. This scales nicely with the machine, because my previous MBP had an i7 and that also burned at 30%.

I understand this is not a bug, nor that its really high on a priority list ( I guess), but perhaps you could put some breaks in the code that burns the energy. I understand I have no clue about the architecture of openMSX so it might even not be possible. I only have some tips from my job. In VB.Net I sometimes write code that loops in some kind of wait-state (because not everything is an event) and the code become a CPU-hog, burning energy. Some sleeps x ms/doevents, etc at that point performs miracles. Perhaps, this is a possibility?

Thanks

Your topic starts on a wrong assumption... There is no such thing as an idle MSX, those computers are from an era that power savings and idle states were not something considered.

As such, no matter if you are sitting at the dos prompt or basic prompt or if running a loop of calculations, there are lots of processes running and vdp still is calculating lines and pixels and doing interruptions, z80 is crunching data all the time, and so on.

So, OPENMSX is cpu intensive for a reason, it will calculate states and transitions as much as possible, thus resulting in high cpu usage, as all processes are host cpu dependent.

The only way I see to lower your cpu usage is to use a simpler emulator that doesn't strive for perfection as much, like fmsx build in libreto, it doesn't try to be as perfect, thus, doesn't check so much things at pixel or line level, and cpu resources used are less. Probably emulating a lower specced MSX on OpenMSX will help as well, do you need a Turbo-R wit v9990 and moonsound to play knightmare? But just the fact you are using a machine with those include two cpu intensive emulations, wasting battery.

Let's say OpenMSX would try to determine when those chips are idle and when they are not, this would cause a problem of latency and introduce bugs, which might be fixed and worked around, but again, that would work again the strive for perfection motto...

Obviously I'm not part of OpenMSX team, but that is my 2 cents and understanding. Tongue

Funny how people always know what people assume, regardless of whether that's true. Second, I never assumed that idle means doing nothing: even current machines, where low energy is relevant, crunch numbers all the time. It was about: some routines (seem to) use a lot of energy and perhaps, some smart redesign can reduce the energy usage, just a suggestion for an improvement. As it turned out: cpu usage was not related to the energy because Mac OS prefers the dGPU over the intel integrated card.

And yes, this beast of a machine is overpowered for continuously running the turbo pascal compiler (not knightmare!), but it compiles fast.

You can use a regular Turbo-R or just create a new one based on it without OPL4 and v9990, this alone could help a lot. Wink

BTW, sorry if you took wrong assumption so badly, I do wrong assumptions all the time, that's life, in my opinion if you think of an emulator that strives to perfection and it starts to include workarounds to change the behavior of chips because at that moment they are not needed, this is just what emulators that don't strive to be as accurate as possible do and why they are not as accurate but probably accurate enough to run 90% of software and most won't notice any discrepancy.

Van Grauw

Ascended (9071)

afbeelding van Grauw

25-04-2020, 16:30

When I run openMSX on my 2019 MacBook Pro it uses 8% CPU of a single core emulating a turboR GT, so it doesn’t break a sweat. I use mostly default settings, so SDLGL-PP and pixel accuracy.

At some point it ran much worse on my old 2012 MacBook Pro, however that turned out to be cooling issues with the laptop, which throttled the CPU and made it consume a lot more power. After I cleaned out the dust nests out of the fans, CPU usage and power consumption went down by a lot.

By the way, as an example of how openMSX does save power when it can, the audio buffer generation part of the audio chip emulation is bypassed when no sound is playing.

I’ve over the years seen many commits from the openMSX developers meticulously optimising various aspects of the emulation, to shave off a few % of performance or memory here and there, to the point where I myself wouldn’t even bother. I can assure you they pay much more attention to this than your average software developer.

Van sd_snatcher

Prophet (3270)

afbeelding van sd_snatcher

25-04-2020, 16:50

Quote:

I can assure you they pay much more attention to this than your average software developer.

I have no doubts about that. Smile

It's an excellent emulator, and its team is very dedicated. I'm pretty sure that, if there's a problem, it happens due to some unexpected situation/combination and not because of lack of effort.

Pagina 2/4
1 | | 3 | 4