Discussion:
mouse in linux 2.6.11 host
(too old to reply)
Andreu Escudero
2005-04-01 09:09:20 UTC
Permalink
Hello everyone, I have a strange problem when using pearpc in my
debian sarge system when running with a 2.6.11 kernel. Everything
seems OK, pearpc starts right as always, but every mouse movement
makes a BIG jump, down-left, until the mouse cursos reaches the lower
end of the screen and dissapears. I have the same problem both in the
main and the altivec branch of cvs, both compiled with gcc 3.3.5, but
exact the same ppc binaries work without any problems when using a
host with 2.6.10, 2.6.9 or 2.6.8 kernel.
The 2.6.11 is self-compiled, with basically the same options as I
always have for my laptop.

Anyone knows something about this problem? or anyone has been able to
use it correctly in a machine with a 2.6.11 linux kernel?

thanks
Jens von der Heydt
2005-04-01 09:15:40 UTC
Permalink
Post by Andreu Escudero
Hello everyone, I have a strange problem when using pearpc in my
debian sarge system when running with a 2.6.11 kernel. Everything
seems OK, pearpc starts right as always, but every mouse movement
makes a BIG jump, down-left, until the mouse cursos reaches the lower
end of the screen and dissapears. I have the same problem both in the
main and the altivec branch of cvs, both compiled with gcc 3.3.5, but
exact the same ppc binaries work without any problems when using a
host with 2.6.10, 2.6.9 or 2.6.8 kernel.
The 2.6.11 is self-compiled, with basically the same options as I
always have for my laptop.
Anyone knows something about this problem? or anyone has been able to
use it correctly in a machine with a 2.6.11 linux kernel?
thanks
If it is total strange behaviour and no real movement I'd say
that you should try a different mouse driver. Does it work with a
2.4 kernel?

Jens
Brian Onn
2005-04-01 09:54:03 UTC
Permalink
On Fri, 01 Apr 2005 11:15:40 +0200, Jens von der Heydt
Post by Jens von der Heydt
Post by Andreu Escudero
Hello everyone, I have a strange problem when using pearpc in my
debian sarge system when running with a 2.6.11 kernel. Everything
seems OK, pearpc starts right as always, but every mouse movement
makes a BIG jump, down-left, until the mouse cursos reaches the lower
end of the screen and dissapears. I have the same problem both in the
main and the altivec branch of cvs, both compiled with gcc 3.3.5, but
exact the same ppc binaries work without any problems when using a
host with 2.6.10, 2.6.9 or 2.6.8 kernel.
The 2.6.11 is self-compiled, with basically the same options as I
always have for my laptop.
Anyone knows something about this problem? or anyone has been able to
use it correctly in a machine with a 2.6.11 linux kernel?
thanks
If it is total strange behaviour and no real movement I'd say
that you should try a different mouse driver. Does it work with a
2.4 kernel?
Jens
I run Knoppix (based on debian) w/2.6.10 on my desktop. I'll upgrade to
2.6.11 and check it out too.

-- Brian
Andreu Escudero
2005-04-01 10:14:39 UTC
Permalink
Post by Jens von der Heydt
If it is total strange behaviour and no real movement I'd say
that you should try a different mouse driver. Does it work with a
2.4 kernel?
I have tried both with the synaptics touchpad of my laptop, and with
an external usb optical mouse. Both work perfectly in linux, but with
both I have the same exact effect on ppc.
I have not tried what a 2.4 kernel does, but all 2.6 work perfectly
well, except 2.6.11 (I have tried 2 different subversions of 2.6.11,
the same result with both.
Daniel Foesch
2005-04-01 15:34:16 UTC
Permalink
Post by Andreu Escudero
Post by Jens von der Heydt
If it is total strange behaviour and no real movement I'd say
that you should try a different mouse driver. Does it work with a
2.4 kernel?
I have tried both with the synaptics touchpad of my laptop, and with
an external usb optical mouse. Both work perfectly in linux, but with
both I have the same exact effect on ppc.
I have not tried what a 2.4 kernel does, but all 2.6 work perfectly
well, except 2.6.11 (I have tried 2 different subversions of 2.6.11,
the same result with both.
Changing your mouse in Windows/Linux won't make a difference to the
emulated client. This is because Windows/Linux have already
abstracted away the differences between all mouse-interfaces before
PearPC gets it's information.

Specifically Jens was asking if you've a different driver inside of
the PearPC hosted linux environment.
--
Daniel Foesch,
PearPC Developer
lars
2005-04-01 11:06:36 UTC
Permalink
Hi guys,

You will not believe this, but after profiling PearPC I decided to try a
wild change based on the results I saw and guess what: PearPC runs now much
much faster!!! :-)

Its a dirty and crazy change, but the results are wow :-)))


Lars
Jens von der Heydt
2005-04-01 11:16:19 UTC
Permalink
Post by lars
Hi guys,
You will not believe this, but after profiling PearPC I decided to try a
wild change based on the results I saw and guess what: PearPC runs now much
much faster!!! :-)
Its a dirty and crazy change, but the results are wow :-)))
Lars
Nice for you, but this is a developer list, so perhaps telling us what
you did would
likely be good for the project :)

Jens
varname
2005-04-01 11:29:18 UTC
Permalink
Sent: Friday, April 01, 2005 1:16 PM
I'm guessing he found out that it's april fools day :]
howard spoelstra
2005-04-01 11:32:45 UTC
Permalink
Let me guess, you set the date to 01.04.2005, right?
Oh No, it already IS 01.04.2005
Subject: Re: [Pearpc-devel] A much much faster PearPC !!!
Date: Fri, 01 Apr 2005 13:16:19 +0200
Post by lars
Hi guys,
You will not believe this, but after profiling PearPC I decided to try a
wild change based on the results I saw and guess what: PearPC runs now
much
much faster!!! :-)
Its a dirty and crazy change, but the results are wow :-)))
Lars
Nice for you, but this is a developer list, so perhaps telling us what you
did would
likely be good for the project :)
Jens
-------------------------------------------------------
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
_________________________________________________________________
Gebruik MSN Webmessenger op je werk en op school
http://webmessenger.msn.com/
lars
2005-04-01 11:45:04 UTC
Permalink
Jens,

This is the beginning of the profile report on PearPC:

24.95 47.37 47.37
ppc_read_effective_word_asm
13.89 73.74 26.37 jitcTouchClientPage
8.14 89.19 15.46
ppc_effective_to_physical_data_read
7.09 102.65 13.46 jitcNewPC
6.58 115.14 12.49
ppc_write_effective_word_asm
5.71 125.98 10.85
ppc_write_effective_dword_asm
3.86 133.32 7.34
ppc_read_effective_byte_asm
2.91 138.84 5.52
ppc_effective_to_physical_code
2.72 144.00 5.16
ppc_effective_to_physical_data_write
2.43 148.61 4.62
ppc_read_effective_qword_asm
1.84 152.10 3.49
ppc_read_effective_half_z_asm
1.54 155.03 2.93 jitcNewEntrypoint
1.52 157.92 2.89
ppc_write_effective_qword_asm
1.46 160.70 2.78
jitcGetOrCreateClientPage(unsigned int)
1.37 163.30 2.60
ppc_write_effective_byte_asm
1.08 165.35 2.05 ppc_opc_srawx()
1.02 167.29 1.94
ppc_read_effective_half_s_asm
0.92 169.04 1.75 jitcCreateClientPage
0.77 170.50 1.46 3751755 0.00 0.00
sys_get_hiresclk_ticks()
0.75 171.92 1.43
ppc_heartbeat_ext_rel_asm
0.65 173.15 1.23
ppc_write_effective_half_asm
0.57 174.24 1.09
ppc_effective_to_physical_data_read_ret
0.51 175.21 0.98
ppc_mmu_tlb_invalidate_all_asm
0.49 176.14 0.93
jitcDestroyFragments(TranslationCacheFragment*)
0.49 177.07 0.93 gcard_write_4(unsigned
int, unsigned int)
0.43 177.88 0.81 ppc_new_pc_rel_asm
0.37 178.58 0.71
gcard_write_16(unsigned int, uint128*)
0.35 179.25 0.67 ppc_heartbeat_ext_asm
0.32 179.85 0.60 ppc_new_pc_asm
0.28 180.38 0.53
ppc_effective_to_physical_data_write_ret
...

I noticed that sys_get_hiresclk_ticks() was called almost 4 million times,
just on the short test I did with PearPC.

sys_get_hiresclk_ticks() just calls Win32 API (for Windows version)
QueryPerformanceCounter() which returns the current value of the
high-resolution performance counter of the system.

Reading about this function on the web, I found that it is slow as it
comunicates to ports on the machine. So I thought "what if I do this... ?"
:-)

Next...

