Re: how to test and compare performance of bullseye for i386 and amd64

[a]

Sorry, last word in last mail is wrong,

it should be inconvenience, not  incontinence

Re: how to test and compare performance of bullseye for i386 and amd64

[a]

Thank David!

my mail provider blocks your reply without informing me, so i can't 
receive it on time, i get your reply by some other way


it's amazing that you get my history of getting help here,

actually i've just bought 2nd-hand pc, it's core2 Q8200, 2.33G, it's my 
fastest pc though others might think it's slow. and i'm interested in 
its performance.  my motive behind this purchase is to solve slow 
reading PDF


as to firmware complaint, i think problem is with debian, not with me, 
because other major distro (opensuse and fedora) include non-free 
firmware in their official release. but i won't switch to other distro 
for such small incontinence

Re: how to test and compare performance of bullseye for i386 and amd64

[a]

Thank Polyna-Maude Racicot-Summerside!

it's only for curiosity.

for most users, their performance have little difference

Re: how to test and compare performance of bullseye for i386 and amd64

[David Wright]

On Wed 26 Jan 2022 at 05:44:50 (-0500), Polyna-Maude Racicot-Summerside wrote:
> On 2022-01-25 19:35, David Wright wrote:
> > On Tue 25 Jan 2022 at 01:37:29 (-0500), a wrote:
> >> Thank David and Polyna-Maude!
> >>
> >> it's surprising that "The x64 binary are also somewhat larger than the
> >> i386 binaries"
> >>
> >> i compare some packages of bullseye for both arch, they happen to be
> >> contrary
> >>
> >> though difference is small and IMO has little impact on performance
> >>
> >> firefox-esr for i386: size= 58465416
> >>
> >> firefox-esr for amd64: size= 55451188
> >>
> >> gcc-10 for i386: size= 18097884
> >>
> >> gcc-10 for amd64: size=  16990272
> > 
> > Well, we've gone from ISOs containing different inventories to sizes
> > of packages. I still don't see how that affects performance.
> > 
> > All I did was to type ls -l /usr/bin for the two architectures into
> > two xterms in two viewports, and blink-compare them. Some binaries
> > were larger and some were smaller.
> > 
> > But let's try running them. I happen to have two freshly installed
> > bullseyes, and neither has run the installed FF before. Their dotfiles
> > in my home directories are close to identical, and their starting
> > pages are blank.
> > 
> > i386:
> > 
> >VSZ   RSZ %MEM  PID STAT   CMD
> > 1200184 176396 34.9   1603 Sl+firefox-esr
> > 477488 50140  9.9 1880 Sl+/usr/lib/firefox-esr/firefox-esr 
> > -contentproc -ch>
> > 467760 34188  6.7 1821 Sl+/usr/lib/firefox-esr/firefox-esr 
> > -contentproc -ch>
> > 455296 27436  5.4 1958 Sl+/usr/lib/firefox-esr/firefox-esr 
> > -contentproc -ch>
> > 
> > amd64:
> > 
> >VSZ   RSZ %MEMPID STAT   CMD
> > 3082424 408156  2.5 2538 Sl+firefox-esr
> > 2446004 146664  0.9 2662 Sl+/usr/lib/firefox-esr/firefox-esr 
> > -contentproc ->
> > 2417628 117508  0.7 2694 Sl+/usr/lib/firefox-esr/firefox-esr 
> > -contentproc ->
> > 2403264 108072  0.6 2603 Sl+/usr/lib/firefox-esr/firefox-esr 
> > -contentproc ->
> > 
> > The difference is larger than I thought it would be. Others would
> > have to interpret the actual numbers. The main difference that
> > /I/ notice is the speed, but it would be an unfair comparison,
> > pitching 1.5GHz/512MB with 1GB encrypted swap on 2004-era rust
> > against a multi-core 2.7GHz/16GB with a 2017-era SSD (but no swap).
> > Starting times come out at 3 minutes vs perhaps one second.
> > 
> Did you ask your question in a real-world intention ? I mean based on
> something you want to implement and may have resources limitation so
> want to have the most for what you got ?
> 
> Or was it only a question for "academic" purposes ? That you wanted some
> answer and explanation without any context that you can give.

The charitable interpretation I placed on "a", aka "lou", is that
they¹ have found a 32-bit-only wireless adapter, run a 32-bit
system, and are generally unimpressed by its speed.

If you remember, reading PDFs was slow, firmware-free adapters
were hard to find, and firmware-inclusive installers were elusive,
in the eyes of the OP. So, a less charitable interpretation might
be in order.

