# 32/64 bits: what to choose for old laptop?

## cord

Old laptop Dell D430. Below is the cut of CPU-Z report:

```

Processors

-------------------------------------------------------------------------

Number of sockets      1

Number of threads      2

APICs

-------------------------------------------------------------------------

Socket 0   

   -- Core 0 (ID 0)   

      -- Thread 0   0

   -- Core 1 (ID 1)   

      -- Thread 1   1

Timers

-------------------------------------------------------------------------

   ACPI timer      3.580 MHz

   Perf timer      1.169 MHz

   Sys timer      1.000 KHz

Processors Information

-------------------------------------------------------------------------

Socket 1         ID = 0

   Number of cores      2 (max 2)

   Number of threads   2 (max 2)

   Name         Intel Mobile Core 2 Duo U7600

   Codename      Merom

   Specification      Intel(R) Core(TM)2 CPU         U7600  @ 1.20GHz

   Package (platform ID)   Socket 479 mPGA (0x5)

   CPUID         6.F.2

   Extended CPUID      6.F

   Core Stepping      L2

   Technology      65 nm

   Core Speed      797.9 MHz

   Multiplier x Bus Speed   6.0 x 133.0 MHz

   Base frequency (cores)   133.0 MHz

   Base frequency (ext.)   133.0 MHz

   Rated Bus speed      531.9 MHz

   Stock frequency      1200 MHz

   Instructions sets   MMX, SSE, SSE2, SSE3, SSSE3, EM64T, VT-x

   Microcode Revision   0x5C

   L1 Data cache      2 x 32 KBytes, 8-way set associative, 64-byte line size

   L1 Instruction cache   2 x 32 KBytes, 8-way set associative, 64-byte line size

   L2 cache      2048 KBytes, 8-way set associative, 64-byte line size

   Max CPUID level      0000000Ah

   Max CPUID ext. level   80000008h

   Cache descriptor   Level 1, D, 32 KB, 1 thread(s)

   Cache descriptor   Level 1, I, 32 KB, 1 thread(s)

   Cache descriptor   Level 2, U, 2 MB, 2 thread(s)

   FID/VID Control      yes

   FID range      6.0x - 9.0x

   Max VID         0.888 V

   IBRS         not supported

   IBPB         not supported

   STIBP         not supported

   RDCL_NO         no

   IBRS_ALL      not supported

   Temperature 0      58 degC (136 degF) (Core #0)

   Temperature 1      58 degC (136 degF) (Core #1)

   Clock Speed 0      797.88 MHz (Core #0)

   Clock Speed 1      797.88 MHz (Core #1)

   Core 0 max ratio   (effective) 9.0

   Core 1 max ratio   (effective) 9.0

Graphics

-------------------------------------------------------------------------

Number of adapters      1

Graphic APIs

-------------------------------------------------------------------------

API            D3D

API            Intel I/O

Display Adapters

-------------------------------------------------------------------------

Display adapter 0   

   ID         0x4000000

   Name         Mobile Intel(R) 945 Express Chipset Family

   Board Manufacturer   0x1028 (0x0201)

   PCI device      bus 0 (0x0), device 2 (0x2), function 0 (0x0)

   Vendor ID      0x8086 (0x1028)

   Model ID      0x27A2 (0x0201)

   Revision ID      0x3

   Performance Level   0

```

By experience, it was obtained that it can't handle more that 2G RAM. Is there any sense to install x86_64 Gentoo on it?

If not, what 'arch' to choose: i486 or i686?

----------

## Logicien

Have you try to stress your processor laptop to know if it can support to compile Gento from sources? Your 2 cores are already at 58 degrees. They can become hot. In plus with only 1200 Mhz processor speed it will take long to compile I guess.

It is interesting to know if a 32 bits version of Gento have an advantage over a 64 bits. 32 bits versions of Linux distributions are going down. A lot of them only support 64 bits now.

----------

