Bruce Dubbs wrote:
> 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 b
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 r
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
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 wa
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 fi
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 p
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
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' v
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
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 th
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 th
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'
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. B
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
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 loo
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 separa
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, IIR
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
On Sun, Mar 25, 2007 at 09:23:39PM -0500, Bruce Dubbs wrote:
>
> Some benchmarks against a 32-bit build would be interesting. My
> understanding is that 64-bit systems have larger binaries, use more ram,
> and are slower the equivalent 32-bit systems unless you are doing some
> fairly serious nu
19 matches
Mail list logo