> If it's only for curiosity then there's plenty of books to read and
> you'll find answers.

Ah, PDFs. Catch 22 here.

¹ Forgive my grammar, RMS.

Cheers,
David.

Re: how to test and compare performance of bullseye for i386 and amd64

[Polyna-Maude Racicot-Summerside]

On 2022-01-25 19:35, David Wright wrote:
> On Tue 25 Jan 2022 at 01:37:29 (-0500), a wrote:
>> Thank David and Polyna-Maude!
>>
>> it's surprising that "The x64 binary are also somewhat larger than the
>> i386 binaries"
>>
>> i compare some packages of bullseye for both arch, they happen to be
>> contrary
>>
>> though difference is small and IMO has little impact on performance
>>
>> firefox-esr for i386: size= 58465416
>>
>> firefox-esr for amd64: size= 55451188
>>
>> gcc-10 for i386: size= 18097884
>>
>> gcc-10 for amd64: size=  16990272
> 
> Well, we've gone from ISOs containing different inventories to sizes
> of packages. I still don't see how that affects performance.
> 
> All I did was to type ls -l /usr/bin for the two architectures into
> two xterms in two viewports, and blink-compare them. Some binaries
> were larger and some were smaller.
> 
> But let's try running them. I happen to have two freshly installed
> bullseyes, and neither has run the installed FF before. Their dotfiles
> in my home directories are close to identical, and their starting
> pages are blank.
> 
> i386:
> 
>VSZ   RSZ %MEM  PID STAT   CMD
> 1200184 176396 34.9   1603 Sl+firefox-esr
> 477488 50140  9.9 1880 Sl+/usr/lib/firefox-esr/firefox-esr 
> -contentproc -ch>
> 467760 34188  6.7 1821 Sl+/usr/lib/firefox-esr/firefox-esr 
> -contentproc -ch>
> 455296 27436  5.4 1958 Sl+/usr/lib/firefox-esr/firefox-esr 
> -contentproc -ch>
> 
> amd64:
> 
>VSZ   RSZ %MEMPID STAT   CMD
> 3082424 408156  2.5 2538 Sl+firefox-esr
> 2446004 146664  0.9 2662 Sl+/usr/lib/firefox-esr/firefox-esr 
> -contentproc ->
> 2417628 117508  0.7 2694 Sl+/usr/lib/firefox-esr/firefox-esr 
> -contentproc ->
> 2403264 108072  0.6 2603 Sl+/usr/lib/firefox-esr/firefox-esr 
> -contentproc ->
> 
> The difference is larger than I thought it would be. Others would
> have to interpret the actual numbers. The main difference that
> /I/ notice is the speed, but it would be an unfair comparison,
> pitching 1.5GHz/512MB with 1GB encrypted swap on 2004-era rust
> against a multi-core 2.7GHz/16GB with a 2017-era SSD (but no swap).
> Starting times come out at 3 minutes vs perhaps one second.
> 
Did you ask your question in a real-world intention ? I mean based on
something you want to implement and may have resources limitation so
want to have the most for what you got ?

Or was it only a question for "academic" purposes ? That you wanted some
answer and explanation without any context that you can give.

Without regards to code size or whatever, there may or may not be a
performance advantage and this depend on both the type of workload and
the system you are running under.

Regarding code size, it's also mostly dependent on some choice made
during calculation such as level of optimization and how the compiler
build the output.

So your simple question needs more real world data if you want a useful
answer.

If it's only for curiosity then there's plenty of books to read and
you'll find answers.
> Cheers,
> David.
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development


OpenPGP_signature
Description: OpenPGP digital signature

Re: how to test and compare performance of bullseye for i386 and amd64

[David Wright]

On Tue 25 Jan 2022 at 01:37:29 (-0500), a wrote:
> Thank David and Polyna-Maude!
> 
> it's surprising that "The x64 binary are also somewhat larger than the
> i386 binaries"
> 
> i compare some packages of bullseye for both arch, they happen to be
> contrary
> 
> though difference is small and IMO has little impact on performance
> 
> firefox-esr for i386: size= 58465416
> 
> firefox-esr for amd64: size= 55451188
> 
> gcc-10 for i386: size= 18097884
> 
> gcc-10 for amd64: size=  16990272

Well, we've gone from ISOs containing different inventories to sizes
of packages. I still don't see how that affects performance.

All I did was to type ls -l /usr/bin for the two architectures into
two xterms in two viewports, and blink-compare them. Some binaries
were larger and some were smaller.