Lars
Rick Altherr
2005-04-02 18:29:22 UTC
Permalink
Why are you bothering to optimize something that constitutes 0.77% of
the total execution time. I would think that you would want to look at
functions that are actually taking a fair amount of time.
--
Rick Altherr
Architecture and Performance Group
Post by lars
Jens,
24.95 47.37 47.37
ppc_read_effective_word_asm
13.89 73.74 26.37
jitcTouchClientPage
8.14 89.19 15.46
ppc_effective_to_physical_data_read
7.09 102.65 13.46 jitcNewPC
6.58 115.14 12.49
ppc_write_effective_word_asm
5.71 125.98 10.85
ppc_write_effective_dword_asm
3.86 133.32 7.34
ppc_read_effective_byte_asm
2.91 138.84 5.52
ppc_effective_to_physical_code
2.72 144.00 5.16
ppc_effective_to_physical_data_write
2.43 148.61 4.62
ppc_read_effective_qword_asm
1.84 152.10 3.49
ppc_read_effective_half_z_asm
1.54 155.03 2.93 jitcNewEntrypoint
1.52 157.92 2.89
ppc_write_effective_qword_asm
1.46 160.70 2.78
jitcGetOrCreateClientPage(unsigned int)
1.37 163.30 2.60
ppc_write_effective_byte_asm
1.08 165.35 2.05 ppc_opc_srawx()
1.02 167.29 1.94
ppc_read_effective_half_s_asm
0.92 169.04 1.75
jitcCreateClientPage
0.77 170.50 1.46 3751755 0.00 0.00
sys_get_hiresclk_ticks()
0.75 171.92 1.43
ppc_heartbeat_ext_rel_asm
0.65 173.15 1.23
ppc_write_effective_half_asm
0.57 174.24 1.09
ppc_effective_to_physical_data_read_ret
0.51 175.21 0.98
ppc_mmu_tlb_invalidate_all_asm
0.49 176.14 0.93
jitcDestroyFragments(TranslationCacheFragment*)
0.49 177.07 0.93
gcard_write_4(unsigned
int, unsigned int)
0.43 177.88 0.81
ppc_new_pc_rel_asm
0.37 178.58 0.71
gcard_write_16(unsigned int, uint128*)
0.35 179.25 0.67
ppc_heartbeat_ext_asm
0.32 179.85 0.60 ppc_new_pc_asm
0.28 180.38 0.53
ppc_effective_to_physical_data_write_ret
...
I noticed that sys_get_hiresclk_ticks() was called almost 4 million times,
just on the short test I did with PearPC.
sys_get_hiresclk_ticks() just calls Win32 API (for Windows version)
QueryPerformanceCounter() which returns the current value of the
high-resolution performance counter of the system.
Reading about this function on the web, I found that it is slow as it
comunicates to ports on the machine. So I thought "what if I do this... ?"
:-)
Next...
Lars
-------------------------------------------------------
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
lars
2005-04-01 11:46:53 UTC
Permalink
Varname, Howard,
Post by varname
I'm guessing he found out that it's april fools day :]
I live at Spain, here we don't celebrate April 1st.

Its true what I am telling, keep reading my message and prepare your fast
belt :)


Lars
Pp
2005-04-01 12:56:37 UTC
Permalink
Could you create a patch for it

-----Original Message-----
From: lars
Date: 1/4/05 19:45
To: pearpc-***@lists.sourceforge.net
Subj: RE: [Pearpc-devel] A much much faster PearPC !!!

Jens,

This is the beginning of the profile report on PearPC:

24.95 47.37 47.37
ppc_read_effective_word_asm
13.89 73.74 26.37 jitcTouchClientPage
8.14 89.19 15.46
ppc_effective_to_physical_data_read
7.09 102.65 13.46 jitcNewPC
6.58 115.14 12.49
ppc_write_effective_word_asm
5.71 125.98 10.85
ppc_write_effective_dword_asm
3.86 133.32 7.34
ppc_read_effective_byte_asm
2.91 138.84 5.52
ppc_effective_to_physical_code
2.72 144.00 5.16
ppc_effective_to_physical_data_write
2.43 148.61 4.62
ppc_read_effective_qword_asm
1.84 152.10 3.49
ppc_read_effective_half_z_asm
1.54 155.03 2.93 jitcNewEntrypoint
1.52 157.92 2.89
ppc_write_effective_qword_asm
1.46 160.70 2.78
jitcGetOrCreateClientPage(unsigned int)
1.37 163.30 2.60
ppc_write_effective_byte_asm
1.08 165.35 2.05 ppc_opc_srawx()
1.02 167.29 1.94
ppc_read_effective_half_s_asm
0.92 169.04 1.75 jitcCreateClientPage
0.77 170.50 1.46 3751755 0.00 0.00
sys_get_hiresclk_ticks()
0.75 171.92 1.43
ppc_heartbeat_ext_rel_asm
0.65 173.15 1.23
ppc_write_effective_half_asm
0.57 174.24 1.09
ppc_effective_to_physical_data_read_ret
0.51 175.21 0.98
ppc_mmu_tlb_invalidate_all_asm
0.49 176.14 0.93
jitcDestroyFragments(TranslationCacheFragment*)
0.49 177.07 0.93 gcard_write_4(unsigned
int, unsigned int)
0.43 177.88 0.81 ppc_new_pc_rel_asm
0.37 178.58 0.71
gcard_write_16(unsigned int, uint128*)
0.35 179.25 0.67 ppc_heartbeat_ext_asm
0.32 179.85 0.60 ppc_new_pc_asm
0.28 180.38 0.53
ppc_effective_to_physical_data_write_ret
...

I noticed that sys_get_hiresclk_ticks() was called almost 4 million times,
just on the short test I did with PearPC.

sys_get_hiresclk_ticks() just calls Win32 API (for Windows version)
QueryPerformanceCounter() which returns the current value of the
high-resolution performance counter of the system.
lars
2005-04-01 13:02:53 UTC
Permalink
Post by Pp
Could you create a patch for it
Just locate systimer.cc and replace this function:

uint64 sys_get_hiresclk_ticks()
{
static uint64 counter = 1;

return counter += 5;
}


Lars
Jens von der Heydt
2005-04-01 13:56:03 UTC
Permalink
Post by lars
Post by Pp
Could you create a patch for it
uint64 sys_get_hiresclk_ticks()
{
static uint64 counter = 1;
return counter += 5;
}
Lars
Well, that's a nice hack and perhaps this could work,
but what you did is kill the complete timebase that pearpc uses here.

For example, I just booted my osx and the display clock
hasn't changed by a second in the last 10 minutes ....
Animations run like slideshows etc. I guess it's not that
easy, though the initial idea to drop a rather often called
and slow win32 call could be worth digging deeper.

Jens
Daniel Foesch
2005-04-01 14:42:19 UTC
Permalink
This change breaks the very purpose that the sys_get_hiresclk_ticks does.

If you break specs, then of course you can make it go faster.

Find a faster way to implement the function that actually works. Do
not use this function as given.
Post by lars
Post by Pp
Could you create a patch for it
uint64 sys_get_hiresclk_ticks()
{
static uint64 counter = 1;
return counter += 5;
}
Lars
-------------------------------------------------------
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
--
Daniel Foesch,
PearPC Developer
Daniel Foesch
2005-04-01 15:30:43 UTC
Permalink
Stupid mornings while I'm rushing off to work. Ok, let me try this
again. Now with CONSTRUCTIVE Criticism!

Ok, the sys_get_hires_ticks is needed by us in order to maintain clock
coherency. We use this in order to keep an accurate track of time, so
that we don't have a problem with clock drift that was plaguing
earlier versions.

Now, considering that this function is getting called 4 million times,
that doesn't mean that we can't think of a way to reduce the cost of
having to do this.

One idea could be to keep an inaccurate time count like the one given
below, but every 10 times or so, let's just syncronize it to the
correct value. Or other such ideas.

Basically, good finding a bottleneck, unfortunately, the problem is
far from solved, as we *need* this to be an accurate time index.
Post by Daniel Foesch
This change breaks the very purpose that the sys_get_hiresclk_ticks does.
If you break specs, then of course you can make it go faster.
Find a faster way to implement the function that actually works. Do
not use this function as given.
Post by lars
Post by Pp
Could you create a patch for it
uint64 sys_get_hiresclk_ticks()
{
static uint64 counter = 1;
return counter += 5;
}
Lars
-------------------------------------------------------
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
--
Daniel Foesch,
PearPC Developer
--
Daniel Foesch,
PearPC Developer
lars
2005-04-01 13:14:29 UTC
Permalink
Ok, you may download PearPC (Windows version) with such change from:

http://www.fivetechsoft.com/files/ppc.zip

I promise it has no viruses, trojans, or whatever.

The fastest PearPC ever seen


Lars
Andrew Manchneko
2005-04-01 14:33:08 UTC
Permalink
Lars, maybe its just me but i only see a very marginal speed improvement if
any. Its the video thats really killing it perhaps. Who knows. Nice touch
on the bus speed/system speed in the profiler lol. 3.36 GHZ. You should post
this file on pearpc.net, stir the kids up a little.

----- Original Message -----
From: "lars" <***@yahoo.es>
To: <pearpc-***@lists.sourceforge.net>
Sent: Friday, April 01, 2005 8:14 AM
Subject: [Pearpc-devel] A much much faster PearPC !!!
Post by lars
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or whatever.
The fastest PearPC ever seen
Lars
-------------------------------------------------------
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
Chris Case
2005-04-01 16:32:23 UTC
Permalink
Here's a question... what about us linux people? This sounds like a
windows only change... right?
Post by lars
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or whatever.
The fastest PearPC ever seen
Lars
-------------------------------------------------------
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
--
Christopher S. Case
SUNY Fredonia Co/Op Engineering
***@gmail.com
(716) 673 - 4396 (Dorm)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human. To forgive, divine.
To fix mistakes, now that's an Engineer."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jens von der Heydt
2005-04-01 16:38:58 UTC
Permalink
Post by Chris Case
Here's a question... what about us linux people? This sounds like a
windows only change... right?
No, his code should work for linux as well,
but the timing will be screwed up. He is not inserting
actual timing values but a static one.
Robert H. Haener IV
2005-04-01 16:45:10 UTC
Permalink
Post by Jens von der Heydt
Post by Chris Case
Here's a question... what about us linux people? This sounds like a
windows only change... right?
No, his code should work for linux as well,
but the timing will be screwed up. He is not inserting
actual timing values but a static one.
Besides, us Linux users already have a nice speed boost over Windows 8?}