## NeddySeagoon

Cord,

Your CPU is 64bit. Thats the EMT-64.

With more than 2G RAM, do a 64bit install.

----------

## cord

 *NeddySeagoon wrote:*   

> With more than 2G RAM, do a 64bit install.

 

I wrote, It doesn't support more than 2G (hardware restrictions).

Does it make sense in 64 bits, if more than 2 GB is not supported? Will 32-bit Gentoo run faster than 64?

----------

## 1clue

 *cord wrote:*   

>  *NeddySeagoon wrote:*   With more than 2G RAM, do a 64bit install. 
> 
> I wrote, It doesn't support more than 2G (hardware restrictions).
> 
> Does it make sense in 64 bits, if more than 2 GB is not supported? Will 32-bit Gentoo run faster than 64?

 

For older hardware with no more than 2g it's not going to help much to go 64 bit.

Just a pointer though, you might want to google your laptop and other memory configs (3g, 4g, etc) because sometimes the manufacturer publishes a certain limit but users have verified that it can accept larger memory.

Gentoo on small-memory systems kinda sucks. If you can find a documented larger memory configuration, it would be worth a try. Memory in that range is extremely cheap.

----------

## Jaglover

64-bit indeed, 2 GB is enough, although not plenty. 32-bit has been phased out by several major software providers.

----------

## cord

 *1clue wrote:*   

>  *cord wrote:*    *NeddySeagoon wrote:*   With more than 2G RAM, do a 64bit install. 
> 
> I wrote, It doesn't support more than 2G (hardware restrictions).
> 
> Does it make sense in 64 bits, if more than 2 GB is not supported? Will 32-bit Gentoo run faster than 64? 
> ...

 

No, it can't accept larger memory. I've checked it myself. There's one 1G chip soldered to the motherboard and one DIMM slot where I can insert also 1G memory module. If I insert there 2G module - laptop doesn't turn on. 

 *Jaglover wrote:*   

> 64-bit indeed, 2 GB is enough, although not plenty. 32-bit has been phased out by several major software providers.

 

Thanks.

----------

## 1clue

 *cord wrote:*   

>  *1clue wrote:*    *cord wrote:*    *NeddySeagoon wrote:*   With more than 2G RAM, do a 64bit install. 
> 
> I wrote, It doesn't support more than 2G (hardware restrictions).
> 
> Does it make sense in 64 bits, if more than 2 GB is not supported? Will 32-bit Gentoo run faster than 64? 
> ...

 

OK that's good info.

While I personally use 64-bit whenever the system in question can handle it, there's not much advantage to using it on your laptop. 64-bit code is larger on the disk and larger in memory, and usually turns out to be a little slower than 32-bit.

----------

## abduct

It's a bit of a toss up wither to go 32 or 64 bit. I personally go with the 64 bit option when ever possible. It provides more registers to developers at the low level end of development and allows for a greater number of raw bytes of data to be transferred in a single cpu instruction. This allows for applications to be better optimized and have faster throughput under specific cases. The down side is that 64bit systems use slightly more memory due to the double the size of instructions and pointers. They can also potentially be larger in file size as well due to similar reasons.

I don't have any benchmarks personally between a native 32bit os and a native 64bit os (no virtual abstractions of 32bit code on 64bit systems) unfortunately, I would be interested if anyone has anything of the like.

To be honest if you are worried install both one at a time and run some benchmarks, but to me I'd just use 64bit. On my laptop booted fully into X with a few terminals and ssh sessions open I only use approx 100mb of ram. If you don't use X I wouldn't be surprised if you hit sub 60mb usage levels.

----------

## ct85711

One thing to also keep in mind, is that more projects are starting to discontinue supporting 32bit all together (not just various distros).  So either way you look at it, 32bit support is dying off slowly.  Now depending on your what your needs are, you may end up reinstalling as 64bit to continue updating some software.

----------

## Ant P.