But let's try running them. I happen to have two freshly installed
bullseyes, and neither has run the installed FF before. Their dotfiles
in my home directories are close to identical, and their starting
pages are blank.

i386:

   VSZ   RSZ %MEM  PID STAT   CMD
1200184 176396 34.9   1603 Sl+firefox-esr
477488 50140  9.9 1880 Sl+/usr/lib/firefox-esr/firefox-esr -contentproc 
-ch>
467760 34188  6.7 1821 Sl+/usr/lib/firefox-esr/firefox-esr -contentproc 
-ch>
455296 27436  5.4 1958 Sl+/usr/lib/firefox-esr/firefox-esr -contentproc 
-ch>

amd64:

   VSZ   RSZ %MEMPID STAT   CMD
3082424 408156  2.5 2538 Sl+firefox-esr
2446004 146664  0.9 2662 Sl+/usr/lib/firefox-esr/firefox-esr 
-contentproc ->
2417628 117508  0.7 2694 Sl+/usr/lib/firefox-esr/firefox-esr 
-contentproc ->
2403264 108072  0.6 2603 Sl+/usr/lib/firefox-esr/firefox-esr 
-contentproc ->

The difference is larger than I thought it would be. Others would
have to interpret the actual numbers. The main difference that
/I/ notice is the speed, but it would be an unfair comparison,
pitching 1.5GHz/512MB with 1GB encrypted swap on 2004-era rust
against a multi-core 2.7GHz/16GB with a 2017-era SSD (but no swap).
Starting times come out at 3 minutes vs perhaps one second.

Cheers,
David.

Re: how to test and compare performance of bullseye for i386 and amd64

[Greg Wooledge]

On Tue, Jan 25, 2022 at 03:29:17PM +0100, to...@tuxteam.de wrote:
> On Tue, Jan 25, 2022 at 09:18:55AM -0500, Stefan Monnier wrote:
> > > it's surprising that "The x64 binary are also somewhat larger than the 
> > > i386
> > > binaries"
> > 
> > There is no fundamental reason why a 64bit architecture (like amd64) would
> > require more code than a 32bit architecture (like x86), but yes, on the
> > average amd64 code is a bit larger than x86.
> 
> For one, pointers are bigger. For another, ints too. So perhaps, for
> plain, straight, silly compiled C code...

I just spent a whole bunch of time writing something similar, in response
to this... and then I figured out that Stefan simply made one poor word
choice that caused the message to be extremely confusing.

I believe that what Stefan meant here is that the amd64 binary has the
same number of *instructions*.  But as you say, the instructions may be
physically longer, due to having longer operands.

So yes, amd64 compiled code tends to take up more space.  Even if it's got
the same number of instructions (which may or may not be true in all cases
-- the increased number of registers, for example, may actually decrease
the number of instructions spent moving values in and out of memory).

Re: how to test and compare performance of bullseye for i386 and amd64

[tomas]

On Tue, Jan 25, 2022 at 09:18:55AM -0500, Stefan Monnier wrote:
> > it's surprising that "The x64 binary are also somewhat larger than the i386
> > binaries"
> 
> There is no fundamental reason why a 64bit architecture (like amd64) would
> require more code than a 32bit architecture (like x86), but yes, on the
> average amd64 code is a bit larger than x86.

For one, pointers are bigger. For another, ints too. So perhaps, for
plain, straight, silly compiled C code...

>  Furthermore the static
> data that accompanies it will naturally tend to be larger since some of
> its elements will use up 64bit instead of 32bit.
> 
> For this reason, amd64 packages tend to be larger than i386 packages.

But once you talk Web browsers, which have at least one bytecode and two
JIT compilers in their fat bellies these days, all bets are up ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: how to test and compare performance of bullseye for i386 and amd64

[Andy Smith]

Hello,

On Mon, Jan 24, 2022 at 08:30:20PM -0500, a wrote:
> i've installed debian 11 for both arch on same PC, amd64 seems faster
> 
> is there some tool to demonstrate performance of PC?

Regardless of performance you should be more concerned that 32-bit
x86 parts of the Linux kernel have more bugs and receive security fixes
slower compared to amd64. For example, it took much longer for
32-bit x86 kernels to receive the same protections against the
various speculation attacks compared to amd64, in some cases it's
still not there.

Then there is the fact that increasing amounts of software simply
isn't available in 32-bit format. You might not have any with that
restriction now, but it would surely suck to want to use some in
future and not be able to without a lot of work (change your kernel
at minimum).

No one should be using 32-bit x86 today if they have the choice to
use amd64 instead.

> they say it's not possible to say which is faster without defining computing
> task

