On Fri, Apr 30, 2010 at 4:11 AM, Sergey Bochkanov
wrote:
> Hello, William.
>
>> In Sage we (=mostly Gonzalo Tornaria) spent an enormous amount of time
>> writing two very efficient C functions, one to convert from mpz to
>> Python ints, and one to convert back. Yes
On Fri, Apr 30, 2010 at 4:11 AM, Sergey Bochkanov
wrote:
> Hello, William.
>
>> In Sage we (=mostly Gonzalo Tornaria) spent an enormous amount of time
>> writing two very efficient C functions, one to convert from mpz to
>> Python ints, and one to convert back. Yes
On Thu, Jan 28, 2010 at 10:47 PM, Bill Hart wrote:
> The tests have passed on Cygwin32/k8. I've updated the website, so
> there are fewer blanks now.
>
> We still need test reports for k7, i7, OSX PPC, alphaev56, netburst,
> if anyone has access to any of those.
All tests pass on linux/nehalem (b
On Thu, Jan 28, 2010 at 9:00 PM, Bill Hart wrote:
> 2010/1/28 Dr. David Kirkby :
>> I'm using an Intel W3580 - 3.33 GHz Quad core Xeon.
>>
>> http://ark.intel.com/Product.aspx?id=39723
>>
>> I've seen other packages use something different to both core2 and penryn,
>> and if I recall correctly, th
make ; make check passes for me on linux 64 bit (debian 5.0)
cpu = Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (nehalem)
gcc 4.3.2
Gonzalo
On Thu, Jan 14, 2010 at 2:16 PM, Bill Hart wrote:
> I have fixed the issue with t-invert being missing from the tarball,
> and so rc6 is now available on our site
On Wed, Jan 13, 2010 at 2:05 PM, Gonzalo Tornaria
wrote:
> -- Forwarded message --
> From: Jaap Spies
> ...
> [j...@vrede sage-4.3.1.alpha1]$ cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model :
-- Forwarded message --
From: Jaap Spies
Date: Wed, Jan 13, 2010 at 1:55 PM
Subject: bouncing message to mpir-devel
To: Gonzalo Tornaria
>> >> Not quite. In Fedora 12 on the real machine I get:
>> >> gcc version 4.4.2 20091222
On Wed, Jan 13, 2010 at 12:06 PM, Jaap Spies wrote:
> Gonzalo Tornaria wrote:
>>
>> On Wed, Jan 13, 2010 at 11:43 AM, Jaap Spies wrote:
>>>
>>> gcc version 4.4.2 20091222 (Red Hat 4.4.2-20) (GCC)
>>> ***
On Thu, Dec 3, 2009 at 4:22 PM, Case Vanhorsen wrote:
> The MS-SDK compiler selected p3 as the CPU type. But the actual CPU is
> a Core2 Duo. The CPU type is correctly detected when I do a 64-bit
> build.
Check out this thread:
http://groups.google.com/group/mpir-devel/browse_thread/thread/c31f8
On Thu, Jul 16, 2009 at 9:19 PM, Bill Hart wrote:
>
> Yes, that is my plan. At present I have access to zero machines with a
> web server and git-svn installed. So I can't do this at present.
>
> I don't know how easy it would be to automatically track the svn repo.
> One way is to have a screen s
On Thu, Jul 16, 2009 at 3:11 AM, Bill Hart wrote:
> Another option, which will be faster, is to clone someone else's git
> repository,
> though if you want to keep up with the central svn repo, you will have to
> wait
> for them to rebase before you can get the updates from them every time. Tha
On Fri, May 22, 2009 at 11:29 PM, Craig Citro wrote:
>
>> That link no longer works but when I skimmed it early it recommended
>> to never use mpz_import and mpz_export. Is there a particular reason?
>> (I use both functions in gmpy to convert between the internal
>> representation of a Python lo
On Mon, May 4, 2009 at 11:27 AM, Jason Moxham wrote:
>
> Hi
>
> I've been playing with some assembler for the Intel Core2 chips and have come
> across this timing oddity which I cant explain . Any ideas?
Maybe it's to do with the branch predictor? Remarks:
1. It seems to me that this starts hap
On Thu, Apr 23, 2009 at 3:40 PM, Bill Hart wrote:
> What is very impressive is that Sun was so keen to send this to the
> Sage project that it arrived just two days after they said they were
> sending it! And they explicitly said it was an unrestricted gift. This
> is obviously also a real boon f
On Fri, Mar 20, 2009 at 11:46 PM, Bill Hart wrote:
>
> I suppose it's just aggregation.
>
> Maybe we need to get rid of the bit that says, "overall licensed
> LGPL". Is that still permitted, when some component of the distro is
> GPL?
Sounds like a good idea.
> Actually the reason for me wantin
On Fri, Mar 20, 2009 at 2:18 PM, Bill Hart wrote:
>
> Well we'll eventually replace with our own. Some of the demos are
> actually GPL as well. We should dump those too.
Why? Only the parts that are linked with applications need to be LGPL.
As long as those files/directories are clearly marked
On Thu, Mar 19, 2009 at 2:35 PM, Jason Moxham wrote:
>> Yes, except config.guess may change it (but it shouldn't, as we
>> discussed before this causes compilation failure, e.g. in a kvm
>> virtual cpu which reports wrong cpuid).
>>
>
> My understanding is that config.guess is to "tweek" the exac
On Thu, Mar 19, 2009 at 2:32 PM, Jason Moxham wrote:
>
> On Thursday 19 March 2009 14:31:55 Gonzalo Tornaria wrote:
>> On Wed, Mar 18, 2009 at 10:44 PM, Bill Hart
> wrote:
>> > Wait, how does it currently decide which ABI to use? Does configure
>> > decide that
On Wed, Mar 18, 2009 at 10:44 PM, Bill Hart wrote:
> Wait, how does it currently decide which ABI to use? Does configure
> decide that aside from what config.guess says.
Yes, except config.guess may change it (but it shouldn't, as we
discussed before this causes compilation failure, e.g. in a kv
This is set up to test an already installed mpir library, afaict. I
posted a different modification a few days ago which allows to test a
non-installed mpir library (i.e. just compiled). It also
(automatically) works with older versions of mpir which use "gmp" for
the library name (e.g. 0.9) and m
; prescott and the 64 bit versions which we called nocona. I now see
> prescott, netburst and pentium4. Admittedly nocona is a codename for a
> certain Xeon revision (basically the Xeon for which intel introduced
> Intel64), and it is also used by gcc to identify 64 bit p4's, so it
>
nd not found: HAVE_NATIVE_%3
>> > =yes: command not found: HAVE_NATIVE_%2
>> > =yes: command not found: HAVE_NATIVE_%3
>> > =yes: command not found: HAVE_NATIVE_%2
>> >
>> > And later:
>> >
>> > checking size of unsigned short... 0
&
_%3
=yes: command not found: HAVE_NATIVE_%2
And later:
checking size of unsigned short... 0
checking size of unsigned... 0
checking size of unsigned long... 0
checking size of mp_limb_t... 0
configure: error: Oops, mp_limb_t doesn't seem to work
Here it stops...
Gonzalo
On Sat, Mar 14
Thanks for the help with mpirbench. I wouldn't call that "just work",
so I redid the script to be more "automatic". It's pretty small when
binaries are not included (hint, hint), so I'm attaching it (I hope it
will make it through the lists).
To use
1) untar it
2) ./runbench
This figures out wh
On Sat, Mar 14, 2009 at 11:07 PM, Jason Moxham
wrote:
>
>
> I volunteer to to do the rewrite.I want to split the x86_64 into these
> microarchitectures
>
> mpn/x86_64/k8
> mpn/x86_64/k8/k10
While we are at this... The kvm issue I originally reported, for intel
cpus, is now fixed in trunk. There'
d.
>> >
>> > Sounds good , give us 30 mins to do it
>> >
>> >> Bill.
>> >>
>> >> 2009/3/14 Jason Moxham :
>> >> > Early Intel CPUs with Intel 64 lacked LAHF and SAHF instructions
>> >> > available in AMD64 unti
On Sat, Mar 14, 2009 at 10:29 PM, Bill Hart wrote:
>
> Yes, I hadn't thought about 64 bit processors running in 32 bit mode.
> My windows machine does that for example, so yeah, we have to leave
> the 32 bit stuff in, even for 64 bit processors.
A lot of people run linux 32bit in 64 bit processo
On Sat, Mar 14, 2009 at 3:13 PM, Bill Hart wrote:
>
> OK, but I'm still unclear why it doesn't pick up the files in the
> core2 directory. That is what it should do based on the code that is
> there. This means noconas are giving a generic C build, which I am
> sure Gonzalo would have complained
On Sat, Mar 14, 2009 at 2:41 PM, Bill Hart wrote:
> Not so clear what 32 bit ones should default to. I would say leave
> that for now. Are there even that many new 32 bit processors arriving
> on the scene these days?
The issue is not new 32 bit processors, but new 64 bit processors
running in 3
On Sat, Mar 14, 2009 at 1:45 PM, Jason Moxham wrote:
>
>
> I pretty sure all core2 cpus have lahf,sahf , it's just some Pentium D dont
> have it . You can test the lahf_lm feature bit in cpuid to see if it's got it
Tested in:
My laptop: model 6 / family 15 (core 2 duo T5300).
My desktop is fami
Here's a proposed fix. The rationale is to separate the decision logic
for intel family 6 in the two cases (32bit / 64bit). This is the same
as it's done for family 15.
In other words, with this patch, any intel processor running in 64 bit
mode is identified as either "nocona" (family 15) or "core
I reported this issue in sage trac
(http://trac.sagemath.org/sage_trac/ticket/5516), but I don't have an
account in mpir trac.
When running a 64 bit virtual cpu in kvm (72+dfsg-4, debian/lenny),
the virtual cpuid reports the cpu as:
vendor_id : GenuineIntel
cpu family : 6
model
Sorry, I mean to say *model* should be 1Ah (26) or 1Ch (28) for i7 and
atom, respectively. The family is 6 for both.
Gonzalo
On Fri, Mar 13, 2009 at 5:46 PM, Gonzalo Tornaria wrote:
> On Fri, Mar 13, 2009 at 5:00 PM, Jason Moxham
> wrote:
>>
>> On Friday 13 March 2009
On Fri, Mar 13, 2009 at 5:00 PM, Jason Moxham wrote:
>
> On Friday 13 March 2009 19:17:29 Bill Hart wrote:
>> Ah, this is an Intel Atom. We should have support for those by the end
>> of the day, hopefully.
>>
>> Bill.
>>
>
> nehalem is model 26 , so perhaps atom is 28?
> I'll svn it when I get i
On Tue, Feb 17, 2009 at 11:14 AM, wrote:
> I thought
> svn merge trunk/ branch/ .
I think you want
svn merge branch trunk
(merges branch into trunk, i.e. AT&T style, rather than intel style ;-)
Or else:
cd trunk # location of your trunk co -- SHOULD BE CLEAN
svn merge http://blablabla/...
In order to revert trunk to revision 1593, you actually need to do a
"reverse merge" of all the changes between r1593 and HEAD.
See:
http://svnbook.red-bean.com/en/1.2/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.undo
I guess something like:
svn merge -r HEAD:1593 .
should work.
On Sun, Nov 16, 2008 at 9:23 AM, Bill Hart <[EMAIL PROTECTED]> wrote:
> I realise there are only four things that really matter to me:
>
> 1) That my copyright notice be maintained.
> 2) That any offer to redistribute in binary form is accompanied by an
> equal offer to redistribute in source form
37 matches
Mail list logo
