Message-ID: <4CD411D7.6010605@cwilson.fastmail.fm>
Date: Fri, 05 Nov 2010 10:16:55 -0400
From: Charles Wilson <cygwin@cwilson.fastmail.fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: Cygwin paths in mingw64
References: <30139174.post@talk.nabble.com> <285084.61145.qm@web25502.mail.ukl.yahoo.com>
In-Reply-To: <285084.61145.qm@web25502.mail.ukl.yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On 11/5/2010 4:44 AM, Marco Atzeri wrote:
> if you are interested in the 64bit performance of Atlas
> you should work with a 64bit version of linux.
> 
> As the original developer don't use windows as platform,
> and Atlas is not only system dependent but also CPU core
> dependent, you have little hope to build a 64bit windows 
> version using cygwin as platform.

The problem is, atlas is self-tuning. The idea is its build process
compiles itself in many different ways, and then actually tests the
performance on the target platform.  When cross compiling, you can set
it up so that it will ssh to the actual target and run the test
apps...but that requires the $target machine has (a) sshd and (b) a
unix-like shell.

This is obviously a difficult hurdle for $target=native win32/64.

One MAY be able to "cheat" by specifying, somehow, the "correct"
optimizations a priori, so that the build system doesn't try to do the
remote tests, but I'm not sure.

I do know that SOMEBODY out there has solved these issues wrt 32bit
win32, because MatLab actually uses ATLAS as its core BLAS
implementation, under the hood.

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple