64-bit vs 32-bit
Ken Moffat wrote: The thing you are ignoring is the programming model - on x86_64 the 64-bit model means that gcc is no longer register-poor, so there is a lot more scope for the compiler to speed up program exection. Ken, I wasn't aware that the IA64 had additional registers. I found a nice overview via google and see what you mean, but since this was from 1999, I'm not sure if this was really Itanianm or not. I wonder how well gcc supports this model? My initial reaction is that context changes are more expensive. One benchmark that would be interesting is how long it takes to build gcc or the kernel on the same hardware but running an IA32 system or an IA64 system. Another benchmark would be doing something like a ffmpeg format conversion of a reasonably large video file. I doubt something like web browser response or normal office tasks like email, text processing, etc would have a noticeable difference. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 64-bit vs 32-bit
On Mon, Mar 26, 2007 at 11:24:47AM -0500, Bruce Dubbs wrote: Ken, I wasn't aware that the IA64 had additional registers. Well, IA64 != 64-bit. The IA64 architecture is 64-bit, and it does have tons more registers (something like 128 or 256, with a window of 32 or 64 visible at one time, IIRC). But most 64-bit machines are *not* IA64; the IA64 architecture is pretty much dead. Just about everything Intel-compatible that's running in 64-bit mode is x86-64 or equivalent (this is AMD's 64-bit architecture, which Intel copied back into their later chips and named EM64T after they realized how much better it was than IA64). This architecture has 32 registers that are all always visible (no windowing); which is still more than 32-bit code had (there were only 16 registers before). Of course the registers are twice as wide, too (on both IA64 and x86-64, although IA64 has an extra bit on each register that when set, means this register has an invalid value in it; it's used during speculative execution). My initial reaction is that context changes are more expensive. I don't remember where I heard this, but supposedly this is true on EM64T processors. It's not true on AMD64, though; their context switches are supposed to be considerably faster. (Now, whether that's faster than 32-bit mode or faster than Intel's, I'm not sure. And of course this should probably be treated as hearsay, because as I said, I don't remember where I heard it.) One benchmark that would be interesting is how long it takes to build gcc or the kernel on the same hardware but running an IA32 system or an IA64 system. Another benchmark would be doing something like a ffmpeg format conversion of a reasonably large video file. IA64 is also horribly slow at running 32-bit code (or at least, it was; maybe they fixed that in Itanium 2?), so if you want to compare it to itself, 64-bit will likely always win. But I don't think there's hardly any slowdown in 32-bit mode on x86-64; I can try to find out for sure tonight. (If I remember, I'll try to transcode 10-20 minutes' worth of MPEG2 video to xvid (MPEG4) on both architectures. Both tests will run under the same 64-bit kernel, but one will be a 32-bit process and the other will be 64. That means I'll have to build a temporary 32-bit transcode, but that's not too difficult.) I doubt something like web browser response or normal office tasks like email, text processing, etc would have a noticeable difference. I'd certainly agree with that -- but then, email, text processing, etc., *never* see a speedup, because they're always waiting on the user. ;-) pgpFZT2yv99bX.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[new XSL] The Index generation
Hi,
The generation of the Index is one of the most broken parts using the new
DocBook-XSL code. That meant that that higly customized stylesheets need be
full reworked.
Due that it need be reworked in any case, I would take advantage of a new
available feature: The possibility to create separate index pages for each
index section. That is, an index HTML page for packages, another for
programs, another for libraries, and so on.
To acomplish that (if I can implement it) a few changes will be need on how
{indexterm} block are tagged. For example, at a first look and waiting for
testing, a current entry like:
{indexterm zone=ch-system-bash}
{primary sortas=a-Bash}Bash{/primary}
{/indexterm}
could be
{indexterm zone=ch-system-bash type=package}
{primary}Bash{/primary}
{/indexterm}
I.e, the sortas attribute in {primary} will be replaced by a type
attribute in {indexterm}.
Of course, that XML changes can't be made until have the new XSL code ready.
Thus the question is, do you want that I start working on that Index pages
split or do you want only to fix the current very long longindex.xtml page
generation?
I could try to prepare a very simple POC of that index pages split if you need
something to look-at before taking a decission.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [new XSL] The Index generation
Randy McMurchy wrote: I'm sitting on the fence here. On one hand, I like the idea of individual indexes for packages/libraries/programs/etc. because of the reduced sizes and faster loading times. But on the other hand I don't want to have to open up multiple indexes to find what I'm looking for. Why not both? Those who know their way around can look at the individual indexes but there's always the long index for those who want it. Have them link to eachother. Just my $0.02. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [new XSL] The Index generation
Joe Ciccone wrote these words on 03/26/07 17:02 CST: Why not both? Those who know their way around can look at the individual indexes but there's always the long index for those who want it. Have them link to eachother. Just my $0.02. Good thought. But it is a helluva lot of work for Manuel, for what I consider very little gain. -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 17:13:00 up 17 days, 15:12, 1 user, load average: 0.12, 0.03, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [new XSL] The Index generation
Randy McMurchy wrote: Joe Ciccone wrote these words on 03/26/07 17:02 CST: Why not both? Those who know their way around can look at the individual indexes but there's always the long index for those who want it. Have them link to eachother. Just my $0.02. Good thought. But it is a helluva lot of work for Manuel, for what I consider very little gain. I agree that the gain is small. The book is over 1000 pages now. I'd rather see some new sections. See http://wiki.linuxfromscratch.org/blfs/query?status=newstatus=assignedstatus=reopenedgroup=milestonemilestone=futuretype=enhancementorder=priority Although this has been a reasonable discussion, I don't think it should be implemented. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Tidy CVS
Hi all, I cooked up a tarball of a CVS version of Tidy. Here's notable changes: 1. The documentation is part of the CVS download, so I created a Makefile.am for the htmldoc directory, generated the HTML and man pages, and generated the API docs. All of the docs are installed during 'make install'. 2. The test suite is part of the CVS download, so I created a Makefile.am for the test directory. Now, the test suite is run during 'make check', and all the tests should pass. 3. I don't know how to check if the patch is still required. It doesn't apply any longer, as the function the patch changed has been renamed. I can't tell from the commit messages if anything to do with pre tags was fixed. Here's a URL to the tarball: http://anduin.linuxfromscratch.org/files/BLFS/sources/tidy-cvs_20070326.tar.bz2 The same build/installation instructions apply, but you no longer need to download/build/install the docs manually. Also, 'make check' works. Here's the new procedure, top to bottom: sh build/gnuauto/setup.sh ./configure --prefix=/usr make make check make install -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 17:55:01 up 17 days, 15:54, 1 user, load average: 0.56, 0.15, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Tidy CVS
On 3/26/07, Randy McMurchy [EMAIL PROTECTED] wrote: I cooked up a tarball of a CVS version of Tidy. Here's notable changes: Great. 1. The documentation is part of the CVS download, so I created a Makefile.am for the htmldoc directory, generated the HTML and man pages, and generated the API docs. All of the docs are installed during 'make install'. Question: Is there any way to disable the documentation install? I generally like having documentation, but the API docs are usually overkill for me since I'm not planning on writing anything using the tidy API anytime soon. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Tidy CVS
Dan Nicholson wrote these words on 03/26/07 18:13 CST: Question: Is there any way to disable the documentation install? I generally like having documentation, but the API docs are usually overkill for me since I'm not planning on writing anything using the tidy API anytime soon. Didn't think about that (creating an optional target). Unless I redo it, you're stuck with rm -rf /usr/share/doc/tidy-cvs_20070326/api. -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 18:13:00 up 17 days, 16:12, 1 user, load average: 0.62, 0.75, 0.42 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Tidy CVS
Randy McMurchy wrote: Here's the new procedure, top to bottom: sh build/gnuauto/setup.sh ./configure --prefix=/usr make make check make install Nice. One suggestion though. Can you package up the app after the sh build/gnuauto/setup.sh so it becomes a pure CMMI app? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Tidy CVS
Bruce Dubbs wrote these words on 03/26/07 18:21 CST: Nice. One suggestion though. Can you package up the app after the sh build/gnuauto/setup.sh so it becomes a pure CMMI app? Yes, that would be simple. At the expense of a larger tarball. Is there any reason to worry about using 'all new' versions of the autotools? This is why I didn't package it in CMMI style. -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 18:28:00 up 17 days, 16:27, 1 user, load average: 0.00, 0.07, 0.18 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 64-bit vs 32-bit
Bryan Kadzban wrote: If I remember, I'll try to transcode 10-20 minutes' worth of MPEG2 video to xvid (MPEG4) on both architectures. Both tests will run under the same 64-bit kernel, but one will be a 32-bit process and the other will be 64. OK, the test was the following: I catted data from my TV card (encodes to MPEG2 in hardware) to an mpeg file for 20 minutes. Then I ran transcode on that file to convert it to xvid4. I ran the tests twice. First, the 64-bit test ran fine. But when I ran the 32-bit test, it decided it wanted to mute the audio -- so to make the tests the same, I disabled audio processing in both tests (using the arguments -y mpeg2,null -x xvid4,null), and ran them both again. Results from the first 32-bit, second 64-bit, and second 32-bit tests are below: 1) 32-bit, audio not turned off, but it decided to mute: encoding frames [00-035932], 40.70 fps, EMT: 0:19:58, ( 0| 0| 0) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 35933 frames (0 dropped, 0 cloned), clip length 1198.96 s real14m42.927s user19m33.863s sys 0m36.278s 2) 64-bit, audio turned off: encoding frames [00-035932], 40.22 fps, EMT: 0:19:58, ( 0| 0| 0) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 35933 frames (0 dropped, 0 cloned), clip length 1198.96 s real14m53.887s user19m9.208s sys 0m35.318s 3) 32-bit, audio turned off: encoding frames [00-035932], 40.66 fps, EMT: 0:19:58, ( 0| 0| 0) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 35933 frames (0 dropped, 0 cloned), clip length 1198.96 s real14m44.144s user19m33.503s sys 0m37.031s Summary: 32-bit code runs in less wall-clock time, but more actual CPU time. This is a dual-core system, and something decided to schedule the 32-bit processes differently, which made their work get done faster. This is also why the FPS numbers are higher for 32-bit: the FPS numbers are frames per wall-clock second. It's also why real time is below user time: the work was split between cores (100% of one core and about 30-50% of the other, with the 100% core switching every couple of minutes as the tasks got swapped). If I used a single-core system, 32-bit would have taken more time under both real and user. But only slightly more time: the differences are only ten wall-clock seconds over 14 minutes (1.1%), or 20 CPU seconds over 20 CPU minutes (1.7%). This is probably well below the level of statistical significance, although I don't remember much statistics, so I can't do any significance tests on the numbers. (The system time is a couple seconds faster on 64-bit also, but I think that's because no translation from 32-bit to 64-bit was required inside the kernel for the 64-bit process. Over 20 minutes of read and write syscalls, this adds up.) signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Tidy CVS
On 3/26/07, Randy McMurchy [EMAIL PROTECTED] wrote: ./configure --prefix=/usr make make check make install make -C htmldoc install_apidocs http://anduin.linuxfromscratch.org/files/BLFS/sources/tidy-cvs_20070326.tar.bz2 Great. Thanks, Randy. At some future time, so long as we're patching Makefile.am, we could probably even make the api doc install configurable with a --with switch in configure.in. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Tidy CVS
On 3/26/07, Randy McMurchy [EMAIL PROTECTED] wrote: Notice how the names of these files coincide with many of the ones you show. This is because those .m4 files are indeed wrong. But you can fix them. We should probably be patching this in BLFS. Anyway, I'm adding in-line my speex.m4 file. Diff it to yours and you'll see the underquoted definition fixed. :-) Should probably start a new thread, but I've found it was fairly easy to fix the source of the issue. For instance, this is what I'm doing in the audiofile build: sed -i.bak '/DEFUN/s/AM_PATH_AUDIOFILE/[]/' audiofile.m4 As I said before, all it does is add the brackets. I don't install most of those old guys anymore. Here's one more I found for nspr: sed -i.bak '/DEFUN/s/AM_PATH_NSPR/[]/' config/nspr.m4 -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 64-bit vs 32-bit
Bryan Kadzban wrote: Bryan Kadzban wrote: If I remember, I'll try to transcode 10-20 minutes' worth of MPEG2 video to xvid (MPEG4) on both architectures. Both tests will run under the same 64-bit kernel, but one will be a 32-bit process and the other will be 64. OK, the test was the following: I catted data from my TV card (encodes to MPEG2 in hardware) to an mpeg file for 20 minutes. Then I ran transcode on that file to convert it to xvid4. I ran the tests twice. First, the 64-bit test ran fine. But when I ran the 32-bit test, it decided it wanted to mute the audio -- so to make the tests the same, I disabled audio processing in both tests (using the arguments -y mpeg2,null -x xvid4,null), and ran them both again. Results from the first 32-bit, second 64-bit, and second 32-bit tests are below: 1) 32-bit, audio not turned off, but it decided to mute: encoding frames [00-035932], 40.70 fps, EMT: 0:19:58, ( 0| 0| 0) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 35933 frames (0 dropped, 0 cloned), clip length 1198.96 s real14m42.927s user19m33.863s sys 0m36.278s 2) 64-bit, audio turned off: encoding frames [00-035932], 40.22 fps, EMT: 0:19:58, ( 0| 0| 0) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 35933 frames (0 dropped, 0 cloned), clip length 1198.96 s real14m53.887s user19m9.208s sys 0m35.318s 3) 32-bit, audio turned off: encoding frames [00-035932], 40.66 fps, EMT: 0:19:58, ( 0| 0| 0) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 35933 frames (0 dropped, 0 cloned), clip length 1198.96 s real14m44.144s user19m33.503s sys 0m37.031s Summary: 32-bit code runs in less wall-clock time, but more actual CPU time. This is a dual-core system, and something decided to schedule the 32-bit processes differently, which made their work get done faster. This is also why the FPS numbers are higher for 32-bit: the FPS numbers are frames per wall-clock second. It's also why real time is below user time: the work was split between cores (100% of one core and about 30-50% of the other, with the 100% core switching every couple of minutes as the tasks got swapped). If I used a single-core system, 32-bit would have taken more time under both real and user. But only slightly more time: the differences are only ten wall-clock seconds over 14 minutes (1.1%), or 20 CPU seconds over 20 CPU minutes (1.7%). This is probably well below the level of statistical significance, although I don't remember much statistics, so I can't do any significance tests on the numbers. (The system time is a couple seconds faster on 64-bit also, but I think that's because no translation from 32-bit to 64-bit was required inside the kernel for the 64-bit process. Over 20 minutes of read and write syscalls, this adds up.) Thanks Bryan. That is a very interesting result. It's only one data point, but it tends to confirm other reports that I have seen that 64 bit processing isn't significantly faster for most tasks. If you are running a server with 4G Ram and very large data sets (i.e. a large database) the additional memory address size would be a definite advantage. Also if you are doing very compute intensive tasks such as solving systems of differential equations (e.g. computational fluid dynamics), 64-bit processing can make a difference. Until I see a need, I'm going to stick with 32-bit computing. YMMV -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 64-bit vs 32-bit
On 3/26/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Thanks Bryan. That is a very interesting result. It's only one data point, but it tends to confirm other reports that I have seen that 64 bit processing isn't significantly faster for most tasks. If you are running a server with 4G Ram and very large data sets (i.e. a large database) the additional memory address size would be a definite advantage. Also if you are doing very compute intensive tasks such as solving systems of differential equations (e.g. computational fluid dynamics), 64-bit processing can make a difference. At work we run a lot of simulators, and it makes a really big deal to have 64 bit binaries. One of the vendors came and gave us a presentation and showed how dramatic the difference was on their electromagnetic simulator. Part of the same presentation was showing how they were switching their UI from this old Motif piece of garbage to using Qt. I thought that was very interesting, although I'm sure no one else I work with had any idea what they were talking about. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 64-bit vs 32-bit
Dan Nicholson wrote: On 3/26/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Thanks Bryan. That is a very interesting result. It's only one data point, but it tends to confirm other reports that I have seen that 64 bit processing isn't significantly faster for most tasks. If you are running a server with 4G Ram and very large data sets (i.e. a large database) the additional memory address size would be a definite advantage. Also if you are doing very compute intensive tasks such as solving systems of differential equations (e.g. computational fluid dynamics), 64-bit processing can make a difference. At work we run a lot of simulators, and it makes a really big deal to have 64 bit binaries. One of the vendors came and gave us a presentation and showed how dramatic the difference was on their electromagnetic simulator. I can see that. It is a specialized application that is probably optimized heavily for 64 bit systems. Part of the same presentation was showing how they were switching their UI from this old Motif piece of garbage to using Qt. Interesting. I thought that was very interesting, although I'm sure no one else I work with had any idea what they were talking about. LOL. Been there. Done that. I hate it when that happens. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