You can install a 32-bit userspace on a 64-bit kernel. No screwing around with highmem settings that way, and more importantly you'll get patches for the Intel security nightmares of 2018.

----------

## cwr

I've run Gentoo pretty successfully on Thinkpad T23s (1 GHz / 1GB RAM), after

stripping  down the kernel so that all modules were built in, and only those

modules which the hardware needed were installed.  (There were a couple of

exceptions which had to be unloaded/loaded for hibernation.)  The same generation

of Ubuntu was pretty slow, especially on boot, since it checked out every module

in sight.

I'd be inclined to use 32-bits for 2GB of RAM; 64 bits isn't going to buy you

anything, and will probably take up more space.  One advantage of Gentoo

is that you get to build the system which best fits your needs.

Will

----------

## mr-simon

With that 2G of RAM, you're going to want to be downloading some -bin packages, rather than compiling huge things yourself (assuming you want a browser on that hardware) and as mentioned earlier some people are dropping 32-bit support in their binaries. ymmv, but you're not losing much by using 64-bit. I don't think you'll notice a performance difference.

64-bit binaries may use more RAM, although I don't think that this will be particularly significant as the binary code isn't going to be the thing that's taking up your RAM space -- it'll be the stuff that your binaries allocate space for manually, which will be the same size either way.

They'll take up more space on the disk, but again that's not really going to be the bottleneck as far as storage is concerned, unless you're really squeaky on space.

Presonally, I'd go with 64.

With 'arch', the general consensus I think is to leave make.conf alone, and if you want the fastest binaries possible then use -march=native so that gcc can work out what's best for you.

What do you plan to do with the laptop once you've installed Gentoo on it?

----------

## NeddySeagoon

cord,

Sorry about missing your 2G statement.

With over 1G of RAM, the 32 bit kernel does some extra work to use it all. That's the HIMEM setting in the kernel. At 2G it has to do more.

2G is about the tipping point to go 64 bit. Pointers use mare RAM but there is no HIMEM setting to use it all.

A long time ago (abandoned now I think) Gentoo supported a hybrid 64 bit addressing with 32 bit everything else install.

Don't go there, I think work was abandoned before it was completed but it was interesting at the time.

32 bit is a sunset install. Its not as well tested as 64 bit any more and in Gentoo, 64 bit gets more support than 32 bit and that difference will accelerate.

On balance, do a 64 bit install.

-- edit --

You can have a 32 bit userland on top of a 64 bit kernel, which avoids the HIMEM issues, however, that's its own nest of vipers as the 32 bit toolchain cannot build a 64 bit kernel.

With support for a 32 bit userland declining, that's possibly the worst of all worlds.

----------

## cord

Thank You All!

I think, I'll try 64.

----------

## paluszak

I would suggest compiling with -Os and possibly lto to reduce memory usage.

I also have an impression that older desktop systems with small CPU cache feel 'snappier' when compiled with -Os, but I did not do any tests to confirm this.Last edited by paluszak on Sun Aug 19, 2018 12:37 pm; edited 1 time in total

----------

## LIsLinuxIsSogood

Do you have access to another Gentoo host that could server as a BINHOST?  

Also invest in a good fan as well if possible else leave PC in a well ventilated area  :Smile: 

If you wanted to spend the same time but a different way you could be finding a way to make the stage4 archive with all your planned installed packages on a separate machine and then clone over to the laptop.  This saves the initial compiling, but then later you will still need to figure out what to do with updated, plus this way isn't recommended without better understanding of system rescues, backup and restore procedures.  

If you did have access to a build-server of sorts that was more powerful I think the good news is with 32-bit vs. 64-bit since the architecture doesn't change drastically you can (I think) do this without a cross-compiler.

----------

## cord

I have installed 64-bit Gentoo. Looks like it working well. But it's very hard to build some @system packages (dev-qt/qtwebkit foe example).

