Some more
16) Whoops, Bill's new FFT , of which I had completely forgotten about :( ,
Dam'it I going to have to deliver on my small size improvements of perhaps 10%
17) Use emulators for different cpu's (although whether they can trap on
unknown opcode's ? (but not a large problem in my experie
Some more idea's
14) There is some asm code out (for non-x86*) there which we can use as it is
under a compatible license
15) Compilers are far more "intelligent" , the macro mul_ppmm is almost
certainly faster in C (since gcc-3.4), perhaps the same for divide , although
for add_ss I not a
On Friday 19 November 2010 19:47:03 Jeff Gilchrist wrote:
> On Fri, Nov 19, 2010 at 1:47 PM, Jason wrote:
> > Cheers , My best guess is that this is an autotool problem. I just tried
> > using the latest autotools , but it is a lot stricter than our current
> > version , and I would have to do som
Finished testing with a Core2 based Windows 7 Ultimate 64bit machine
and Visual Studio 2010. Testing the core2 64bit project with C++
project as well.
Compile happened fine. But when running the python test script using
python 2.6.2 I get:
Traceback (most recent call last):
File "D:\Data\Jeff_
On Fri, Nov 19, 2010 at 1:47 PM, Jason wrote:
> Cheers , My best guess is that this is an autotool problem. I just tried using
> the latest autotools , but it is a lot stricter than our current version , and
> I would have to do some work on our configure.in and makefile.am's before I
> can
> tr
On Friday 19 November 2010 17:36:15 Jeff Gilchrist wrote:
> On Fri, Nov 19, 2010 at 11:56 AM, Jason wrote:
> > To get just a static build you have to --disable-shared as well and for
> > just a shared build --disable-static as linux defaults to building both.
> > Note for cygwin/mingw* just puttin
On Fri, Nov 19, 2010 at 11:56 AM, Jason wrote:
> To get just a static build you have to --disable-shared as well and for just a
> shared build --disable-static as linux defaults to building both. Note for
> cygwin/mingw* just putting --disable-static will fail as it only builds static
> by defaul
On Friday 19 November 2010 16:40:38 Jeff Gilchrist wrote:
> On Fri, Nov 19, 2010 at 3:57 AM, Jason wrote:
> > Thanks , I have no idea what it is , the only thing I can suggest for the
> > moment is to try a build for static only , and then in a clean dir a
> > shared build only. I'm not sure what
On Fri, Nov 19, 2010 at 3:57 AM, Jason wrote:
> Thanks , I have no idea what it is , the only thing I can suggest for the
> moment is to try a build for static only , and then in a clean dir a shared
> build only. I'm not sure what it will tell us !!!
Using just --enable-static works fine compil
Whoops , posted this in reply to someone else
One other thing to consider is that we could take advantage of more unrolling
for functions that are only used for FFT , and even better if the lengths are
always a multiple of the unroll factor , then we dont have to bother with
feedin/wind-do
There are many. I'll post a list when I find some time.
On 19 November 2010 14:14, Jason wrote:
> On Friday 19 November 2010 13:23:28 Bill Hart wrote:
>> It is very likely that my new FFT will be done within 3 months. It
>> will be BSD licensed for obvious reasons. But this would be
>> compatible
On Friday 19 November 2010 13:23:28 Bill Hart wrote:
> It is very likely that my new FFT will be done within 3 months. It
> will be BSD licensed for obvious reasons. But this would be
> compatible, so you could use it. That would allow a lot of
> improvements to the asymptotically fast division cod
It is very likely that my new FFT will be done within 3 months. It
will be BSD licensed for obvious reasons. But this would be
compatible, so you could use it. That would allow a lot of
improvements to the asymptotically fast division code. But I won't get
to doing those as well in the next 3 month
Hi
Now that v2.2 is almost ready for release (just waiting to test on a few more
machines ie gcc-farm , should be done by mid next week) , we should think
about what should go in to v2.3 , here are some of the things I hope to do.
1) Quicker release , say no more than 3 months until release (2.
Looks like it may be an autotools problem in that it's not setting the path to
the shared library properly . There are later autotools available which may fix
this.
mpir-2.1 uses (from boxen)
libtool 1.5.26
autoconf 2.61
automake 1.10.1
mpir-2.2 uses (from eno)
libtool 2.2.6b
autoconf 2.65
auto
On Friday 19 November 2010 01:10:47 Jeff Gilchrist wrote:
> On Thu, Nov 18, 2010 at 5:29 PM, Jason wrote:
> > I'm assuming case 3 is on the same machine as the failed case ?
>
> Yes, they are the same machine.
>
> > Did the previous mpir v2.1 fail with the same options ?
>
> I just checked an v
On Thursday 18 November 2010 20:31:46 Bill Hart wrote:
> $ diff cpuid.old cpuid.c
> 124c124,125
> < break;
> ---
>
> > if (model == 9) { CPUIS(k102);break;}
> >
> > break;
>
> Otherwise tests pass with only the following warnings when doing make
> check:
>
> me
17 matches
Mail list logo