-Robert Haener
trygvebw
2005-04-01 17:22:17 UTC
Permalink
Lars: Does your version support altivec?

trygvebw
Post by Robert H. Haener IV
Post by Jens von der Heydt
Post by Chris Case
Here's a question... what about us linux people? This sounds like a
windows only change... right?
No, his code should work for linux as well,
but the timing will be screwed up. He is not inserting
actual timing values but a static one.
Besides, us Linux users already have a nice speed boost over Windows 8?}
-Robert Haener
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
Brian Onn
2005-04-01 17:22:07 UTC
Permalink
Nice hack... but I see a way to capitalize on what Lars found.

By eliminating the Windows API call and providing his own counter, he was
able to achieve a marked speed-up.

So, we need to reduce the number of calls to the Windows API (and the
equivalent linux API), yet still maintain the correct timings.

In the hardware world, I would used a PLL (Phase Locked Loop) device to
lock one timing source to another, less frequent timing source. The
output of the PLL maintains timing for the system, while slowly drifting
ahead or behind the real clock source, and then occasionally a real-clock
tick arrives and the PLL syncs to it. We can simulate the same basic idea
in software (while not needing to emulate an actual PLL).

In our case, we use Lar's hack to create a software counter *in-between*
calls to the real API. Occasionally, say once per second or once per .1
second (we'd need to figure out what would be needed here) we make a REAL
call to the underlying API and sync our software clock to the real hi-res
clock.

This would need to take into consideration that the software clock might
get ahead or behind the hardware clock and would thus be adjusted up or
down. The ramifications of backing up the clock like this to synchronize
would have to be considered in a proper solution.

-- Brian
Stefan Reinauer
2005-04-01 17:29:43 UTC
Permalink
Post by Jens von der Heydt
No, his code should work for linux as well,
but the timing will be screwed up. He is not inserting
actual timing values but a static one.
If it were not for cpu frequency changes, the increment to the counter
could be calculated once during program start. Then timing would not be
screwed up at all.
This could even be realistic, since a decently working machine will not
drop cpu frequence while pearpc is running and causing a permanent system
load of 100% anyways.

Stefan.
Nikolas 'Atrus' Coukouma
2005-04-01 17:44:46 UTC
Permalink
Post by Stefan Reinauer
Post by Jens von der Heydt
No, his code should work for linux as well,
but the timing will be screwed up. He is not inserting
actual timing values but a static one.
If it were not for cpu frequency changes, the increment to the counter
could be calculated once during program start. Then timing would not be
screwed up at all.
This could even be realistic, since a decently working machine will not
drop cpu frequence while pearpc is running and causing a permanent system
load of 100% anyways.
Stefan.
Actually, come processors do support frequency scaling. For example my
Athlon64 can run at either 800MHz or 2GHz. I agree that it's unlikely,
but far from impossible. I think a simple setting in the config file
would handle things nicely.

-Nikolas 'Atrus' Coukouma
Jens von der Heydt
2005-04-02 12:56:24 UTC
Permalink
Post by Nikolas 'Atrus' Coukouma
Post by Stefan Reinauer
Post by Jens von der Heydt
No, his code should work for linux as well,
but the timing will be screwed up. He is not inserting
actual timing values but a static one.
If it were not for cpu frequency changes, the increment to the counter
could be calculated once during program start. Then timing would not be
screwed up at all.
This could even be realistic, since a decently working machine will not
drop cpu frequence while pearpc is running and causing a permanent system
load of 100% anyways.
Stefan.
Actually, come processors do support frequency scaling. For example my
Athlon64 can run at either 800MHz or 2GHz. I agree that it's unlikely,
but far from impossible. I think a simple setting in the config file
would handle things nicely.
-Nikolas 'Atrus' Coukouma
Why not call the win32 function every 3rd or Xth call ?

Jens
Sebastien Metrot
2005-04-02 13:03:00 UTC
Permalink
Post by Jens von der Heydt
Post by Nikolas 'Atrus' Coukouma
Actually, come processors do support frequency scaling. For example my
Athlon64 can run at either 800MHz or 2GHz. I agree that it's unlikely,
but far from impossible. I think a simple setting in the config file
would handle things nicely.
-Nikolas 'Atrus' Coukouma
Why not call the win32 function every 3rd or Xth call ?
Jens
Have you tried to use the x86 rdtsc instruction instead of calling
QueryPerformanceCounter? (first link from google:
http://www.midnightbeach.com/jon/pubs/rdtsc.htm)

The win32 QPC uses rdtsc but you may win some perfs by removing the
function call overhead.

My 0.02 cents,

Sebastien
Stefan Reinauer
2005-04-02 15:01:48 UTC
Permalink
Post by Nikolas 'Atrus' Coukouma
Actually, come processors do support frequency scaling. For example my
Athlon64 can run at either 800MHz or 2GHz. I agree that it's unlikely,
but far from impossible. I think a simple setting in the config file
would handle things nicely.
Yes, all common CPUs support frequency scaling. But they won't scale
down as long as PearPC is running since the CPU emulation consumes 100%
CPU power permanently. So only a broken bios or missing AC power will
make it scale down.

Another possibility would be to resync the time every now and then
rather than getting it all the time. So if the time and increment is
synced every ten seconds, only those ten seconds after a frequency scale
the time runs slightly faster/slower.

Stefan
Jens von der Heydt
2005-04-02 15:08:06 UTC
Permalink
Post by Stefan Reinauer
Post by Nikolas 'Atrus' Coukouma
Actually, come processors do support frequency scaling. For example my
Athlon64 can run at either 800MHz or 2GHz. I agree that it's unlikely,
but far from impossible. I think a simple setting in the config file
would handle things nicely.
Yes, all common CPUs support frequency scaling. But they won't scale
down as long as PearPC is running since the CPU emulation consumes 100%
CPU power permanently. So only a broken bios or missing AC power will
make it scale down.
Another possibility would be to resync the time every now and then
rather than getting it all the time. So if the time and increment is
synced every ten seconds, only those ten seconds after a frequency scale
the time runs slightly faster/slower.
Stefan
No, PearPC can go idle.

Jens
Stefan Reinauer
2005-04-02 15:56:33 UTC
Permalink
Post by Jens von der Heydt
No, PearPC can go idle.
How? It never did for me.


Stefan
Jens von der Heydt
2005-04-02 16:07:14 UTC
Permalink
Post by Stefan Reinauer
Post by Jens von der Heydt
No, PearPC can go idle.
How? It never did for me.
Stefan
Last time we worked on the whole timing issue
there were semaphores introduced into the code.
It does not do idle calls on your maching?

When OS X is booted, I can watch my CPU go down
to nearly 0 % usage.

Jens
Sebastian Biallas
2005-04-02 23:27:03 UTC
Permalink
Post by Stefan Reinauer
Post by Jens von der Heydt
No, PearPC can go idle.
How? It never did for me.
Really? Please post exact versions of programs involved. This should be
working for long time (and does for me, on Linux and Windows, with Linux
and Mac OS X 10.3 clients).
Post by Stefan Reinauer
Stefan
Sebastian
Daniel Foesch
2005-04-01 17:48:34 UTC
Permalink
Post by Chris Case
Here's a question... what about us linux people? This sounds like a
windows only change... right?
Post by lars
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or whatever.
The fastest PearPC ever seen
Lars
This change can easily be applied to src/osapi/posix/systimer.cc just
as it was for windows.

But let me reiterate. This is an invalid emulation, and should not be
done if you want an accurate emulation that will not lose time. This
is merely a hack, and will not be accepted into any future versions as
is.

But it does have me thinking, so don't worry. I'll get something that
is both accurate, and speedy.
--
Daniel Foesch,
PearPC Developer
Andy Toulouse
2005-04-01 21:05:26 UTC
Permalink
For some odd reason, it feels like this "hack" made my emulation slower. How
do I check?
Post by Chris Case
Here's a question... what about us linux people? This sounds like a
windows only change... right?
Post by lars
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or whatever.
The fastest PearPC ever seen
Lars
This change can easily be applied to src/osapi/posix/systimer.cc just
as it was for windows.
But let me reiterate. This is an invalid emulation, and should not be
done if you want an accurate emulation that will not lose time. This
is merely a hack, and will not be accepted into any future versions as
is.
But it does have me thinking, so don't worry. I'll get something that
is both accurate, and speedy.
--
Daniel Foesch,
PearPC Developer
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
Michael Gonzalez
2005-04-01 21:12:54 UTC
Permalink
its slower for me too :S.. But i got a CPU rating of 3.36 GHZ PowerPC G4
----- Original Message -----
From: Andy Toulouse
To: pearpc-***@lists.sourceforge.net
Sent: Friday, April 01, 2005 4:05 PM
Subject: Re: [Pearpc-devel] A much much faster PearPC !!!


For some odd reason, it feels like this "hack" made my emulation slower. How do I check?
Post by Chris Case
Here's a question... what about us linux people? This sounds like a
windows only change... right?
Post by lars
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or whatever.
The fastest PearPC ever seen
Lars
This change can easily be applied to src/osapi/posix/systimer.cc just
as it was for windows.

But let me reiterate. This is an invalid emulation, and should not be
done if you want an accurate emulation that will not lose time. This
is merely a hack, and will not be accepted into any future versions as
is.

But it does have me thinking, so don't worry. I'll get something that
is both accurate, and speedy.

--
Daniel Foesch,
PearPC Developer


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
Pearpc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
Andy Toulouse
2005-04-02 00:27:08 UTC
Permalink
I take that back. Putting stuff back to the dock, magnification, etc. are
all faster, but there's something about it that feels like it's off. It's
running, then walking, then running, then walking...it's better, but feels
weird.
Post by Andy Toulouse
For some odd reason, it feels like this "hack" made my emulation slower.
How do I check?
Post by Chris Case
Here's a question... what about us linux people? This sounds like a
windows only change... right?
Post by lars
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or whatever.
The fastest PearPC ever seen
Lars
This change can easily be applied to src/osapi/posix/systimer.cc just
as it was for windows.
But let me reiterate. This is an invalid emulation, and should not be
done if you want an accurate emulation that will not lose time. This
is merely a hack, and will not be accepted into any future versions as
is.
But it does have me thinking, so don't worry. I'll get something that
is both accurate, and speedy.
--
Daniel Foesch,
PearPC Developer
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
Daniel Foesch
2005-04-02 00:42:46 UTC
Permalink
This is because of the inconsistent timing of the emulator. The more
we call the timing function, the more time goes by, and the faster
some things run. The less we call it, the slowing the timing is, and
the computer acts slower.
Post by Andy Toulouse
I take that back. Putting stuff back to the dock, magnification, etc. are
all faster, but there's something about it that feels like it's off. It's
running, then walking, then running, then walking...it's better, but feels
weird.
Post by Andy Toulouse
For some odd reason, it feels like this "hack" made my emulation slower.
How do I check?
Post by Andy Toulouse
Post by Daniel Foesch
Post by Chris Case
Here's a question... what about us linux people? This sounds like a
windows only change... right?
Post by lars
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or whatever.
The fastest PearPC ever seen
Lars
This change can easily be applied to src/osapi/posix/systimer.cc
just
Post by Andy Toulouse
Post by Daniel Foesch
as it was for windows.
But let me reiterate. This is an invalid emulation, and should not be
done if you want an accurate emulation that will not lose time. This
is merely a hack, and will not be accepted into any future versions as
is.
But it does have me thinking, so don't worry. I'll get something that
is both accurate, and speedy.
--
Daniel Foesch,
PearPC Developer
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
--
Daniel Foesch,
PearPC Developer
John Kielkopf
2005-04-02 00:54:06 UTC
Permalink
First, I'm NOT a C developer, so please read the following as you would
broken English.

Would something along the lines of this work?:

//(global stuff that needs to be initialized on start somehow - I know
this is wrong, but you get the idea)
int test_inc = 1; //we need to start somwere, so start incing by 1
int test_counter = 0; //
uint64 last_test;
QueryPerformanceCounter((_LARGE_INTEGER *)&last_test); // we need to set
our "last test"
uint64 predicted_test;
predicted_test = last_test; // and our "first" prediction should be correct.


// The "updated" routine
uint64 sys_get_hiresclk_ticks()
{
// Probably not the best place to define this, but here it is
define test_limit = 100;

uint64 test;

// inc the counter
test_counter++;

// Did we go over? If so, get the real performance counter, and
update how we will continue prediction based on how close we got.
if(test_counter>test_limit){
QueryPerformanceCounter((_LARGE_INTEGER *)&test);
test_inc = ((test-last_test)-(predicted_test-test))/test_limit;
test_counter = 0;
last_test = test;
}

// update the predicted result
predicted_test += test_inc;

return predicted_test;
}


--John
Post by Daniel Foesch
This is because of the inconsistent timing of the emulator. The more
we call the timing function, the more time goes by, and the faster
some things run. The less we call it, the slowing the timing is, and
the computer acts slower.
Post by Andy Toulouse
I take that back. Putting stuff back to the dock, magnification, etc. are
all faster, but there's something about it that feels like it's off. It's
running, then walking, then running, then walking...it's better, but feels
weird.
Post by Andy Toulouse
For some odd reason, it feels like this "hack" made my emulation slower.
How do I check?
Post by Andy Toulouse
Post by Daniel Foesch
Post by Chris Case
Here's a question... what about us linux people? This sounds like a
windows only change... right?
Post by lars
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or whatever.
The fastest PearPC ever seen
Lars
This change can easily be applied to src/osapi/posix/systimer.cc
just
Post by Andy Toulouse
Post by Daniel Foesch
as it was for windows.
But let me reiterate. This is an invalid emulation, and should not be
done if you want an accurate emulation that will not lose time. This
is merely a hack, and will not be accepted into any future versions as
is.
But it does have me thinking, so don't worry. I'll get something that
is both accurate, and speedy.
--
Daniel Foesch,
PearPC Developer
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
bjc
2005-04-02 01:37:26 UTC
Permalink
I tried it and the speed is indeed faster, i didn't notice any strange
behavior though.

Jed
Post by John Kielkopf
First, I'm NOT a C developer, so please read the following as you would
broken English.
//(global stuff that needs to be initialized on start somehow - I know
this is wrong, but you get the idea)
int test_inc = 1; //we need to start somwere, so start incing by 1
int test_counter = 0; //
uint64 last_test;
QueryPerformanceCounter((_LARGE_INTEGER *)&last_test); // we need to set
our "last test"
uint64 predicted_test;
predicted_test = last_test; // and our "first" prediction should be correct.
// The "updated" routine
uint64 sys_get_hiresclk_ticks()
{
// Probably not the best place to define this, but here it is
define test_limit = 100;
uint64 test;
// inc the counter
test_counter++;
// Did we go over? If so, get the real performance counter, and
update how we will continue prediction based on how close we got.
if(test_counter>test_limit){
QueryPerformanceCounter((_LARGE_INTEGER *)&test);
test_inc = ((test-last_test)-(predicted_test-test))/test_limit;
test_counter = 0;
last_test = test;
}
// update the predicted result
predicted_test += test_inc;
return predicted_test;
}
--John
Post by Daniel Foesch
This is because of the inconsistent timing of the emulator. The more
we call the timing function, the more time goes by, and the faster
some things run. The less we call it, the slowing the timing is, and
the computer acts slower.
Post by Andy Toulouse
I take that back. Putting stuff back to the dock, magnification, etc. are
all faster, but there's something about it that feels like it's off. It's
running, then walking, then running, then walking...it's better, but feels
weird.
Post by Andy Toulouse
For some odd reason, it feels like this "hack" made my emulation slower.
How do I check?
Post by Andy Toulouse
Post by Daniel Foesch
Post by Chris Case
Here's a question... what about us linux people? This sounds like a
windows only change... right?
Post by lars
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or whatever.
The fastest PearPC ever seen
Lars
This change can easily be applied to src/osapi/posix/systimer.cc
just
Post by Andy Toulouse
Post by Daniel Foesch
as it was for windows.
But let me reiterate. This is an invalid emulation, and should not be
done if you want an accurate emulation that will not lose time. This
is merely a hack, and will not be accepted into any future versions as
is.
But it does have me thinking, so don't worry. I'll get something that
is both accurate, and speedy.
--
Daniel Foesch,
PearPC Developer
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
Sebastian Biallas
2005-04-02 23:24:03 UTC
Permalink
Post by Andy Toulouse
For some odd reason, it feels like this "hack" made my emulation slower.
How do I check?
Yes, this is also possible. It's like the old pearpc versions which
couldn't get the timing right... For some it will apear faster for some
slower, depending on the (hardcoded) factor.

