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

[David Wright]

> <http://ftp.sunet.se/debian-cd/11.2.0/i386/iso-cd/debian-11.2.0-i386-netinst.iso>

>
> 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.

[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
>> <http://ftp.sunet.se/debian-cd/11.2.0/i386/iso-cd/debian-11.2.0-i386-netinst.iso>
>>
>> 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

[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

[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

[to...@tuxteam.de]

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

[Stefan Monnier]

> Modern web browsers are quite large and the 4GiB per process memory
> limit with 32-bit PAE could be an issue.

I'm using an i386 distribution on this Thinkpad T60 and haven't noticed
any such problem with Firefox.


Stefan

[Stefan Monnier]

> 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. 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.

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

Yes, life is complicated.


Stefan

[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).

[Stefan Monnier]

>> > 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.

Usually there are no pointers inside the code: they are manipulated by
the code but they don't directly appear in the code. Same for integers.

An 256bit-wide `add` instruction doesn't need to use up more code space
than a 16bit-wide `add`.

Of course, immediate operands do occur here and there, and sometimes
they depend on the actual size of pointers and integers, but it's fairly
rare, especially considering that there is no good reason why an ISA
can't accept a 32bit immediate value for a 64bit-wide operation.

So the reasons why amd64 code might be bigger than i386 code are most
likely due to pragmatic choices made in the design of those ISAs rather
than due to the size of their pointers.


Stefan

[Stefan Monnier]

> I believe that what Stefan meant here is that the amd64 binary has the
> same number of *instructions*.

Kind of, except that the number (and the size) of instructions is
something that depends on what kinds of instructions the ISA supports.
So I instead prefer to talk about the resulting code size.


Stefan

[David Wright]

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 %MEM PID 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.

[Polyna-Maude Racicot-Summerside]

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.

[David Wright]

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.

[a]

Thank Polyna-Maude Racicot-Summerside!

it's only for curiosity.

for most users, their performance have little difference

[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

[a]

Sorry, last word in last mail is wrong,

it should be inconvenience, not  incontinence