Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
On Wed, Dec 12, 2012 at 09:16:58AM +0100, Florian Philipp wrote: * The last thing I’m going to set up is filesystem encryption, at least for ~. I already know/think that AES would be the best choice due to limited CPU power, but what else is there to heed besides key size? Nothing, you're good. Hash and key chaining method have negligible impact. If you stick with an x86_32 userspace I suggest at least using an x64 kernel so you can use of CRYPTO_AES_X86_64. That's an interesting idea. [...] I haven't done any comparisons of 32/64 crypto yet, I'm just reading docs on Luks (never used it before). Well now, I did a few comparisons yesterday. Not much---just permutated a few of the most probable crypto combinations (aes/twofish, cbc/xts, essiv/plain). I created the LUKS container, opened it and gave it a spin with hdparm -t. The result was shocking and outrageous; reported throughput w/o encryption was 75 MB/s, which is your typical 5400 rev laptop HDD. First I was disappointed when I saw what aes-cbc-essiv gave me on 32 bit: a mere 19 and a bit. But on 64 bit, it yielded a whopping 34 MB/s. I had a hunch and booted the 32 bit system with the 64 bit kernel---and throughput stayed high as expected. So for the sake of simplicity (and to give it a rest after two weeks of ricing to the day), I will use the 32 bit userland with a 64 bit kernel. I will only need to set up some magic (a multilib crossdev gcc and separate build dirs) so I can build both kernels with their separate configs from the same source dir. I personally see no reason for encrypting root as there is nothing of interest in there. Hm ideed, the only password I have in a plaintext config file are WiFi passwords vor wpa and vpnc. For those the symlink solution could be used. Not needing an initrd is a big incentive. :) On a sidenote, While I was cleaning up unread mails in the ML, I just found your interesting frontswap/zcache trick. I tried that, too, but for now will keep it disabled---simple copying of big files was slowed down to 33 MB/s, obviously b/c the cache is constantly being changed. It's just not suitable for little Atoms. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. The duration of a minute is relative. It depends on the side of the toilet door you are standing on. signature.asc Description: Digital signature
Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
On Wed, 12 Dec 2012 18:41:03 +0100, Florian Philipp wrote: I personally see no reason for encrypting root as there is nothing of interest in there. No passwords in /etc? The main reason I encrypt / is that wicd keeps its passwords in /etc. I substitute with symlinks to /var/lib/*, /srv/* or similar. I used to do that, although I linked to /home/etc, but I found myself adding more and more and worried about missing something important. So I decided to learn how to create an initramfs and now have all but /boot (and sometimes /usr) encrypted. -- Neil Bothwick Top Oxymorons Number 5: Twelve-ounce pound cake signature.asc Description: PGP signature
Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
Am Mittwoch, 12. Dezember 2012, 02:40:04 schrieb Frank Steinmetzger: On Tue, Dec 11, 2012 at 09:20:55PM +0100, Florian Philipp wrote: * From my observations, the benefit of 64 bit over 32 is much smaller for an Atom than it is for my Core2. Am I right to assume thus that the Atom architecture doesn’t have much to offer to 64 bit (such as extra registers)? I’m not talking about memory here, since it’s limited to 2 GB in any case. It has the same set of registers as your Core2. Incidentally, when I initially set up the netbook, the output of gcc -march=native -E -v - /dev/null 21 | sed -n 's/.* -v - //p' (which floated around the ML in the past) implied core2, IIRC. It's just that the Atom micro-architecture is terrible with regard to 64bit. That's just about the only reason that x32 was invented (and now that I've said it, I'm just waiting for the flamewar about it). Terrible in what way? Inadequate memory throughput? I didn't know x32, but from what I've read in the last few minutes it sounds intriguing. terrible at dealing with 64bit numbers. Terrible at everything pretty much. -- #163933
Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
Am 12.12.2012 02:40, schrieb Frank Steinmetzger: On Tue, Dec 11, 2012 at 09:20:55PM +0100, Florian Philipp wrote: * From my observations, the benefit of 64 bit over 32 is much smaller for an Atom than it is for my Core2. Am I right to assume thus that the Atom architecture doesn’t have much to offer to 64 bit (such as extra registers)? I’m not talking about memory here, since it’s limited to 2 GB in any case. It has the same set of registers as your Core2. Incidentally, when I initially set up the netbook, the output of gcc -march=native -E -v - /dev/null 21 | sed -n 's/.* -v - //p' (which floated around the ML in the past) implied core2, IIRC. It's just that the Atom micro-architecture is terrible with regard to 64bit. That's just about the only reason that x32 was invented (and now that I've said it, I'm just waiting for the flamewar about it). Terrible in what way? Inadequate memory throughput? I didn't know x32, but from what I've read in the last few minutes it sounds intriguing. Just citing Flameeyes who is citing Intel. http://blog.flameeyes.eu/2012/06/debunking-x32-myths [...] I sped up the installation process for 32 bit by using a chroot on the big machine, which worked nicely. But it’s not a long-term solution, b/c it uses up too much disk space on the host. I do the same using NFS, bind mounts and tmpfs. What do you mean by disk space? That I don't have much space left on the host machine for the entire chroot. I bind-mount distfiles and portage, but I'm still running low on gigabytes. I was thinking of NFS quite early, but a friend said it would perform not nicely. Also, with all my cables currently occupied, the two are connected over a slow WiFi router. It's one of the rare cases in which compressing distcc traffic increases performance. :) The netbook has gigabit ethernet, though. Thank $DEITY for compressed tar pipes over SSH. I wonder what Windows people would do in such a situation. :-] I see. Yep, wifi is really not a good choice for this. NFS works nice, though. I just ran into some minor trouble when setuid bits would not survive merging. Haven't debugged this yet as it's easy enough to find with a script. [...] * The last thing I’m going to set up is filesystem encryption, at least for ~. I already know/think that AES would be the best choice due to limited CPU power, but what else is there to heed besides key size? Nothing, you're good. Hash and key chaining method have negligible impact. If you stick with an x86_32 userspace I suggest at least using an x64 kernel so you can use of CRYPTO_AES_X86_64. That's an interesting idea. If I had a 32 bit userland, I would have to build new kernels on my big 64 laptop then, right? I don’t suppose I can simply mix chosts, such that I would have a multilib x86_64 gcc/binutils/glibc, but i686 everything else. Try this. http://www.gossamer-threads.com/lists/gentoo/user/190919 I haven't done any comparisons of 32/64 crypto yet, I'm just reading docs on Luks (never used it before). Big stuff (videos, music) won't be encrypted anyway, just the sensitive data like mail, documents, passwords and personal photos. So the requirements won't be high. However I might expand it to /, though that would involve a more complicated boot process (I never needed initrds except for bootsplash). I personally see no reason for encrypting root as there is nothing of interest in there. I just encrypt home, certain /var/* sub-mounts and other stuff. That way, you can use /etc/init.d/dmcrypt.Actually, I've tweaked the setup so that I can have LVM on top of Luks. If you're interested, I can share the change. On a sidenote, While I was cleaning up unread mails in the ML, I just found your interesting frontswap/zcache trick. I wonder how many years I'd have to use the device to get back the time from improved performance that I spent setting it up in the first place. :-D Consider it experience. ;-) Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
On Tue, Dec 11, 2012 at 06:36:47PM +0100, Frank Steinmetzger wrote * I???m interested in the question of -O2 vs. -Os. Some sources say -Os is bad, b/c it breaks debugging and is mainly untested. I won???t do heavy developing on it anyway, and Atoms do have a puny cache. So I wonder whether -Os would improve execution time and RAM usage noticably. Diskspace itself is not an issue. I do builds on the netbook. My generic make.conf CFLAGS line is... CFLAGS=-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables ...on my machines. -fno-unwind-tables -fno-asynchronous-unwind-tables reverses a new and improved feature of GCC that bloats the busybox binary (and presumably other binaries) 15% to 20%. See the short thread http://lists.busybox.net/pipermail/busybox/2012-September/078326.html for background. The busybox developers obviously want to reduce every bit of disk and/or ram usage, because busybox is used in a lot of ram and disk constrained embedded systems. I don't know if it's possible to easily add another gig of ram. It would certainly help. I have an ancient netbook. It has 2 gigs of ram, but is restricted to 32-bit only. BTW, does the netbook jave a Poulsbo GPU? There are some hints at the Arch wiki https://wiki.archlinux.org/index.php/Poulsbo for getting it to work better. I can get HD Youtube videos to play in the large player, but my machine has 2 gigs of ram. If it's a relatively new Gentoo install, I recommend... emerge system emerge world ...to get the most optimization. Also, build the ondemand cpu governor and enable it (emerge cpufrequtils). This will enable the higher CPU speeds. I think my machine was originally stuck at its lowest CPU frequency due to the powersave governor, even with the machine plugged into the wall for power. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
On Wed, 12 Dec 2012 09:16:58 +0100, Florian Philipp wrote: I personally see no reason for encrypting root as there is nothing of interest in there. No passwords in /etc? The main reason I encrypt / is that wicd keeps its passwords in /etc. -- Neil Bothwick DOS never says EXCELLENT command or filename... signature.asc Description: PGP signature
Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
Am 12.12.2012 10:40, schrieb Neil Bothwick: On Wed, 12 Dec 2012 09:16:58 +0100, Florian Philipp wrote: I personally see no reason for encrypting root as there is nothing of interest in there. No passwords in /etc? The main reason I encrypt / is that wicd keeps its passwords in /etc. I substitute with symlinks to /var/lib/*, /srv/* or similar. signature.asc Description: OpenPGP digital signature
[gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
Hello list Long time no read... :) It follows a verbose preamble. For the actual questions see dashed line below. TL;DR summary: it’s all about ricer-performance questions on a netbook. I have the luck of having obtained a used netbook for free (Atom N450, single- core with HT, 1 GB memory, 5400 rev HDD). During the last week I’ve been experimenting with 32 and 64 bits on it and am still quite undecided which to keep. My reasons: - They are not as far apart in CPU performance as is the Core2. I posted a 32/64 comparison for Core2 a few months ago, which showed that Lilypond speedup on 64 bit was 50%. On the Atom, it actually took 5% longer. (Sadly, Blender doesn’t build on 32 bit right now). - Startup times for hogs like Firefox and KDE are quite equal between the two (that could be attributed in parts to the fact that the 64 bit partition sits on the disk’s first sectors, while 32 bit sits at the other end, I don’t know which end is faster). - pro 64: it is very easy to use distcc, as opposed to 32 bits (see below). - con 64: it uses about 50% more memory, 32 bit builds are a little faster. The RAM argument is the most convincing one right now, since more free RAM means more cache, which means a faster system in the long run. Currently, KDE after logon needs 150 MB on 32 bit, and 250 MB on 64 bit (without akonadi for now). But awesome WM rocks on a netbook anyway. --[ Questions begin ] So I’m interested in you opinion and own experience about the following arising questions: * From my observations, the benefit of 64 bit over 32 is much smaller for an Atom than it is for my Core2. Am I right to assume thus that the Atom architecture doesn’t have much to offer to 64 bit (such as extra registers)? I’m not talking about memory here, since it’s limited to 2 GB in any case. * The problem of distcc between different architectures: The netbook already had an older 32 bit Gentoo installed. And since I have a multilib host (march=core2), I though I could upgrade with distcc (using march=atom on the netbook). But at some point more and more stuff stopped working, eventually I got “invalid instruction” errors during emerge, hence I figured that was a dead end. So is it possible to mix architectures in this way at all with distcc? I also have crossdev for i686 installed, which even shares files with the system’s normal multilib gcc. I find that odd. I sped up the installation process for 32 bit by using a chroot on the big machine, which worked nicely. But it’s not a long-term solution, b/c it uses up too much disk space on the host. * I’m interested in the question of -O2 vs. -Os. Some sources say -Os is bad, b/c it breaks debugging and is mainly untested. I won’t do heavy developing on it anyway, and Atoms do have a puny cache. So I wonder whether -Os would improve execution time and RAM usage noticably. Diskspace itself is not an issue. * I’m also interested in comparing bin packages over self-compiled ones. E.g. I did compile icedtea, even if it’s just for TV browser. :) Can you name a Java benchmark to measure CPU performance? * The last thing I’m going to set up is filesystem encryption, at least for ~. I already know/think that AES would be the best choice due to limited CPU power, but what else is there to heed besides key size? * What other small benchmarks for CPU and memory can you recommend? So far I tested with nbench and sysbench. The results are so-and-so. Some computation stuff is much slower on 64 bit, some a bit faster. The applicability to every-day use is of course a wibbly-wobbly argument. I also tested the runtime of some application (packing and unpacking of archives, throughput with dd, mencoder). If there is interest, I can post the result of 21 runs on each platform, measured with GNU time. --[ Questions end ]-- PS.: I’m aware that benchmarks are always a bit subjective and none is perfect. I also realise that most of the questions quite belong into the ricer corner. But Netbooks are ricer devices, b/c they need to perform at their limits all the time. :-D If you read until this point, thank you very much for your time. You get a unicorn as a reward: `^nn~ -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. “Time is money” said the waiter and put the date on the bill. signature.asc Description: Digital signature
Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
On 11 December 2012 12:36, Frank Steinmetzger war...@gmx.de wrote: Hello list . . . So I’m interested in you opinion and own experience about the following arising questions: * From my observations, the benefit of 64 bit over 32 is much smaller for an Atom than it is for my Core2. Am I right to assume thus that the Atom architecture doesn’t have much to offer to 64 bit (such as extra registers)? I’m not talking about memory here, since it’s limited to 2 GB in any case. * The problem of distcc between different architectures: The netbook already had an older 32 bit Gentoo installed. And since I have a multilib host (march=core2), I though I could upgrade with distcc (using march=atom on the netbook). But at some point more and more stuff stopped working, eventually I got “invalid instruction” errors during emerge, hence I figured that was a dead end. So is it possible to mix architectures in this way at all with distcc? I also have crossdev for i686 installed, which even shares files with the system’s normal multilib gcc. I find that odd. I sped up the installation process for 32 bit by using a chroot on the big machine, which worked nicely. But it’s not a long-term solution, b/c it uses up too much disk space on the host. * I’m interested in the question of -O2 vs. -Os. Some sources say -Os is bad, b/c it breaks debugging and is mainly untested. I won’t do heavy developing on it anyway, and Atoms do have a puny cache. So I wonder whether -Os would improve execution time and RAM usage noticably. Diskspace itself is not an issue. * I’m also interested in comparing bin packages over self-compiled ones. E.g. I did compile icedtea, even if it’s just for TV browser. :) Can you name a Java benchmark to measure CPU performance? * The last thing I’m going to set up is filesystem encryption, at least for ~. I already know/think that AES would be the best choice due to limited CPU power, but what else is there to heed besides key size? * What other small benchmarks for CPU and memory can you recommend? So far I tested with nbench and sysbench. The results are so-and-so. Some computation stuff is much slower on 64 bit, some a bit faster. The applicability to every-day use is of course a wibbly-wobbly argument. I also tested the runtime of some application (packing and unpacking of archives, throughput with dd, mencoder). If there is interest, I can post the result of 21 runs on each platform, measured with GNU time. --[ Questions end ]-- PS.: I’m aware that benchmarks are always a bit subjective and none is perfect. I also realise that most of the questions quite belong into the ricer corner. But Netbooks are ricer devices, b/c they need to perform at their limits all the time. :-D I have an old N280 atom netbook, so the 64v32 is moot for me, but with a hardware limit of 2G, I'd probably run 32-bit. I don't use distcc, either, since I'd rather not saturate my (802.11g) wireless network. -Os, in my experience, makes very little difference on amd64/x86_64/whate'er (FreeBSD 9.x amd64 clang the final sizes of the binaries between -Os -O3 have very little bearing on expectations), however the atom seems to benefit quite a lot more from the smaller binaries, which on 32-bit (again in my experience with gentoo gcc46 i686) are significantly smaller than -O2 -O3 binaries. I would assume this has to do with cache fit. Some suggest using -mfpmath=sse, which I've not studied in depth. But if the x87 bits are particularly slow on the atom (mind you, I have no idea), you're not running stuff that makes heavy use of your sse registers I don't see a downside. 64-bit probably won't help much at all, unless you're running really numbery stuff. I suggest unless you're doing video editing or scientific number crunching (on your atom netbook) 32 will be fine.
Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
Am 11.12.2012 18:36, schrieb Frank Steinmetzger: Hello list Long time no read... :) It follows a verbose preamble. For the actual questions see dashed line below. TL;DR summary: it’s all about ricer-performance questions on a netbook. I have the luck of having obtained a used netbook for free (Atom N450, single- core with HT, 1 GB memory, 5400 rev HDD). During the last week I’ve been experimenting with 32 and 64 bits on it and am still quite undecided which to keep. My reasons: - They are not as far apart in CPU performance as is the Core2. I posted a 32/64 comparison for Core2 a few months ago, which showed that Lilypond speedup on 64 bit was 50%. On the Atom, it actually took 5% longer. (Sadly, Blender doesn’t build on 32 bit right now). - Startup times for hogs like Firefox and KDE are quite equal between the two (that could be attributed in parts to the fact that the 64 bit partition sits on the disk’s first sectors, while 32 bit sits at the other end, I don’t know which end is faster). The first part (which actually is the outer edge of the physical disk). - pro 64: it is very easy to use distcc, as opposed to 32 bits (see below). - con 64: it uses about 50% more memory, 32 bit builds are a little faster. The RAM argument is the most convincing one right now, since more free RAM means more cache, which means a faster system in the long run. Currently, KDE after logon needs 150 MB on 32 bit, and 250 MB on 64 bit (without akonadi for now). But awesome WM rocks on a netbook anyway. --[ Questions begin ] So I’m interested in you opinion and own experience about the following arising questions: * From my observations, the benefit of 64 bit over 32 is much smaller for an Atom than it is for my Core2. Am I right to assume thus that the Atom architecture doesn’t have much to offer to 64 bit (such as extra registers)? I’m not talking about memory here, since it’s limited to 2 GB in any case. It has the same set of registers as your Core2. It's just that the Atom micro-architecture is terrible with regard to 64bit. That's just about the only reason that x32 was invented (and now that I've said it, I'm just waiting for the flamewar about it). * The problem of distcc between different architectures: The netbook already had an older 32 bit Gentoo installed. And since I have a multilib host (march=core2), I though I could upgrade with distcc (using march=atom on the netbook). But at some point more and more stuff stopped working, eventually I got “invalid instruction” errors during emerge, hence I figured that was a dead end. So is it possible to mix architectures in this way at all with distcc? I also have crossdev for i686 installed, which even shares files with the system’s normal multilib gcc. I find that odd. I don't think you can mix x86_32 and x64 easily but I've never tried. Did you try adding a CFLAGS=-m32? From comparing `gcc -Q --help=target -march=xxx` they should be compatible. I sped up the installation process for 32 bit by using a chroot on the big machine, which worked nicely. But it’s not a long-term solution, b/c it uses up too much disk space on the host. I do the same using NFS, bind mounts and tmpfs. What do you mean by disk space? If you can use common CFLAGS, you could try installing binary packages from your build host on your netbook (use quickpkg and friends). * I’m interested in the question of -O2 vs. -Os. Some sources say -Os is bad, b/c it breaks debugging and is mainly untested. I won’t do heavy developing on it anyway, and Atoms do have a puny cache. So I wonder whether -Os would improve execution time and RAM usage noticably. Diskspace itself is not an issue. I use -Os but have no data to back it up (I'm also using an older Atom). Gentoo wiki suggests using -O2 -fno-reorder-blocks -fno-reorder-functions as a compromise. * I’m also interested in comparing bin packages over self-compiled ones. E.g. I did compile icedtea, even if it’s just for TV browser. :) Can you name a Java benchmark to measure CPU performance? How about something from this site: http://shootout.alioth.debian.org/ * The last thing I’m going to set up is filesystem encryption, at least for ~. I already know/think that AES would be the best choice due to limited CPU power, but what else is there to heed besides key size? Nothing, you're good. Hash and key chaining method have negligible impact. If you stick with an x86_32 userspace I suggest at least using an x64 kernel so you can use of CRYPTO_AES_X86_64. * What other small benchmarks for CPU and memory can you recommend? So far I tested with nbench and sysbench. The results are so-and-so. Some computation stuff is much slower on 64 bit, some a bit faster. The applicability to every-day use is of course a wibbly-wobbly argument. I
Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
I have: Atom(TM) CPU 330 @ 1.60GHz
running it with:
CFLAGS=-march=core2 -O2 -pipe
CXXFLAGS=${CFLAGS}
MAKEOPTS=-j5
CHOST=x86_64-pc-linux-gnu
Didn't run any test performance on it, but the only disappointing fact about
this small box is that it will not reboot itself when the power goes down.
It runs my asterisk and hylafax in remote location so I have to keep an eye on
it :-/
--
Joseph
On 12/11/12 18:36, Frank Steinmetzger wrote:
Hello list
Long time no read... :)
It follows a verbose preamble. For the actual questions see dashed line below.
TL;DR summary: it’s all about ricer-performance questions on a netbook.
I have the luck of having obtained a used netbook for free (Atom N450, single-
core with HT, 1 GB memory, 5400 rev HDD). During the last week I’ve been
experimenting with 32 and 64 bits on it and am still quite undecided which to
keep. My reasons:
- They are not as far apart in CPU performance as is the Core2.
I posted a 32/64 comparison for Core2 a few months ago, which showed that
Lilypond speedup on 64 bit was 50%. On the Atom, it actually took 5% longer.
(Sadly, Blender doesn’t build on 32 bit right now).
- Startup times for hogs like Firefox and KDE are quite equal between the two
(that could be attributed in parts to the fact that the 64 bit partition
sits on the disk’s first sectors, while 32 bit sits at the other end, I
don’t know which end is faster).
- pro 64: it is very easy to use distcc, as opposed to 32 bits (see below).
- con 64: it uses about 50% more memory, 32 bit builds are a little faster.
The RAM argument is the most convincing one right now, since more free RAM
means more cache, which means a faster system in the long run. Currently, KDE
after logon needs 150 MB on 32 bit, and 250 MB on 64 bit (without akonadi for
now). But awesome WM rocks on a netbook anyway.
--[ Questions begin ]
So I’m interested in you opinion and own experience about the following
arising questions:
* From my observations, the benefit of 64 bit over 32 is much smaller for an
Atom than it is for my Core2. Am I right to assume thus that the Atom
architecture doesn’t have much to offer to 64 bit (such as extra registers)?
I’m not talking about memory here, since it’s limited to 2 GB in any case.
* The problem of distcc between different architectures:
The netbook already had an older 32 bit Gentoo installed. And since I have
a multilib host (march=core2), I though I could upgrade with distcc (using
march=atom on the netbook). But at some point more and more stuff stopped
working, eventually I got “invalid instruction” errors during emerge, hence
I figured that was a dead end.
So is it possible to mix architectures in this way at all with distcc?
I also have crossdev for i686 installed, which even shares files with the
system’s normal multilib gcc. I find that odd.
I sped up the installation process for 32 bit by using a chroot on the big
machine, which worked nicely. But it’s not a long-term solution, b/c it
uses up too much disk space on the host.
* I’m interested in the question of -O2 vs. -Os.
Some sources say -Os is bad, b/c it breaks debugging and is mainly untested.
I won’t do heavy developing on it anyway, and Atoms do have a puny cache.
So I wonder whether -Os would improve execution time and RAM usage
noticably. Diskspace itself is not an issue.
* I’m also interested in comparing bin packages over self-compiled ones.
E.g. I did compile icedtea, even if it’s just for TV browser. :)
Can you name a Java benchmark to measure CPU performance?
* The last thing I’m going to set up is filesystem encryption, at least for ~.
I already know/think that AES would be the best choice due to limited CPU
power, but what else is there to heed besides key size?
* What other small benchmarks for CPU and memory can you recommend? So far I
tested with nbench and sysbench. The results are so-and-so. Some computation
stuff is much slower on 64 bit, some a bit faster. The applicability to
every-day use is of course a wibbly-wobbly argument.
I also tested the runtime of some application (packing and unpacking of
archives, throughput with dd, mencoder). If there is interest, I can post
the result of 21 runs on each platform, measured with GNU time.
--[ Questions end ]--
PS.: I’m aware that benchmarks are always a bit subjective and none is
perfect. I also realise that most of the questions quite belong into the
ricer corner. But Netbooks are ricer devices, b/c they need to perform at
their limits all the time. :-D
If you read until this point, thank you very much for your time. You get a
unicorn as a reward: `^nn~
--
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.
“Time is money” said the waiter and put the date on the bill.
Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
On Tue, Dec 11, 2012 at 09:20:55PM +0100, Florian Philipp wrote: * From my observations, the benefit of 64 bit over 32 is much smaller for an Atom than it is for my Core2. Am I right to assume thus that the Atom architecture doesn’t have much to offer to 64 bit (such as extra registers)? I’m not talking about memory here, since it’s limited to 2 GB in any case. It has the same set of registers as your Core2. Incidentally, when I initially set up the netbook, the output of gcc -march=native -E -v - /dev/null 21 | sed -n 's/.* -v - //p' (which floated around the ML in the past) implied core2, IIRC. It's just that the Atom micro-architecture is terrible with regard to 64bit. That's just about the only reason that x32 was invented (and now that I've said it, I'm just waiting for the flamewar about it). Terrible in what way? Inadequate memory throughput? I didn't know x32, but from what I've read in the last few minutes it sounds intriguing. So is it possible to mix architectures in this way at all with distcc? I also have crossdev for i686 installed, which even shares files with the system’s normal multilib gcc. I find that odd. I don't think you can mix x86_32 and x64 easily but I've never tried. Did you try adding a CFLAGS=-m32? From comparing `gcc -Q --help=target -march=xxx` they should be compatible. Not yet, putting in on todo, as it would involve building, running, testing (or reading up on it :-p ). I sped up the installation process for 32 bit by using a chroot on the big machine, which worked nicely. But it’s not a long-term solution, b/c it uses up too much disk space on the host. I do the same using NFS, bind mounts and tmpfs. What do you mean by disk space? That I don't have much space left on the host machine for the entire chroot. I bind-mount distfiles and portage, but I'm still running low on gigabytes. I was thinking of NFS quite early, but a friend said it would perform not nicely. Also, with all my cables currently occupied, the two are connected over a slow WiFi router. It's one of the rare cases in which compressing distcc traffic increases performance. :) The netbook has gigabit ethernet, though. Thank $DEITY for compressed tar pipes over SSH. I wonder what Windows people would do in such a situation. :-] If you can use common CFLAGS, you could try installing binary packages from your build host on your netbook (use quickpkg and friends). Which brings me back to the disk space problem. Right now the 32 bit chroot is a direct mirror, which is rsynced to and fro when the netbook runs in 64 bit. Once I have a cable available I think I'll go with NFS. […] Can you name a Java benchmark to measure CPU performance? How about something from this site: http://shootout.alioth.debian.org/ Will have a look-see. * The last thing I’m going to set up is filesystem encryption, at least for ~. I already know/think that AES would be the best choice due to limited CPU power, but what else is there to heed besides key size? Nothing, you're good. Hash and key chaining method have negligible impact. If you stick with an x86_32 userspace I suggest at least using an x64 kernel so you can use of CRYPTO_AES_X86_64. That's an interesting idea. If I had a 32 bit userland, I would have to build new kernels on my big 64 laptop then, right? I don’t suppose I can simply mix chosts, such that I would have a multilib x86_64 gcc/binutils/glibc, but i686 everything else. I haven't done any comparisons of 32/64 crypto yet, I'm just reading docs on Luks (never used it before). Big stuff (videos, music) won't be encrypted anyway, just the sensitive data like mail, documents, passwords and personal photos. So the requirements won't be high. However I might expand it to /, though that would involve a more complicated boot process (I never needed initrds except for bootsplash). On a sidenote, While I was cleaning up unread mails in the ML, I just found your interesting frontswap/zcache trick. I wonder how many years I'd have to use the device to get back the time from improved performance that I spent setting it up in the first place. :-D * What other small benchmarks for CPU and memory can you recommend? […] How about trying some browser benchmarks. […] I could also use those to compare binary and source firefox (which is compiling in the chroot right now). There is also a Qt render benchmark http://code.google.com/p/qtperf/ Check out app-admin/eselect-qtgraphicssystem and see how they compare in appearance and numbers. Nice idea, since I'm a general Qt fanboy. So thanks a lot for the info so far, I'll try to digest it all tomorrow. Good night for now. *yawn* -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. Emacs is a great operating system, which only lacks a good editor. pgp1UwGoo9N6y.pgp Description: PGP signature