Sebastian
Chris Case
2005-04-01 16:32:23 UTC
Permalink
Here's a question... what about us linux people? This sounds like a
windows only change... right?
Post by lars
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or whatever.
The fastest PearPC ever seen
Lars
-------------------------------------------------------
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
--
Christopher S. Case
SUNY Fredonia Co/Op Engineering
***@gmail.com
(716) 673 - 4396 (Dorm)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human. To forgive, divine.
To fix mistakes, now that's an Engineer."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sebastian Biallas
2005-04-02 23:19:19 UTC
Permalink
Post by lars
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or whatever.
The fastest PearPC ever seen
I guess it apears faster because you don't calibrate the tsc. Take the
older pearpcs and you'll get the same experience.
Post by lars
Lars
Sebastian
lars
2005-04-01 15:12:40 UTC
Permalink
Using a 50 value on a P4 2.400, Internet is working ok and overall speed is
ok:

uint64 sys_get_hiresclk_ticks()
{
static uint64 counter = 1;
return counter += 50;
}


Lars
lars
2005-04-01 17:43:48 UTC
Permalink
Stefan,
If it were not for cpu frequency changes, the increment to the counter could
be calculated once during program start. Then timing would not be screwed up
at all.
That looks as a very good idea :)

We could calculate an average of increments from a certain amount of calls,
and from that moment on, use such value.

Lets try it :)


Lars
lars
2005-04-01 19:49:36 UTC
Permalink
You may find the 50 value based version I am using now at:

http://www.fivetechsoft.com/files/ppc50.zip

It works really fine on a P4 2,4. Internet goes smoothly.

Congrats to PearPC team for such outstanding software :-)

Regards,