That is correct because there are many differences. amd64 has more
registers which can make code faster, but its pointers and other
data types are double the size which can affect cache hits. It
really is difficult to say without real world benchmark.

> is performance difference significant if computing task is web browsing

Modern web browsers are quite large and the 4GiB per process memory
limit with 32-bit PAE could be an issue. Otherwise, I'd guess at not
much difference.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: how to test and compare performance of bullseye for i386 and amd64

[a]

Thank David and Polyna-Maude!

it's surprising that "The x64 binary are also somewhat larger than the 
i386 binaries"


i compare some packages of bullseye for both arch, they happen to be 
contrary


though difference is small and IMO has little impact on performance

firefox-esr for i386: size= 58465416

firefox-esr for amd64: size= 55451188

gcc-10 for i386: size= 18097884

gcc-10 for amd64: size=  16990272

Re: how to test and compare performance of bullseye for i386 and amd64

[Polyna-Maude Racicot-Summerside]

On 2022-01-24 22:02, David Wright wrote:
> On Mon 24 Jan 2022 at 20:30:20 (-0500), a wrote:
>> i've installed debian 11 for both arch on same PC, amd64 seems faster
>>
>> is there some tool to demonstrate performance of PC?
>>
Yes there is standardized benchmark available. LinPack for example,
GeekBench is another one.

https://www.geekbench.com/download/


>> they say it's not possible to say which is faster without defining
>> computing task
True, AMD64 code incur some overhead.
So it will be less effective if you don't have any reason to take
advantages of the x64 architectures, for example by having less than 4
GB of RAM.

The x64 binary are also somewhat larger than the i386 binaries, they
also need more memory to run because often they will allocate 64 bit for
data "by default" on this platform.

If you are on short supply of memory, again no advantage of x64.

But this also depend on many other factors.

Because what make a difference between our PCs and high performance node
is hardware bottleneck.

So for general computing, you'll rarely exploit fully your CPU. You'll
often wait for data coming from the central memory, wait for data to be
sent out on the peripheral bus or extensions bus.

You ask a question that needs a context to be answered.

>>
>> is performance difference significant if computing task is web
>> browsing (www.debian.org)
No ! Shouldn't be, unless you have over 4 GB of RAM and would be running
many many windows/tabs/intensive web applications.

>>
>> debian-11.2.0-i386-netinst.iso is 470M while
>> debian-11.2.0-amd64-netinst.iso is 378M
>> 
>>
>> no wonder amd64 is more efficient
> 
> What exactly are you comparing here? Generally speaking, the amd64
> packages are /larger/ than the i386 ones: hardly surprising.
> 
> But the i386 ISOs have /two/ versions of many packages, the PAE
> ones and the non-PAE ones.
> 
Based solely on the size on a installation CD making affirmation
regarding benchmark is really doing a shortcut to deliver conclusion.

The question ask require more information to get a real answer.

I seriously doubt that you'll really feel difference in real life type
workload. Even using benchmark tools does not relate to real life
workload, unless you are doing physics simulation, financial analysis
regression or other math workload. In such case, you wouldn't ask such
question and already hold the answer.

> Cheers,
> David.
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development


OpenPGP_signature
Description: OpenPGP digital signature

Re: how to test and compare performance of bullseye for i386 and amd64

[David Wright]

On Mon 24 Jan 2022 at 20:30:20 (-0500), a wrote:
> i've installed debian 11 for both arch on same PC, amd64 seems faster
> 
> is there some tool to demonstrate performance of PC?
> 
> they say it's not possible to say which is faster without defining
> computing task
> 
> is performance difference significant if computing task is web
> browsing (www.debian.org)
> 
> debian-11.2.0-i386-netinst.iso is 470M while
> debian-11.2.0-amd64-netinst.iso is 378M
> 
> 
> no wonder amd64 is more efficient

What exactly are you comparing here? Generally speaking, the amd64
packages are /larger/ than the i386 ones: hardly surprising.

But the i386 ISOs have /two/ versions of many packages, the PAE
ones and the non-PAE ones.

Cheers,
David.

how to test and compare performance of bullseye for i386 and amd64

[a]

i've installed debian 11 for both arch on same PC, amd64 seems faster

is there some tool to demonstrate performance of PC?

they say it's not possible to say which is faster without defining 
computing task


is performance difference significant if computing task is web browsing 
(www.debian.org)


debian-11.2.0-i386-netinst.iso is 470M while 
debian-11.2.0-amd64-netinst.iso is 378M



no wonder amd64 is more efficient