BINHOST is good idea, and yes, I have machine for that (Core i5 / 8 GiB RAM). But I find difficult to define CFLAGS variables - both are set to "-march=native -O2 -pipe" (no problems with CPU_FLAGS_X86, it's clear). I understand, that CPU flag sets are different...

----------

## C5ace

I run 64 bit Xfce in Virtualbox with 2 cores with 512KB RAM and 4GB Swap. Compiling and running Gentoo, Firefox, Thunderbird and Openoffice works fine but slow. Emerge @world takes 3 days.

----------

## cord

 *C5ace wrote:*   

> I run 64 bit Xfce in Virtualbox with 2 cores with 512KB RAM and 4GB Swap. Compiling and running Gentoo, Firefox, Thunderbird and Openoffice works fine but slow. Emerge @world takes 3 days.

 

Maybe you mean 512MiB?

In my case only qtwebkit compiling took 3 days, with total computer inaccessibility.

----------

## C5ace

 *cord wrote:*   

>  *C5ace wrote:*   I run 64 bit Xfce in Virtualbox with 2 cores with 512KB RAM and 4GB Swap. Compiling and running Gentoo, Firefox, Thunderbird and Openoffice works fine but slow. Emerge @world takes 3 days. 
> 
> Maybe you mean 512MiB?
> 
> In my case only qtwebkit compiling took 3 days, with total computer inaccessibility.

 

Sorry, should read 512MB RAM.

----------

## cord

I find out script that lists me necessary flags:

```
#!/bin/bash

echo $(

    gcc -v -march=native -x c /dev/null 2>&1 \

        | fgrep -- '-march' \

        | egrep -o ' (-m|--param )\S+' \

        | fgrep -v -- '-mno-'

)
```

And now I wrote script for making binnaries

```

#!/bin/bash

# Huge packages: dev-qt/qtwebkit www-client/firefox dev-qt/qtwebengine app-office/libreoffice sys-kernel/gentoo-sources sys-devel/gcc

CFLAGS="-march=core2 -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mfxsr --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2 -O2 -pipe" CXXFLAGS="${CFLAGS}" PKGDIR="/home/ftp/gentoo-distfiles/packages/" PORTAGE_BINHOST="ftp://172.16.0.1/gentoo-distfiles/packages" MAKEOPTS="-j5" emerge -vB dev-qt/qtwebkit

```

Would that work?

----------

## josephg

 *cord wrote:*   

> Would that work?

 

Have you seen what the wiki says..

http://wiki.gentoo.org/wiki/GCC_optimization#-msse.2C_-msse2.2C_-msse3.2C_-mmmx.2C_-m3dnow

 *Quote:*   

> Normally none of these flags need to be added to /etc/portage/make.conf, as long as the system is using the correct -march (for example, -march=nocona implies -msse3)

 

----------

## eccerr0r

Besides the fact that 32-bit support is waning, I find that the 64-bit install on a Core2 machine I'm working on is hoggy on RAM and 2GB is a bit low.  That is, it seems to hit swap a lot sooner than what I would expect compared to another machine with a 32-bit install with like 2GB of RAM.  

Compiling -Os will at least help your text sizes, but data sizes can still be huge.

YMMV - I was planning to upgrade a Core2 Quad with 4GB RAM to 64-bit to help future proof it a bit...

----------

## josephg

 *eccerr0r wrote:*   

> Besides the fact that 32-bit support is waning, I find that the 64-bit install on a Core2 machine I'm working on is hoggy on RAM and 2GB is a bit low.  That is, it seems to hit swap a lot sooner than what I would expect compared to another machine with a 32-bit install with like 2GB of RAM.  
> 
> Compiling -Os will at least help your text sizes, but data sizes can still be huge.

 

i experienced the same when i initially started moving to 64bits with all gung ho.. quickly realising that i wasn't getting much of the expected benefits. so now i have everything on 32bits. having them all on 32bit is easier for me to manage.

----------

## eccerr0r

Yeah, I took a chunk out of my SSD's life trying to compile I believe it was webkit or qt.  I only had 3 processes going on this dual core (-j3) with 2GB RAM, and it was swapping quite a bit though it was kind of hard to notice since it swaps fairly quickly.

The SSD is now probably getting close to a decade old, and I just hit... 1% lifetime usage (it's now about 30 erase cycles on the MLC).  Portage_tmpdir is on the SSD as well.  That last huge batch update I did on this SSD took around ~2 erase cycles to complete, and the swapping was a good chunk of it... and having to restart broken merges kills...

----------

## josephg

that's why i have -gk in make.conf on my netbook

----------

## Jaglover

My solution to this problem is building in NFS chroot. Puts minimal load to the hardware, except the NIC. No 32 bit here.

----------

## josephg

that's interesting.. i wonder if you can cross compile arm in nfs chroot from intel

----------

## eccerr0r

Actually build memory use isn't the problem, the fact that build memory use is high, all other operations on that computer like running Firefox, etc., is also high, and performance will suffer likewise.

However if you still do not completely use up all your RAM, then maybe things are okay.  I just felt that amd64 2GB machine even when not compiling seemed to use up all RAM well before my x86 machine did with 2GB RAM.

----------

## josephg

one of the reasons i still continue with 32bit on all my systems

----------

## 1clue

IMO Gentoo is not happy in 2 GiB no matter what. I think that anything under 4 and you want to have a compiler farm with bigger hardware somewhere on your network.

I have successfully installed Gentoo on a Raspberry Pi B+ without the compiler farm, but when I was done I pretty much trashed it as it would be a full-time job just to do updates on it.

----------

## eccerr0r

I tried chrooting into my nfs mounted Atom from my i7...

When I tried running 'emerge' I got greeted with:

```
/tmp # chroot /mnt0

/ # emerge

Illegal instruction (core dumped)

/ # exit
```

No idea where it dumped core...

I still sort of update a 1GB P-m, it's still tolerable but swaps quite a bit.  Less than 1GB I don't even try.

----------

## tribute58

I'm running Gentoo with 64bit kernel + userspace on an Acer Aspire One D255 (Atom N550  1.5GHz dualcore + HT with max  2GB Ram). And it works!

The only problematic package, in case of ram, is chromium. It didn't respect -jn and ran with at least 8 threads, if I remember correctly. Maybe one can override it... I didn't dig into this as I use firefox, which compiles just fine.

My make.conf uses march=native -O2 pipe and -j2! Running updates over night is not a problem as long as you don't try to experiment with LTO.

The only bin package I'm using is LibreOffice, but thats a question of CPU performance...

I don't think -Os helps, neither compiling nor running programs, but I never checked that. Of course, it reduces the instruction memory footprint, but has no influence on data, so the overall gain will be negligible.

----------

## eccerr0r

My Atom 32 bit with 2GB RAM is still chugging away at updates.  It was compiling rust when I looked at it last night, and is STILL compiling rust this morning...

```
atom /tmp # uname -a

Linux atom 4.9.95-gentoo #1 SMP Mon Jun 18 21:51:25 MDT 2018 i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux

atom /tmp # qlop -c

 * dev-lang/rust-1.29.1

     started: Sat Oct 13 20:34:01 2018

     elapsed: 12 hours, 53 minutes, 11 seconds
```

CPU limited not RAM limited I think, though I don't quite get how rustc allocates memory.  It appears to be multithreaded but once I caught it pretty much using all RAM but didn't touch swap.

I did notice rustc use more than 2 threads on my quad core machines, so it must have some internal thread usage limitation.  The current rustc execution has a resident size of 1.2GB, though I saw 1.5GB last night.

I switched over to swapping onto a USB HDD just in case, but current swap usage is 0.

----------

## cord

How long dev-qt/qtwebkit compilation took?

----------

## eccerr0r

I don't have qtwebkit or webkit-gtk installed on this machine, plus sometimes I have distcc working and sometimes not, so hard to tell which merges were done under what circumstances.

Also not sure why I have a few entries with really short merge times, but this one is probably accurate:

rust: Sat Oct 13 20:27:49 2018: 57930 seconds

Gcc is bad too, this is 7.3:

gcc: Sat Oct 13 09:19:24 2018: 27702 seconds

32-bit -- so far, neither package swaps while building using MAKEOPTS=-j2 (since this Atom is a dual thread machine.) on 2GB.

The 64-bit setup seems more swappy with the same amount of RAM.  Alas overall speed is faster for the 64-bit because that's a Core2 Duo which is many times faster than the dual thread single core Atom.

----------

## n05ph3r42

cord:

As for hardware RAM limitations - i suggest to try other RAM, better of same manufacturer, same as soldered on your mb. Mostly this "limitations" is only in specifications.

Also you can try https://wiki.gentoo.org/wiki/Distcc to speedup compilation, if you have other machines on your network.

----------

## tribute58

 *eccerr0r wrote:*   

> The 64-bit setup seems more swappy with the same amount of RAM.

 

You're right, measuring absolute numbers, but the difference is negligible. I started with a 32 bit System, but soon made the step to 64 bit, because the extra Ram usage is much less than often communicated. Using a lightweight DE and activating only necessary services, plugins, ...  is important.

 *cord wrote:*   

> How long dev-qt/qtwebkit compilation took?

 

You can't compare that to your system. eccerr0rs system has one physical core, mine has two (as yours has), but both have much less IPC than your C2D. So if swapping doesn't occur, you're compile times will be seriously faster than ours.

----------

## eccerr0r

BTW,  portage/"emerge" uses ~500MB of RAM on an amd64 box I'm updating right now (2GB RAM) ... a quarter of its RAM is used by portage for emerge!

I suspect I'm not comparing apples with apples, but a 32-bit install I'm maintaining, emerge used up about 252MB of RAM.  The difference: the 32-bit install (1GB RAM...) has an xfce4 setup, other 64-bit has full GNOME setup too; both have firefox-60 and its dependencies.

Anyone see similar memory use?  No wonder the 2GB amd64 machine is running fairly crappy when doing updates.

----------

## cord

 *eccerr0r wrote:*   

> BTW,  portage/"emerge" uses ~500MB of RAM on an amd64 box I'm updating right now (2GB RAM) ... a quarter of its RAM is used by portage for emerge!

 

Is there difference between "emerge --sync" / "emerge-webrsync"?

----------

## eccerr0r

Those don't make portage use much memory.  Anyway --sync could be using rsync or git I believe, webrsync is rsync.  Both use an external program to do the sync and isn't really using portage.

Doing the dependency calculations unfortunately is serialized with doing the actual make compilation, unlike doing a sync which does not need to be (and should not be) running while computing dependencies...

----------

## Anon-E-moose

 *cord wrote:*   

>  *eccerr0r wrote:*   BTW,  portage/"emerge" uses ~500MB of RAM on an amd64 box I'm updating right now (2GB RAM) ... a quarter of its RAM is used by portage for emerge! 
> 
> Is there difference between "emerge --sync" / "emerge-webrsync"?

 

Just time, webrsync downloads portage as a tarball instead of individual packages, then unpacks them. May be some memory difference but I doubt much.

----------

## cord

It needs 500 MiB RAM to unpack 50 MiB archive?

----------

## eccerr0r

No... again, 500MB to compute dependencies.  When doing a sync, dependencies are not computed - heck, portage doesn't even load the ebuilds to compute anything...

----------

## eccerr0r

For curiosity sake, dev-lang/rust of the few runs I tried took:

Atom 1.6GHz dual thread, 32-bit: 16 hours (std dev less than 5 mins)

Pentium-M 1.6GHz single thread, 32-bit: 7 hours (std dev is on the order of an hour, so I have to get more accurate data...)

I have to use rust as a gauge because rust does not distribute, so I know it's not cheating :)

Anyway, I didn't expect this kind of discrepancy, thought the two processors were closer together in terms of speed.  Alas the Atom is not affected by meltdown or other CPU security issues...

I will need to do some testing of 32- vs 64- bit.  The only data I have right now is flawed:

32 bit QEMU KVM using 2 cores on Core2Quad 9550S: just under 3 hours

64bit baremetal using 4 cores on Core2Quad 9550S: just over 1 hour.

If I extrapolate the 32-bit number, it would be under 1.5 hours in 32 bit.  That would mean that QEMU is quite slow adding 50% time penalty or 33% speed penalty...  Of course this has no bearing on 32- vs 64- on baremetal.

----------

## Marcih

 *eccerr0r wrote:*   

> Atom 1.6GHz dual thread, 32-bit: 16 hours (std dev less than 5 mins)
> 
> Pentium-M 1.6GHz single thread, 32-bit: 7 hours (std dev is on the order of an hour, so I have to get more accurate data...).

 

That's interesting, what exact processors are those? I have a notebook and a 2-in-1 with a Pentium M 770 (2.33GHz, single core) and an Atom Z3735F (1.33GHz, quad-core), both have Gentoo with all the installed packages and the kernel compiled using GCC's native optimizations. I have yet to do any scientific testing but the Atom seems to be (less than) half the speed of the Pentium M (~20 mins vs 1 hr compiling glibc) and I'm wondering why that is. If the Atoms deal with instructions differently, shouldn't the compiler optimize for that, making them not suck as much? The Pentium is simple, it's just a more power-efficient PIII, no change in how it executes instructions as far as I know, but the Atom family may have a more esoteric set-up (I know the rest of the device does, I haven't managed to get audio working on it after almost a year  :Rolling Eyes: ).

----------

## 1clue

 *Marcih wrote:*   

>  *eccerr0r wrote:*   Atom 1.6GHz dual thread, 32-bit: 16 hours (std dev less than 5 mins)
> 
> Pentium-M 1.6GHz single thread, 32-bit: 7 hours (std dev is on the order of an hour, so I have to get more accurate data...). 
> 
> That's interesting, what exact processors are those? I have a notebook and a 2-in-1 with a Pentium M 770 (2.33GHz, single core) and an Atom Z3735F (1.33GHz, quad-core), both have Gentoo with all the installed packages and the kernel compiled using GCC's native optimizations. I have yet to do any scientific testing but the Atom seems to be (less than) half the speed of the Pentium M (~20 mins vs 1 hr compiling glibc) and I'm wondering why that is. If the Atoms deal with instructions differently, shouldn't the compiler optimize for that, making them not suck as much? The Pentium is simple, it's just a more power-efficient PIII, no change in how it executes instructions as far as I know, but the Atom family may have a more esoteric set-up (I know the rest of the device does, I haven't managed to get audio working on it after almost a year ).

 

I have a c2758 based board running Gentoo. It also sucks pretty bad for compile times compared to my i7 920, but for encryption/compression/networking tasks it goes neck and neck with the i7. The atom has extra hardware for acceleration of encryption and compression, and the board was designed as a network device with 7x Intel nics. So I suspect that this atom from eccerr0r also has some sort of extra on-chip hardware that makes some things faster, but not compilation.

----------

## eccerr0r

The atom is an old n270 single core dual thread, the Pentium-M is just a Dothan 1.6GHz.

I also suspect that the "rust" workload is really not what an atom is designed for.  I haven't had a definitive distcc-less gcc run to compare but I suspect gcc also isn't quite a "normal" workload.

On the other hand firefox itself seems about the same or maybe a tad worse on the Pentium-M and the Atom.  But I haven't run a true benchmark on them to compare, but I would think that a browser should be in the intended workloads of the Atom...

----------