Lars
cory graves
2005-04-02 02:10:51 UTC
Permalink
STOP SENDING ME E-MAILES I WILL SUE YOU IF YOU DON'T
STOP.
Post by John Kielkopf
First, I'm NOT a C developer, so please read the
following as you would
broken English.
//(global stuff that needs to be initialized on
start somehow - I know
this is wrong, but you get the idea)
int test_inc = 1; //we need to start somwere, so
start incing by 1
int test_counter = 0; //
uint64 last_test;
QueryPerformanceCounter((_LARGE_INTEGER
*)&last_test); // we need to set
our "last test"
uint64 predicted_test;
predicted_test = last_test; // and our "first"
prediction should be correct.
// The "updated" routine
uint64 sys_get_hiresclk_ticks()
{
// Probably not the best place to define this,
but here it is
define test_limit = 100;
uint64 test;
// inc the counter
test_counter++;
// Did we go over? If so, get the real
performance counter, and
update how we will continue prediction based on how
close we got.
if(test_counter>test_limit){
QueryPerformanceCounter((_LARGE_INTEGER
*)&test);
test_inc =
((test-last_test)-(predicted_test-test))/test_limit;
test_counter = 0;
last_test = test;
}
// update the predicted result
predicted_test += test_inc;
return predicted_test;
}
--John
Post by Daniel Foesch
This is because of the inconsistent timing of the
emulator. The more
Post by Daniel Foesch
we call the timing function, the more time goes by,
and the faster
Post by Daniel Foesch
some things run. The less we call it, the slowing
the timing is, and
Post by Daniel Foesch
the computer acts slower.
On Apr 2, 2005 2:27 AM, Andy Toulouse
Post by Andy Toulouse
I take that back. Putting stuff back to the dock,
magnification, etc. are
Post by Daniel Foesch
Post by Andy Toulouse
all faster, but there's something about it that
feels like it's off. It's
Post by Daniel Foesch
Post by Andy Toulouse
running, then walking, then running, then
walking...it's better, but feels
Post by Daniel Foesch
Post by Andy Toulouse
weird.
On Apr 1, 2005 1:05 PM, Andy Toulouse
Post by Andy Toulouse
For some odd reason, it feels like this "hack"
made my emulation slower.
Post by Daniel Foesch
Post by Andy Toulouse
How do I check?
Post by Andy Toulouse
On Apr 1, 2005 9:48 AM, Daniel Foesch
On Apr 1, 2005 9:32 AM, Chris Case
Post by Chris Case
Here's a question... what about us linux
people? This sounds like a
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
Post by Chris Case
windows only change... right?
On Apr 1, 2005 8:14 AM, lars
Post by lars
Ok, you may download PearPC (Windows version)
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or
whatever.
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
Post by Chris Case
Post by lars
The fastest PearPC ever seen
Lars
This change can easily be applied to
src/osapi/posix/systimer.cc
Post by Daniel Foesch
Post by Andy Toulouse
just
Post by Andy Toulouse
as it was for windows.
But let me reiterate. This is an invalid
emulation, and should not be
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
done if you want an accurate emulation that will
not lose time. This
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
is merely a hack, and will not be accepted into
any future versions as
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
is.
But it does have me thinking, so don't worry.
I'll get something that
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
is both accurate, and speedy.
--
Daniel Foesch,
PearPC Developer
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT
Products from real users.
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
Discover which products truly live up to the
hype. Start reading now.
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
-------------------------------------------------------
Post by John Kielkopf
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT
Products from real users.
Discover which products truly live up to the hype.
Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Post by John Kielkopf
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
__________________________________
Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun.
http://www.advision.webevents.yahoo.com/emoticontest
Andy Toulouse
2005-04-02 02:40:26 UTC
Permalink
Cory: Please unsubscribe to stop getting the emails. As it is completely
voluntary on your part getting the mail is not a suable offense.

Everyone else: That aside, I installed the development tools; which tool
gauges the kind of performance change I'm looking for?
Post by cory graves
STOP SENDING ME E-MAILES I WILL SUE YOU IF YOU DON'T
STOP.
Jens von der Heydt
2005-04-02 13:34:11 UTC
Permalink
why don't you unsubscribe from the list then!?!?!?

Jens
Post by cory graves
STOP SENDING ME E-MAILES I WILL SUE YOU IF YOU DON'T
STOP.
Post by John Kielkopf
First, I'm NOT a C developer, so please read the
following as you would
broken English.
//(global stuff that needs to be initialized on
start somehow - I know
this is wrong, but you get the idea)
int test_inc = 1; //we need to start somwere, so
start incing by 1
int test_counter = 0; //
uint64 last_test;
QueryPerformanceCounter((_LARGE_INTEGER
*)&last_test); // we need to set
our "last test"
uint64 predicted_test;
predicted_test = last_test; // and our "first"
prediction should be correct.
// The "updated" routine
uint64 sys_get_hiresclk_ticks()
{
// Probably not the best place to define this,
but here it is
define test_limit = 100;
uint64 test;
// inc the counter
test_counter++;
// Did we go over? If so, get the real
performance counter, and
update how we will continue prediction based on how
close we got.
if(test_counter>test_limit){
QueryPerformanceCounter((_LARGE_INTEGER
*)&test);
test_inc =
((test-last_test)-(predicted_test-test))/test_limit;
test_counter = 0;
last_test = test;
}
// update the predicted result
predicted_test += test_inc;
return predicted_test;
}
--John
Post by Daniel Foesch
This is because of the inconsistent timing of the
emulator. The more
Post by Daniel Foesch
we call the timing function, the more time goes by,
and the faster
Post by Daniel Foesch
some things run. The less we call it, the slowing
the timing is, and
Post by Daniel Foesch
the computer acts slower.
On Apr 2, 2005 2:27 AM, Andy Toulouse
Post by Andy Toulouse
I take that back. Putting stuff back to the dock,
magnification, etc. are
Post by Daniel Foesch
Post by Andy Toulouse
all faster, but there's something about it that
feels like it's off. It's
Post by Daniel Foesch
Post by Andy Toulouse
running, then walking, then running, then
walking...it's better, but feels
Post by Daniel Foesch
Post by Andy Toulouse
weird.
On Apr 1, 2005 1:05 PM, Andy Toulouse
Post by Andy Toulouse
For some odd reason, it feels like this "hack"
made my emulation slower.
Post by Daniel Foesch
Post by Andy Toulouse
How do I check?
Post by Andy Toulouse
On Apr 1, 2005 9:48 AM, Daniel Foesch
On Apr 1, 2005 9:32 AM, Chris Case
Post by Chris Case
Here's a question... what about us linux
people? This sounds like a
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
Post by Chris Case
windows only change... right?
On Apr 1, 2005 8:14 AM, lars
Post by lars
Ok, you may download PearPC (Windows version)
http://www.fivetechsoft.com/files/ppc.zip
I promise it has no viruses, trojans, or
whatever.
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
Post by Chris Case
Post by lars
The fastest PearPC ever seen
Lars
This change can easily be applied to
src/osapi/posix/systimer.cc
Post by Daniel Foesch
Post by Andy Toulouse
just
Post by Andy Toulouse
as it was for windows.
But let me reiterate. This is an invalid
emulation, and should not be
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
done if you want an accurate emulation that will
not lose time. This
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
is merely a hack, and will not be accepted into
any future versions as
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
is.
But it does have me thinking, so don't worry.
I'll get something that
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
is both accurate, and speedy.
--
Daniel Foesch,
PearPC Developer
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT
Products from real users.
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
Discover which products truly live up to the
hype. Start reading now.
Post by Daniel Foesch
Post by Andy Toulouse
Post by Andy Toulouse
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
-------------------------------------------------------
Post by John Kielkopf
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT
Products from real users.
Discover which products truly live up to the hype.
Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Post by John Kielkopf
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
__________________________________
Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun.
http://www.advision.webevents.yahoo.com/emoticontest
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
Stefan Reinauer
2005-04-02 15:06:52 UTC
Permalink
Post by Jens von der Heydt
why don't you unsubscribe from the list then!?!?!?
Jens
Post by cory graves
STOP SENDING ME E-MAILES I WILL SUE YOU IF YOU DON'T
STOP.
It was his contribution to the first of April ;-) Sad enough it wasn't
really funny ;-))
lars
2005-04-02 12:48:53 UTC
Permalink
I have uploaded a new PearPC build with a dynamic way to test and fine tune
the hack:

http://www.fivetechsoft.com/files/ppcs.zip

On the window system menu you will see a new item, click on it and select to
use the standard CPU speed or try with different values for your machine.
You can change from one to the other on the fly and make your tests.

Important: You should wait until MacOSX desktop is shown to change the
speed. This guaranties that it may not crash on the startup :-)

I appreciate your tests feedback at the development forum at pearpc.net.
Have fun :-)

Lars
lars
2005-04-02 13:30:14 UTC
Permalink
Trygvebw,
Post by trygvebw
Lars: Does your version support altivec?
I am using G4 version. I have not tested Altivec yet :-)

Regards,

Lars
lars
2005-04-02 14:00:50 UTC
Permalink
Andrew,
Post by Andrew Manchneko
Lars, maybe its just me but i only see a very marginal speed improvement
if any.

Have a look at the recently published ppcs.zip where you may properly fine
tune for your machine:

http://www.fivetechsoft.com/files/ppcs.zip

Click on the system menu, once the OSX desktop is launched, to test
different speeds.

Regards,

Lars
lars
2005-04-02 14:27:01 UTC
Permalink
Daniel,
This change breaks the very purpose that the sys_get_hiresclk_ticks does.

If you break specs, then of course you can make it go faster.

Find a faster way to implement the function that actually works. Do not use
this function as given.
I fully agree with you, Daniel. My tests just revealed that we can go
faster. Now we need to find the rigth way to do it :-)


Lars
Jens von der Heydt
2005-04-02 14:38:45 UTC
Permalink
Post by lars
Daniel,
This change breaks the very purpose that the sys_get_hiresclk_ticks does.
If you break specs, then of course you can make it go faster.
Find a faster way to implement the function that actually works. Do not use
this function as given.
I fully agree with you, Daniel. My tests just revealed that we can go
faster. Now we need to find the rigth way to do it :-)
Lars
That's not exactly true, Lars. I'm sorry, but what it reveals is that
we can break the timing and what you may experience as being faster
is actually based on the broken timing.

