Rene Herman wrote on 12-12-07 00:31:
Good day.
Would some people on x86 (both 32 and 64) be kind enough to compile and
run the attached program? This is about testing how long I/O port access
to port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
reporting.
Compiled as you
Rene Herman wrote:
> On 13-12-07 17:27, James Kosin wrote:
>
>> model name : Pentium III (Katmai)
>> cpu MHz : 499.156
>
>> [EMAIL PROTECTED] jkosin]# ./a.out
>> cycles: out 683, in 299
>
> Thanks much, you made spot 32 ;-)
>
> http://lkml.org/lkml/2007/12/12/309
>
> By the way, i
On 13-12-07 23:30, Jesper Juhl wrote:
On 13/12/2007, Rene Herman <[EMAIL PROTECTED]> wrote:
http://lkml.org/lkml/2007/12/12/309
By the way, if anyone in this/these thread(s) wrote something today (*) they
would like me to reply to -- my horseshit ISP is completely crapping out on
me and I ha
On 13/12/2007, Rene Herman <[EMAIL PROTECTED]> wrote:
> On 13-12-07 17:27, James Kosin wrote:
>
> > model name : Pentium III (Katmai)
> > cpu MHz : 499.156
>
> > [EMAIL PROTECTED] jkosin]# ./a.out
> > cycles: out 683, in 299
>
> Thanks much, you made spot 32 ;-)
>
> http://lkml.org/lkm
On 13-12-07 17:27, James Kosin wrote:
model name : Pentium III (Katmai)
cpu MHz : 499.156
[EMAIL PROTECTED] jkosin]# ./a.out
cycles: out 683, in 299
Thanks much, you made spot 32 ;-)
http://lkml.org/lkml/2007/12/12/309
By the way, if anyone in this/these thread(s) wrote somet
Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and
> run the attached program? This is about testing how long I/O port access
> to port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
> reporting.
>
> Posted a previous incar
On Wed, Dec 12, 2007 at 01:57:01PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
> > Good day.
> >
> > Would some people on x86 (both 32 and 64) be kind enough to compile and run
> > the attached program? This is about testing how long I/O port access t
Rene Herman napsal(a):
> On 12-12-07 19:44, H. Peter Anvin wrote:
>
>>> model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
>>> cycles: out 3217, in 1898
>>
>> 1.6 µs, on the high end
>>
>>> model name : Dual Core AMD Opteron(tm) Processor 275
>>> cycles: out 5508, in 5524
>
Rene Herman wrote:
On 12-12-07 06:23, Kyle McMartin wrote:
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
asm volatile ("rdtsc": "=A" (tsc));
rdtsc returns a 64-bit value in two 32-bit regs, you need to do
inline unsigned long long rdtsc(void)
{
unsigned int lo, hi;
Jan Engelhardt wrote:
On Dec 12 2007 00:31, Rene Herman wrote:
Would some people on x86 (both 32 and 64) be kind enough to compile and run the
attached program? This is about testing how long I/O port access to port 0x80
takes. It measures in CPU cycles so CPU speed is crucial in reporting.
T
On Dec 13 2007 00:54, Jan Engelhardt wrote:
>
>Transmeta TM5800 CPU with nominal frequency 933 MHz, but it has a
>hardware(!) 'ondemand' governor over the range of frequencies that
>the user allowed scaling over, irrespective of the software governor.
>(That is, if the CPU can do 300,533 and 933 M
On Dec 12 2007 00:31, Rene Herman wrote:
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the
> attached program? This is about testing how long I/O port access to port 0x80
> takes. It measures in CPU cycles so CPU speed is crucial in reporting.
>
Transmeta TM58
On 12/12/2007, Rene Herman <[EMAIL PROTECTED]> wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporti
Rene Herman wrote:
On 12-12-07 01:09, Alejandro Riveira Fernández wrote:
On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
cycles: out 1844674407370808, in 1844674407369087
It is not constant but variations are not significant afaics
Eh, oh, I guess you need to compile as a 32-bit b
Andi Kleen wrote:
"=A" works on 32-bit systems (only), obviously, and gcc will generally
produce slightly better code as a result (gcc could really use a
register renaming/copy propagation step *after* multi-register entities
I believe gcc 4.3 (or maybe 4.2) does that already -- it splits the
> "=A" works on 32-bit systems (only), obviously, and gcc will generally
> produce slightly better code as a result (gcc could really use a
> register renaming/copy propagation step *after* multi-register entities
I believe gcc 4.3 (or maybe 4.2) does that already -- it splits them much
earlie
Kyle McMartin wrote:
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
asm volatile ("rdtsc": "=A" (tsc));
rdtsc returns a 64-bit value in two 32-bit regs, you need to do
inline unsigned long long rdtsc(void)
{
unsigned int lo, hi;
asm volatile ("rdtsc": "=a
On 12-12-07 19:44, H. Peter Anvin wrote:
model name : Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
cycles: out 3217, in 1898
1.6 µs, on the high end
model name : Dual Core AMD Opteron(tm) Processor 275
cycles: out 5508, in 5524
Definitely an outlier; 2.5 µs here.
Jah, I
On 12-12-07 19:39, SL Baur wrote:
model name : Intel(R) Pentium(R) 4 CPU 3.20GHz
cpu MHz : 3201.345
cycles: out 3026, in 2204
cycles: out 3031, in 2182
cycles: out 3019, in 2196
cycles: out 3030, in 2201
cycles: out 3013, in 2186
Thank you. I just posted the combined results, alt
I have been having a fun time testing this on my AMD64x2 system.
Since out's to port 80 hang the system hard after a while, I can run a
test just after booting, but the next run will typically hang it.
I did also test two ports thought to be unused. They do *not* hang the
system. Thus appa
Jiri Slaby wrote:
On Dec 12, 2007 9:48 AM, Jiri Slaby <[EMAIL PROTECTED]> wrote:
On 12/12/2007 12:31 AM, Rene Herman wrote:
Good day.
Would some people on x86 (both 32 and 64) be kind enough to compile and
run the attached program? This is about testing how long I/O port access
model name
On 12/11/07, Rene Herman <[EMAIL PROTECTED]> wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting
Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile
> and run the attached program? This is about testing how long I/O port
> access to port 0x80 takes. It measures in CPU cycles so CPU speed is
> crucial in reporting.
>
> Posted a previous incarna
Ondrej Zary wrote:
Cyrix MII PR300 (225MHz), i430TX:cycles: out 263, in 93
Pentium MMX 166MHz @133MHz, VIA VPX: cycles: out 163, in 163
Celeron 433MHz, i440BX: cycles: out 620, in 305
Celeron 1.3GHz, i440BX: cycles: out 2114, in 849
Celeron 1.7GHz (P4-based), i845:
[Rene Herman - Wed, Dec 12, 2007 at 12:31:18AM +0100]
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to
> port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
> re
On Wednesday 12 December 2007 00:31:18 Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to
> port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
> r
pancs:/tmp# for((i=0;i<20;i++)); do ./port80; done
cycles: out 4098, in 2532
cycles: out 3951, in 2389
cycles: out 4043, in 2485
cycles: out 4058, in 2393
cycles: out 4056, in 2509
cycles: out 4063, in 2394
cycles: out 4076, in 2508
cycles: out 4143, in 2395
cycles: out 4062, in 2502
cycles: out 40
On 12-12-07 10:57, Romano Giannetti wrote:
On a laptop with a CoreDuo T2080/1.73GHz, but running on battery at
800 MHz (on-demand):
cycles: out 3575, in 2844
Okay, I'm going to ignore this one. This would be 4 microsecs but there are
sleep states involved, and if a piece of hardware would
My results, PIII, Dual 550Mhz Xeon.
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
jfsnew:~/src> sudo ./port80
cycles: out 774, in 332
j
On 12-12-07 12:25, Jiri Slaby wrote:
Thanks for reporting! You have two results that are somewhat off:
Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz
cycles: out 6500, in 3135
6500 / 3000 = 2.17. Fairly high...
Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
cycles: out 3217, in 1898
3217 / 2000 = 1.61.
On 12-12-07 12:25, Jiri Slaby wrote:
Thanks for reporting! You have two results that are somewhat off:
Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz
cycles: out 6500, in 3135
6500 / 3000 = 2.17. Fairly high...
Intel(R) Xeon(R) CPU E5335 @ 2.00GHz
cycles: out 3217, in 1898
3217 / 2000 = 1.61.
On Wed, 2007-12-12 at 00:31 +0100, Rene Herman wrote:
> cc -W -Wall -O2 -o port80 port80.c
On a laptop with a CoreDuo T2080/1.73GHz, but running on battery at
800 MHz (on-demand):
(0)rukbat:~/tmp% for i in {1..10}; do
sudo ./port80
done
cycles: out 3575, in 2844
cycles: out 3589, in 2923
cycle
On Wednesday 12 December 2007 15:30, Rene Herman wrote:
> On 12-12-07 09:59, Juergen Beisert wrote:
> > $ for i in `seq 5`; do ./port80; sleep 1; done
> > cycles: out 5260, in 2372
> > cycles: out 5260, in 2384
> > cycles: out 5260, in 2323
> > cycles: out 5270, in 2382
> > cycles: out 5259, in 232
On 12-12-07 12:20, [EMAIL PROTECTED] wrote:
Here are a variety of machines:
Thanks much for all! Collecting all data now...
With -O2, the cycle counts come out (before division) as
out: 0xFFEA6F4F
in: 0xFCE68BB6
I think the "A" constraint doesn't work quite the same in
64-bi
On 12-12-07 09:59, Juergen Beisert wrote:
$ for i in `seq 5`; do ./port80; sleep 1; done
cycles: out 5260, in 2372
cycles: out 5260, in 2384
cycles: out 5260, in 2323
cycles: out 5270, in 2382
cycles: out 5259, in 2323
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu f
On Wed, 12 Dec 2007, Rene Herman wrote:
> On 12-12-07 13:59, linux-os (Dick Johnson) wrote:
>
>> On Tue, 11 Dec 2007, [utf-8] Alejandro Riveira Fern?ndez wrote:
>
>>> On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
>>>
>>> cycles: out 1844674407370808, in 1844674407369087
>>>
>>> It is no
On 12-12-07 13:59, linux-os (Dick Johnson) wrote:
On Tue, 11 Dec 2007, [utf-8] Alejandro Riveira Fern?ndez wrote:
On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
cycles: out 1844674407370808, in 1844674407369087
It is not constant but variations are not significant afaics
It look
On 12 Dec 2007 06:20:49 -0500
[EMAIL PROTECTED] wrote:
> With -O2, the cycle counts come out (before division) as
> out: 0xFFEA6F4F
> in: 0xFCE68BB6
> I think the "A" constraint doesn't work quite the same in
> 64-bit code. The compiler seems to be using %rdx rather than
> %edx:%
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to
> port 0x80 takes. It measures in CPU cycles so CPU speed is crucial i
El Wed, 12 Dec 2007 01:16:06 +0100
Rene Herman <[EMAIL PROTECTED]> escribió:
> On 12-12-07 01:09, Alejandro Riveira Fernández wrote:
[...]
>
> Great, thanks much for reporting. Sort of interesting in itself that without
> -O2 you do still get correct results on 64-bit but for some other time.
Here are a variety of machines:
600 MHz PIII (Katmai), 440BX chipset, 82371AB/EB/MB PIIX4 ISA bridge:
cycles: out 794, in 348
cycles: out 791, in 348
cycles: out 791, in 349
cycles: out 791, in 348
cycles: out 791, in 348
433 MHz Celeron (Mendocino), 440 BX chipset, same ISA bridge:
cycles: out 6
On Dec 12, 2007 9:48 AM, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> On 12/12/2007 12:31 AM, Rene Herman wrote:
> > Good day.
> >
> > Would some people on x86 (both 32 and 64) be kind enough to compile and
> > run the attached program? This is about testing how long I/O port access
model name : I
Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile
> and run the attached program? This is about testing how long I/O port
> access to port 0x80 takes. It measures in CPU cycles so CPU speed is
> crucial in reporting.
$ cat /proc/cpuinfo
processo
On Wed, 2007-12-12 at 00:31 +0100, Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in rep
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is cruc
$ for i in `seq 5`; do ./port80; sleep 1; done
cycles: out 5260, in 2372
cycles: out 5260, in 2384
cycles: out 5260, in 2323
cycles: out 5270, in 2382
cycles: out 5259, in 2323
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name
On 12/12/2007 12:31 AM, Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and
> run the attached program? This is about testing how long I/O port access
model name : Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz
cycles: out 6490, in 313
Exactly constant timing in every iteration:
cycles: out 667, in 305
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Celeron (Coppermine)
stepping: 3
cpu MHz : 497.582
cache size : 128 KB
fdiv_bug: no
hlt_bug
On Dec 12, 2007 7:31 AM, Rene Herman <[EMAIL PROTECTED]> wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial
On Wed, 12 Dec 2007 00:31:18 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
>
> and on a PII 400 (Intel 440BX chipset) a constant:
>
> [EMAIL PROTECTED]:~/src/port80$ su -c ./port80
> cycles: out 553, in 251
>
> Results are (mostly) independent of compiler optimisation, but testing with
> an -O2
On 12-12-07 06:23, Kyle McMartin wrote:
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
asm volatile ("rdtsc": "=A" (tsc));
rdtsc returns a 64-bit value in two 32-bit regs, you need to do
inline unsigned long long rdtsc(void)
{
unsigned int lo, hi;
asm vo
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
> asm volatile ("rdtsc": "=A" (tsc));
rdtsc returns a 64-bit value in two 32-bit regs, you need to do
inline unsigned long long rdtsc(void)
{
unsigned int lo, hi;
asm volatile ("rdtsc": "=a" (lo), "=d" (hi));
cycles: out 1296, in 1243
cycles: out 1312, in 1245
cycles: out 1289, in 1239
cycles: out 1309, in 1245
cycles: out 1308, in 1244
cycles: out 1325, in 1239
cycles: out 1310, in 1245
cycles: out 1289, in 1239
cycles: out 1301, in 1252
cycles: out 1325, in 1249
cycles: out 1307, in 1249
cycles: out
Rene Herman wrote:
> On 12-12-07 00:55, Nigel Cunningham wrote:
>
>> (AMD 1.8GHz Turion, running at 800MHz. ATI RS480 - Mitac 8350 mobo)
>>
>> [EMAIL PROTECTED]:~/Downloads$ gcc port80.c -o port80
>> [EMAIL PROTECTED]:~/Downloads$ sudo ./port80
>> cycles: out 1235, in 1207
>
> Looking good.
>
>>
On Wed, 12 Dec 2007 10:01:18 am Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to
> port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
> reportin
On Wed, 12 Dec 2007 00:31:18 +0100 Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in rep
On Tuesday 11 December 2007 23:31:18 Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to
> port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
> rep
On 12-12-07 01:14, Maxim Levitsky wrote:
CPU frequency locked to 2128.000 Mhz:
[EMAIL PROTECTED]:~/tmp$ sudo ./port800
cycles: out 1650, in 1065
CPU frequency locked to: 1596.000 Mhz
[EMAIL PROTECTED]:~/tmp$ sudo ./port800
cycles: out 1730, in 1138
A bit strange, isn't it?
Well, yes. Don
On 12-12-07 01:09, Alejandro Riveira Fernández wrote:
On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
cycles: out 1844674407370808, in 1844674407369087
It is not constant but variations are not significant afaics
Eh, oh, I guess you need to compile as a 32-bit binary...
I tried
On Wednesday 12 December 2007 01:44:42 Rene Herman wrote:
> On 12-12-07 00:40, Maxim Levitsky wrote:
>
> > [EMAIL PROTECTED]:~/tmp$ sudo ./port800
> > cycles: out 1767, in 1147
> > [EMAIL PROTECTED]:~/tmp$ sudo ./port800
> > cycles: out 1774, in 1148
> > [EMAIL PROTECTED]:~/tmp$ sudo ./port800
> >
El Wed, 12 Dec 2007 00:51:25 +0100
Rene Herman <[EMAIL PROTECTED]> escribió:
> On 12-12-07 00:43, Alejandro Riveira Fernández wrote:
>
> > On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
> >
> > cycles: out 1844674407370808, in 1844674407369087
> >
> > It is not constant but variatio
On 12-12-07 00:55, Nigel Cunningham wrote:
(AMD 1.8GHz Turion, running at 800MHz. ATI RS480 - Mitac 8350 mobo)
[EMAIL PROTECTED]:~/Downloads$ gcc port80.c -o port80
[EMAIL PROTECTED]:~/Downloads$ sudo ./port80
cycles: out 1235, in 1207
Looking good.
[EMAIL PROTECTED]:~/Downloads$ gcc -O2 po
Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and
> run the attached program? This is about testing how long I/O port access
> to port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
> reporting.
>
> Posted a previous incar
On 12-12-07 00:43, Alejandro Riveira Fernández wrote:
On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
cycles: out 1844674407370808, in 1844674407369087
It is not constant but variations are not significant afaics
Eh, oh, I guess you need to compile as a 32-bit binary...
Rene.
--
On 12-12-07 00:40, Maxim Levitsky wrote:
[EMAIL PROTECTED]:~/tmp$ sudo ./port800
cycles: out 1767, in 1147
[EMAIL PROTECTED]:~/tmp$ sudo ./port800
cycles: out 1774, in 1148
[EMAIL PROTECTED]:~/tmp$ sudo ./port800
cycles: out 1769, in 1150
[EMAIL PROTECTED]:~/tmp$ sudo ./port800
cycles: out 1769,
El Wed, 12 Dec 2007 00:31:18 +0100
Rene Herman <[EMAIL PROTECTED]> escribió:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU
On Wednesday 12 December 2007 01:31:18 Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
Good day.
Would some people on x86 (both 32 and 64) be kind enough to compile and run
the attached program? This is about testing how long I/O port access to port
0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting.
Posted a previous incarnation of this before, buried i
68 matches
Mail list logo
