Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share
to use 3 registers: one to roll y, one to hold the squares of x,
and one to hold
the result.
Writing the same algoritm with assembler language can save a few instructions
per loop,
because gcc doesn't catch that it can use the out-going bit of y to directly
jump over xy *= x;
if not set. But it won't be portable then.
Best regards,
Nicolas Argyrou
I'm ok with using Bash's licence.
- Original Message -
From: William Park
To: Nicolas ARGYROU
Cc: bashbug
Sent: Monday, September 19, 2011 3:33 AM
Subject: Re: Bug fix for $((x**y)) algorithm on 64+ bits machines.
No. For example, current Bash is copyrighted and licen
)
Regards,
Nicolas Argyrou
- Original Message -
From: Dave Rutherford
To: Nicolas ARGYROU
Cc:
Sent: Saturday, September 17, 2011 10:34 PM
Subject: Re: Bug fix for $((x**y)) algorithm on 64+ bits machines.
On Sat, Sep 17, 2011 at 07:10, Nicolas ARGYROU wrote:
> I came up with a
I'm glad it pleases you. I'm amazed also how fast it deals with large numbers.
Feel free to use it. :)
I came up with a version that is slightly more precise in the comments, and
that uses 3 registers instead of 4
(though gcc can optimize that):
// Copyright 2011: Nicolas Argyro
unsigned integer type, and doesn't
need any external resource:
// Copyright 2011: Nicolas Argyrou , public domain.
template
inline T ipow(register T x, register T y)
{
if (x == 0 && y != 0) return 0;
// 1: ipow(x,y) = x ** y = Product [i=0; i>i)&1)*2**i))
// 2: x
mprovement!
Apparently, bash-completion is very active at the moment. They are
currently trying to fix as many bugs as possible, and will then optimize
bash-completion for Bash 3.x.
Nicolas
rnor),
starting a new shell (and running my .bashrc) now takes around 0.4s,
while it took 0.6s with Bash 3.2. This is enough to feel a difference!
Nicolas
colors`
is now 4.8 times faster!).
Thank you very much for this wonderful new version of Bash!
Nicolas
> > What is the role of xmbsrtowcs? Why doesn't mbsrtowcs convert 0x5c to
> U<0x5c>?
>
>
> I see. I assume that it's a bug in mbsrtowcs. (If you check, xmbsrtowcs
> isn't used anywhere, so the question is moot.)
Ok. But I suppose that the role of xdupmbsrtowcs is to avoid the same
bug, am I r
Thanks for your answer.
> > Nevertheless, I don't really understand the purpose of this function.
> > Is it supposed to bypass a bug in mbsrtowcs (defined in wchar.h), as
> > said in the following commentaries?
> > /* xmbsrtowcs.c -- replacement function for mbsrtowcs */
> > /* On some locale
for converting 0x5c to U<0x5c>. */
If so, why isn't it corrected to wchar.h?
Regards,
Nicolas
Thanks for your answer.
> I assume you know that the speed issues most likely come from the
> operating system's supporting functions like the fork() and exec*()
> family members?
How does it explain the speed difference between "echo `dircolors`"
and "dircolors" ?
p;& sh ./dircolors_output
still takes 0.004s, so it is more than 20 times faster than using
command substitution.
So, do you think that speeding up command substitution would be a
difficult task?
Regards,
Nicolas
lt task?
Thanks,
Nicolas
lists.gnu.org/archive/html/bug-bash/2004-09/msg00118.html
If it's a known issue, why does the configure script select the
bison-1.75 instead of the working yacc?
If this can't be changed easily, perhaps you can add a note in INSTALL
or somewhere else, warning people to use bison-1
16 matches
Mail list logo