For example, take this spinning thing when booting OS X. Ok, it's spinning
faster with your code, but it does so because the timebase it is using to
calculate it's rotation etc is broken.

Same with the "About this Mac" - MHz display. This little prog runs
a rough benchmark to find out the MHz of the CPU. Benchmark rely
on correct time measurements. Since you broke it, the value displayed
is wrong. If I told you to time me running 100 meters without a stopwatch
and you had to count from 1 to x, the result wouldn't actually be
accurate :)


But what you found is a function that maybe needed to be rewritten
because it is called that often

Jens
Andy Toulouse
2005-04-02 14:50:52 UTC
Permalink
Jens, I quite disagree. The performance was much better, even though the
consistency was, if anything, a lot worse. I minimized the button to the
dock, and I could actually see it go, for once. Programs started faster, and
as a whole the speed went up. I agree that changing the function might
possibly be used to speed up PearPC, and that we need to find the right
(non-broken) way to do it -- consistency matters, too. In the
casual/unwashed user's eyes, having it run fast is preferable to having it
run consistently.
Post by Jens von der Heydt
Post by lars
Daniel,
This change breaks the very purpose that the sys_get_hiresclk_ticks does.
If you break specs, then of course you can make it go faster.
Find a faster way to implement the function that actually works. Do not
use
Post by lars
this function as given.
I fully agree with you, Daniel. My tests just revealed that we can go
faster. Now we need to find the rigth way to do it :-)
Lars
That's not exactly true, Lars. I'm sorry, but what it reveals is that
we can break the timing and what you may experience as being faster
is actually based on the broken timing.
For example, take this spinning thing when booting OS X. Ok, it's spinning
faster with your code, but it does so because the timebase it is using to
calculate it's rotation etc is broken.
Same with the "About this Mac" - MHz display. This little prog runs
a rough benchmark to find out the MHz of the CPU. Benchmark rely
on correct time measurements. Since you broke it, the value displayed
is wrong. If I told you to time me running 100 meters without a stopwatch
and you had to count from 1 to x, the result wouldn't actually be
accurate :)
But what you found is a function that maybe needed to be rewritten
because it is called that often
Jens
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
varname
2005-04-02 15:08:16 UTC
Permalink
I was just wondering if anyone else was having problems with the list not
distributing messages in chronological order? I get replies before the
original post and 'replays' of messages (spread over last two days).
Jens von der Heydt
2005-04-02 15:45:05 UTC
Permalink
Post by varname
I was just wondering if anyone else was having problems with the list not
distributing messages in chronological order? I get replies before the
original post and 'replays' of messages (spread over last two days).
yes, me too. Seams like sourceforge's mailserver is misbehaving.

Jens
trygvebw
2005-04-02 18:05:04 UTC
Permalink
Only happened to me with a few messages. Quite irritating, though.

trygvebw
Post by Jens von der Heydt
Post by varname
I was just wondering if anyone else was having problems with the list not
distributing messages in chronological order? I get replies before the
original post and 'replays' of messages (spread over last two days).
yes, me too. Seams like sourceforge's mailserver is misbehaving.
Jens
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
Sebastian Biallas
2005-04-02 23:21:56 UTC
Permalink
Post by varname
I was just wondering if anyone else was having problems with the list not
distributing messages in chronological order? I get replies before the
original post and 'replays' of messages (spread over last two days).
Me too. Just ignore it. As long as the people get the reference-headers
right and quote the relevant parts I see no problems.

I have the strange feeling that the SF mailing list system like some
people more than others.. For example messages from Jens apear almost
instantanly for me ;)

Sebastian
lars
2005-04-02 14:34:38 UTC
Permalink
Daniel,

How may we implement this in gcc ?

asm
db $0F; db $31; {BASM doesn't support RDTSC}
{Pentium RDTSC - Read Time Stamp Counter - instruction}
{$ifdef Cpu386}
mov [TimeStamp.Lo],eax // the low dword
mov [TimeStamp.Hi],edx // the high dword


I am used to Borland, not gcc.


Lars
Jens von der Heydt
2005-04-02 14:43:20 UTC
Permalink
there's already something defined in jitc_debug.h :

static inline UNUSED uint64 jitcDebugGetTicks()
{
uint32 s0, s1;
asm("rdtsc" : "=a" (s0), "=d" (s1));
return ((uint64)s1)<<32 | s0;
}

you can use that one.

Jens
Post by lars
Daniel,
How may we implement this in gcc ?
asm
db $0F; db $31; {BASM doesn't support RDTSC}
{Pentium RDTSC - Read Time Stamp Counter - instruction}
{$ifdef Cpu386}
mov [TimeStamp.Lo],eax // the low dword
mov [TimeStamp.Hi],edx // the high dword
I am used to Borland, not gcc.
Lars
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
lars
2005-04-02 15:09:03 UTC
Permalink
John,
I did that test yesterday and does not work because the ticks increments are
not constants.

i.e.: one call th the function may get the ticks increased in200, and the
next maybe 150, and the next maybe 800...


Lars
lars
2005-04-02 15:17:32 UTC
Permalink
Jens,
But what you found is a function that maybe needed to be rewritten
because it is called that often
That was my first intention, after profiling PearPC, but I guess that we
have discovered something else.

My "quick & dirty" hack revealed that PearPC _can_ perform a faster
emulation. The timing is completely broken, right, and has to be fixed.

But, how may we improve the emulation speed based on these tests ? Thats the
point.

Lars
lars
2005-04-02 16:45:35 UTC
Permalink
Jens,

OK, I got a new build using "rdtsc" and now the timings seem ok and is
running quite fast! :-)

I am going to publish it to see what the users say :-)


Lars
Jens von der Heydt
2005-04-02 20:58:27 UTC
Permalink
Post by lars
Jens,
OK, I got a new build using "rdtsc" and now the timings seem ok and is
running quite fast! :-)
I am going to publish it to see what the users say :-)
Lars
Yes, it's running quite nice, though the timing seems to be slower than
it has to be. If you boot OS X and have the clock display the seconds,
you'll notice (at least with my amd 2000+) that the
emulated clock changes seconds every 4 wall clock seconds.

Is there a way to fix this? But after all it everything seems to run
more smoothly....

Jens
lars
2005-04-02 17:05:12 UTC
Permalink
I got a new build using "rdtsc" and now the timings seem ok and is running
quite fast! :-)

BTW, I realized that "rdtsc" and QueryPerformanceCounter() report different
values (I confirmed this at Google), so I had to do some tests to find a
proper equivalence.

The main thing is that the timings are proportional and this is the good
thing, so PearPC seems to be running ok :-)


Lars
Shawn Christopher
2005-04-02 17:33:15 UTC
Permalink
Forgive me for trying to butt in on something that I don't know how to
do but maybe I can plant a seed of logic or something or another here.
What I think might be a plausible idea however might cause some issues.

Is it possible to have the timer called less often however jump
with an increment? I think maybe have a sys_get_hiresclk_ticks +
(incremented value) WHICH BTW is not a code just a logic idea that I
have to compensate for the lack in running the process. I think reading
Daniel/Jens e-mails they said it runs 4 million times? If it ran only 2
or 1 million times and have the incremented value doubled or tripled
how would this impact the system?

Does the sys_get_hiresclk_ticks account for milliseconds/seconds?
If so this may be able to follow the above guidelines? I don't know but
_I_ don't care how many milliseconds or seconds my Mac is off. I will
accept all laughter at my idea I'm just throwing my two cents in though.

Shawn
lars
2005-04-02 19:58:07 UTC
Permalink
Rick,
Why are you bothering to optimize something that constitutes 0.77% of the
total execution time. I would think that you would want to look at
functions that are actually taking a fair amount of time.
It is not cause the 0.77%

The fact is that sys_get_hiresclk_ticks() returned values have a real impact
on the overall PearPC OSX emulation.

IMO the main problem with PearPC is its performance speed. I guess Sebastian
and Daniel fine tuned PearPC the best they could, but it seems that changing
sys_get_hiresclk_ticks() the system is much more responsive.

I use to manage a Mac Mini using VNC on a lan, and now PearPC goes almost at
the same speed. Thats why I think PearPC timing should be revised.

Regards,

Lars
Jens von der Heydt
2005-04-02 20:24:47 UTC
Permalink
would you ming posint the code?

jens
Post by lars
Rick,
Why are you bothering to optimize something that constitutes 0.77% of the
total execution time. I would think that you would want to look at
functions that are actually taking a fair amount of time.
It is not cause the 0.77%
The fact is that sys_get_hiresclk_ticks() returned values have a real impact
on the overall PearPC OSX emulation.
IMO the main problem with PearPC is its performance speed. I guess Sebastian
and Daniel fine tuned PearPC the best they could, but it seems that changing
sys_get_hiresclk_ticks() the system is much more responsive.
I use to manage a Mac Mini using VNC on a lan, and now PearPC goes almost at
the same speed. Thats why I think PearPC timing should be revised.
Regards,
Lars
lars
2005-04-02 20:39:50 UTC
Permalink
Jens,
Post by Jens von der Heydt
would you ming posint the code?
uint64 sys_get_hiresclk_ticks()
{
static uint64 old = 0;
static uint64 total = 0;
uint64 now, val;
uint32 s0, s1;

asm( "rdtsc" : "=a" (s0), "=d" (s1) );

now = ((uint64)s1)<<32 | s0;

if( old == 0 )
old = now - 100000;

if( now > old )
val = ( now - old ) / 2000;
else
val = ( old - now ) / 2000;

old = now;
return total += val;
}

Lars
Sebastian Biallas
2005-04-02 23:18:07 UTC
Permalink
Post by lars
Jens,
Post by Jens von der Heydt
would you ming posint the code?
uint64 sys_get_hiresclk_ticks()
{
[..]
Post by lars
asm( "rdtsc" : "=a" (s0), "=d" (s1) );
Think how we do this on Linux. We would have done it this way on Windows
too, if we knew how to get the processor/tsc speed in a
(windows-)portable way...
Post by lars
Lars
Sebastian
Daniel Foesch
2005-04-02 23:34:55 UTC
Permalink
uint64 get_tsc_per_second()
{
uint64 old, new;

__asm__ __volatile__ asm("rdtsc", "=A"(old));

sleep(1000);

__asm__ __volatile__ asm("rdtsc", "=A"(new));

return new - old;
}
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by lars
Jens,
Post by Jens von der Heydt
would you ming posint the code?
uint64 sys_get_hiresclk_ticks()
{
[..]
Post by lars
asm( "rdtsc" : "=a" (s0), "=d" (s1) );
Think how we do this on Linux. We would have done it this way on Windows
too, if we knew how to get the processor/tsc speed in a
(windows-)portable way...
Post by lars
Lars
Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBQk8oL/81M8QtvOSJAQIljggAgRwupLv6JWa/HKReivaU69/arPsdrGWE
VfHia1c1tae09NwZDI1x6CuoDgwIhBdFQNqyja5VAPXazHLXvi2ks05VYz2HS5o2
rwQPRGPh8W2Yf0RY2s9YKBXMGk5nzs5HtC76Z/Mw8pL6xlcVXngyzZjZLcE3RsJb
BrZNRdtp0xtSNglAGk/9DH7izUkcDMzP4H/4IAJeDWAduj+uftZvxeJaFSwgkbUY
xSuvu5LNWsi37HhD2jA1k3kAhqzu5uR1P5RzPsq4WDZSqxqLGo96nHrvIJpDJZPu
0FjrAHRrO+SauvB1YgaxCYUxt0C62F6fMGlTBNd4FAFBWS0qCopTLw==
=MxMZ
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
--
Daniel Foesch,
PearPC Developer
Sebastian Biallas
2005-04-03 00:17:26 UTC
Permalink
Post by Daniel Foesch
uint64 get_tsc_per_second()
{
uint64 old, new;
__asm__ __volatile__ asm("rdtsc", "=A"(old));
sleep(1000);
__asm__ __volatile__ asm("rdtsc", "=A"(new));
return new - old;
}
Do you mean Sleep instead of sleep? Then this would wait 1 s for every
PearPC start. So we had to cache this somehow... And I don't know how
accurate Sleep is.

Can somebody test this? If it archives accurate values we can take this
solution.

Sebastian
Daniel Foesch
2005-04-03 00:23:29 UTC
Permalink
Well, we could also use delay() which works in millisecond increments.
Pause for maybe a quarter of a second or so, and then multiply the
value by 4 or whatever.

The less we wait the more we risk losing significant values. And
really. Oh big deal... we wait a second during start up. At some
point, it just doesn't really make a difference. Is a second pause at
start up, *that* big a deal?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Daniel Foesch
uint64 get_tsc_per_second()
{
uint64 old, new;
__asm__ __volatile__ asm("rdtsc", "=A"(old));
sleep(1000);
__asm__ __volatile__ asm("rdtsc", "=A"(new));
return new - old;
}
Do you mean Sleep instead of sleep? Then this would wait 1 s for every
PearPC start. So we had to cache this somehow... And I don't know how
accurate Sleep is.
Can somebody test this? If it archives accurate values we can take this
solution.
Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBQk82Fv81M8QtvOSJAQLQxwgAgeoNePFsuiGDvBhARZXoK2lkSIQd1KHY
aPgO8UVgnd2ILgC7kgc32LC9S0y1fcd6f3y9qwhl9KsAWVq8K+N+/v5g25Mi8/By
p6IRVOImB3E1twWy8DHkf46kGlJJu60TBfgWwGkdhapdxFwJTVzfebg5G7VlFW1K
9vdNFgGpuBnUq4/ZZKefwLweiWIL2jCpEBMzkae/+Fcdt+xcK/PCPlfTITAiGTTU
C3zZh/H+oVj9CnXjtKEfbnzZ5ZjmHXdjYgZQduFmMps767tGIa3dUZ+M9AL3aBhU
K6l3w/A1IWUfoTOaRjYY8TfMbnqXmIhHV6uyp9r3SyNcy/pdu80OWQ==
=l9LK
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
--
Daniel Foesch,
PearPC Developer
lars
2005-04-02 21:09:22 UTC
Permalink
Jens,
Is there a way to fix this? But after all it everything seems to run more
smoothly....

As Daniel has commented at pearpc.net devel forum, we need to change
sys_get_hiresclk_ticks_per_second() to properly fit with the pentium "rdtsc"
returned values.

If we do that, then we will have avoided the Win32 function call and the
timing will be ok.

Anyhow, his comment gave me another idea so I am going to do some new tests
now :-)


Lars
Andy Toulouse
2005-04-02 21:15:53 UTC
Permalink
Wow! I can finally see the window minimizing itself to the dock! Though the
4:1 second bug is still there, emulated OS X just got a lot more bearable to
use.
Post by Jens von der Heydt
Jens,
Post by Jens von der Heydt
Is there a way to fix this? But after all it everything seems to run
more
smoothly....
As Daniel has commented at pearpc.net <http://pearpc.net> devel forum, we
need to change
sys_get_hiresclk_ticks_per_second() to properly fit with the pentium "rdtsc"
returned values.
If we do that, then we will have avoided the Win32 function call and the
timing will be ok.
Anyhow, his comment gave me another idea so I am going to do some new tests
now :-)
Lars
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
Brian Onn
2005-04-02 22:12:29 UTC
Permalink
Lars,

Good work so far identifying this bottleneck and attempting some
solutions. Here's some suggestions:

Remember that RDTSC is counting clock cycles, not a high-res timer, and so
it's going to be different on every single person's system.

You need to figure out, on every single machine, at startup, how many
clock cycles transpire in some constrained time, for example, 1 usec, if
that's what the original timer returned.

Your posted code won't work on all hardware. The constants need to be
determined at run time.

Also note that not all systems support RDTSC, so you need to dynamically
determine at run time if the CPU supports it and fall back to a different
system or the original system if the host CPU can't support it.

-- Brian
Post by Jens von der Heydt
Jens,
Is there a way to fix this? But after all it everything seems to run more
smoothly....
As Daniel has commented at pearpc.net devel forum, we need to change
sys_get_hiresclk_ticks_per_second() to properly fit with the pentium "rdtsc"
returned values.
If we do that, then we will have avoided the Win32 function call and the
timing will be ok.
Anyhow, his comment gave me another idea so I am going to do some new tests
now :-)
Daniel Foesch
2005-04-02 22:17:03 UTC
Permalink
Post by Brian Onn
Also note that not all systems support RDTSC, so you need to dynamically
determine at run time if the CPU supports it and fall back to a different
system or the original system if the host CPU can't support it.
All pentiums and higher support it.

I don't mean to sound like a jerk here, but if you're not using a
pentium, you shouldn't be running PearPC.
--
Daniel Foesch,
PearPC Developer
Brian Onn
2005-04-02 22:32:18 UTC
Permalink
Post by Daniel Foesch
Post by Brian Onn
Also note that not all systems support RDTSC, so you need to dynamically
determine at run time if the CPU supports it and fall back to a different
system or the original system if the host CPU can't support it.
All pentiums and higher support it.
I don't mean to sound like a jerk here, but if you're not using a
pentium, you shouldn't be running PearPC.
I run it on an Athlon 64, so it's ok for me. I believe in making all code
bullet proof, and not explode when someone starts it on a system that
doesn't have the instruction, especially if we know in advance of the
potential to blow up.

$ ppc ppc.cfg
Illegal instruction (core dumped)

Cheers!
--- Brian
Daniel Foesch
2005-04-02 22:51:23 UTC
Permalink
I believe in bulletproof also. But no one is going to run PearPC on a
486 or ealier.

Unless they're crazy. In that case, they can patch the code themselves.
Post by Brian Onn
Post by Daniel Foesch
Post by Brian Onn
Also note that not all systems support RDTSC, so you need to dynamically
determine at run time if the CPU supports it and fall back to a different
system or the original system if the host CPU can't support it.
All pentiums and higher support it.
I don't mean to sound like a jerk here, but if you're not using a
pentium, you shouldn't be running PearPC.
I run it on an Athlon 64, so it's ok for me. I believe in making all code
bullet proof, and not explode when someone starts it on a system that
doesn't have the instruction, especially if we know in advance of the
potential to blow up.
$ ppc ppc.cfg
Illegal instruction (core dumped)
Cheers!
--- Brian
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
--
Daniel Foesch,
PearPC Developer
Jens von der Heydt
2005-04-02 22:55:35 UTC
Permalink
Post by Daniel Foesch
I believe in bulletproof also. But no one is going to run PearPC on a
486 or ealier.
Unless they're crazy. In that case, they can patch the code themselves.
Remember that cmov desaster? it's in the code.....so we should make a point
if we supported pentium and above or the old CPUs as well.

j
Daniel Foesch
2005-04-02 23:03:39 UTC
Permalink
CMOV can be checked for the compatibilty. RDTSC cannot.

We say that PearPC is Pentium req or higher, problem solved. If they
try and run it on a 486, and it crashes, we say, "we said it required
a Pentium or higher".
Post by Jens von der Heydt
Post by Daniel Foesch
I believe in bulletproof also. But no one is going to run PearPC on a
486 or ealier.
Unless they're crazy. In that case, they can patch the code themselves.
Remember that cmov desaster? it's in the code.....so we should make a point
if we supported pentium and above or the old CPUs as well.
j
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
--
Daniel Foesch,
PearPC Developer
Brian Onn
2005-04-02 23:21:13 UTC
Permalink
Post by Daniel Foesch
CMOV can be checked for the compatibilty. RDTSC cannot.
I believe RDTSC can also be checked, but not from my personal experience
with it.

I found some code at a source exchange site. I've only had a cursory look
at this code

http://c.ittoolbox.com/code/d.asp?d=1441&a=s

It's Windows only code, but here's the summary:

Summary: A Timer class that uses rdtsc and falls back on TimeGetTime( )
if rdtsc is unavailable


-- Brian
Sebastian Biallas
2005-04-03 00:01:34 UTC
Permalink
Post by Daniel Foesch
CMOV can be checked for the compatibilty. RDTSC cannot.
Well, actually it can.
http://www.sandpile.org/ia32/cpuid.htm
But are there really CPUs without RDTSC which also could run PearPC?
Post by Daniel Foesch
We say that PearPC is Pentium req or higher, problem solved. If they
try and run it on a 486, and it crashes, we say, "we said it required
a Pentium or higher".
We could check it at least and print an error. I'll add that.

Sebastian
Clemens Brust
2005-04-02 22:56:20 UTC
Permalink
As far as my x86 asm goes, rdtsc puts the value of the counter into eax.



_____

From: pearpc-devel-***@lists.sourceforge.net
[mailto:pearpc-devel-***@lists.sourceforge.net] On Behalf Of Andy Toulouse
Sent: Samstag, 2. April 2005 22:16
To: pearpc-***@lists.sourceforge.net
Subject: Re: [Pearpc-devel] A much much faster PearPC !!!



Wow! I can finally see the window minimizing itself to the dock! Though the
4:1 second bug is still there, emulated OS X just got a lot more bearable to
use.

On Apr 2, 2005 1:09 PM, lars <***@yahoo.es> wrote:

Jens,
Is there a way to fix this? But after all it everything seems to run more
smoothly....

As Daniel has commented at pearpc.net devel forum, we need to change
sys_get_hiresclk_ticks_per_second() to properly fit with the pentium "rdtsc"
returned values.

If we do that, then we will have avoided the Win32 function call and the
timing will be ok.

Anyhow, his comment gave me another idea so I am going to do some new tests
now :-)


Lars


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595
<http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click>
&alloc_id=14396&op=click
Daniel Foesch
2005-04-02 22:00:59 UTC
Permalink
Post by Clemens Brust
As far as my x86 asm goes, rdtsc puts the value of the counter into eax.
Not just eax, it puts it into edx:eax. The value returned is 64-bit.
--
Daniel Foesch,
PearPC Developer
Rick Altherr
2005-04-02 22:06:20 UTC
Permalink
Jens von der Heydt
2005-04-02 22:19:21 UTC
Permalink
Rick Altherr wrote:
Brian Onn
2005-04-02 22:25:45 UTC
Permalink
On Sat, 2 Apr 2005 17:06:20 -0500, Rick Altherr <***@apple.com> wrote:
Daniel Foesch
2005-04-02 22:29:40 UTC
Permalink
Brian Onn
2005-04-02 22:36:20 UTC
Permalink
Then sys_get_hiresclk_ticks() merely becomes a call to read the
internal
value and doesn't execute rdtsc directly itself.
This is likely exactly what quickPerformanceTicks,or whatever it is
that we're trying to replace does.
It would be sadly ironic if we come full-circle. :)

-- Brian
lars
2005-04-02 22:04:27 UTC
Permalink
Clemens,
Post by Clemens Brust
As far as my x86 asm goes, rdtsc puts the value of the counter into eax.
How may we get the right value for sys_get_hiresclk_ticks_per_second() ?


Lars
lars
2005-04-02 22:19:37 UTC
Permalink
Jens von der Heydt
2005-04-02 22:23:29 UTC
Permalink
Brian,
You need to figure out, on every single machine, at startup, how many clock
cycles transpire in some constrained time, for example, 1 usec, if that's
what the original timer returned.
How may we do that ? :-)
Lars
As strange as it sounds,

measure the hires timers for a certain time.

For example you time the clock cycles that pass in a given time frame
and use that as a later constant, you could also do that
like 3-10 times in a row to get a better value. Something like that.
I'd say you can find many examples on the net. Benchmark
utils for HDs use this kind of stuff, for example.

Jens
Sebastian Biallas
2005-04-02 23:14:10 UTC
Permalink
Post by Andreu Escudero
Hello everyone, I have a strange problem when using pearpc in my
debian sarge system when running with a 2.6.11 kernel. Everything
seems OK, pearpc starts right as always, but every mouse movement
makes a BIG jump, down-left, until the mouse cursos reaches the lower
end of the screen and dissapears. I have the same problem both in the
main and the altivec branch of cvs, both compiled with gcc 3.3.5, but
exact the same ppc binaries work without any problems when using a
host with 2.6.10, 2.6.9 or 2.6.8 kernel.
The 2.6.11 is self-compiled, with basically the same options as I
always have for my laptop.
Anyone knows something about this problem? or anyone has been able to
use it correctly in a machine with a 2.6.11 linux kernel?
Do you use X11 or SDL?
Post by Andreu Escudero
thanks
Sebastian
Charles Darvy
2005-04-02 23:29:00 UTC
Permalink
Post by Brian Onn
Post by Daniel Foesch
CMOV can be checked for the compatibilty. RDTSC cannot.
I believe RDTSC can also be checked, but not from my personal experience
with it.
I found some code at a source exchange site. I've only had a cursory look
at this code
http://c.ittoolbox.com/code/d.asp?d=1441&a=s
Summary: A Timer class that uses rdtsc and falls back on TimeGetTime( )
if rdtsc is unavailable
I also noticed an interesting PDF:

"Using the RDTSC Instruction for Performance Monitoring"
http://www.math.uwaterloo.ca/~jamuir/rdtscpm1.pdf
Google cache version:
http://64.233.179.104/search?q=cache:83XkokJJcC0J:www.math.uwaterloo.ca/~jamuir/rdtscpm1.pdf+RDTSC&hl=en

CONTENTS:
1.0. Introduction
2.0. The Time-Stamp Counter
2.1. How the Time-Stamp Counter Works
2.2. When to use the Time-Stamp Counter
2.3. Compiler Issues with RDTSC
3.0. Issues Affecting the Cycle Count
3.1. Out-of-Order Execution
3.2. Data Cache and Instruction Cache
3.3. Register Overwriting
3 .4. Counter Overflow
4.0. Using RDTSC Properly
4.1. Pentium® Pro Processors and Pentium® II Processors
4.2. Pentium® Processors and Pentium® with MMXTM Technology
5.0. Conclusion
A.0. Appendix: Code Samples
A.1. Using CPUID for Serialization
A.2. Taking a Time Average for a Repeated Code Section
A.3. Testing a Small Code Section for Repeatable Results

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
lars
2005-04-03 00:01:29 UTC
Permalink
Daniel,

I already tested that and it does not works :(
uint64 get_tsc_per_second()
{
uint64 old, new;

__asm__ __volatile__ asm("rdtsc", "=A"(old));

sleep(1000);

__asm__ __volatile__ asm("rdtsc", "=A"(new));

return new - old;
}
Rick Altherr
2005-04-03 00:11:24 UTC
Permalink
This has a number of issues. First, the rdtsc value continues to
increase even when the PearPC process is not running. Second,
sleep(1000) is to sleep 1000 seconds, not one second. Third, sleep
does not necessarily come back after the exact time specified. If
another thread of higher priority is running, the sleeping process may
get preempted on a UP system and not actually resume running until a
little after the amount of time specified has elapsed.
--
Rick Altherr
Architecture and Performance Group
Post by lars
Daniel,
I already tested that and it does not works :(
uint64 get_tsc_per_second()
{
uint64 old, new;
__asm__ __volatile__ asm("rdtsc", "=A"(old));
sleep(1000);
__asm__ __volatile__ asm("rdtsc", "=A"(new));
return new - old;
}
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real
users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
Daniel Foesch
2005-04-03 00:18:07 UTC
Permalink
Alright, sleep(1), still, wait a second. It's Pseudocode

Second, we don't need it to be perfectly accurate. We throw out some
of the least significant values, so we pretty much don't care.
Post by Rick Altherr
This has a number of issues. First, the rdtsc value continues to
increase even when the PearPC process is not running. Second,
sleep(1000) is to sleep 1000 seconds, not one second. Third, sleep
does not necessarily come back after the exact time specified. If
another thread of higher priority is running, the sleeping process may
get preempted on a UP system and not actually resume running until a
little after the amount of time specified has elapsed.
--
Rick Altherr
Architecture and Performance Group
Post by lars
Daniel,
I already tested that and it does not works :(
uint64 get_tsc_per_second()
{
uint64 old, new;
__asm__ __volatile__ asm("rdtsc", "=A"(old));
sleep(1000);
__asm__ __volatile__ asm("rdtsc", "=A"(new));
return new - old;
}
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real
users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel
--
Daniel Foesch,
PearPC Developer
Loading...