| Re: [eigen] Totally missing /O2 for MSVC-Compiler |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Totally missing /O2 for MSVC-Compiler
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Fri, 30 Jan 2009 23:33:28 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=a+PHwXWS0txgDWcUIMNGaAV+WEmm5hx9D/j3yAqwHcU=; b=ST0U2oSrB6MaXPieJd9leXFf4iJJwcY+91A6A1QR8Z6BQT3D1EWRo+qecS6T3H0bbY /KAPiEL5dOOHW8oQd+ow2N1y1qOsPTmX+TJaAp4F8Au1xi7V7mG6XUTYjQSZx9gkDHIT DkuNcEJZGZCmGzqKZ1EGFXlwXFip5Y1ulqDis=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=d9dqrwHjWgaabyJWdsSaDk7zwpGo+B3AdwWQE2+JqJ23CDzKLsPU/t+5H4PQGd9VKM p/WcHLE1Ge6JNml3m8so1jgEBeEFH+vMfQyO3tK36hXkyq4gW0N5VzLBnPhhvFD4EPvK KuW4lGDt4HBI1ReBuOOut/Rq0kaiPy+5L77+w=
On Fri, Jan 30, 2009 at 8:34 PM, FMDSPAM <fmdspam@xxxxxxxxx> wrote:
>> I don't really understand what you meant here ? but FYI I'll make sure
>> the large_product test and lu test will be always compiled with /O2
>> for msvc (otherwise they take too long to run).
>>
>
> OK, but why only these both testcases?
> a) I would consider to test all under the hardest conditions available.
> b) a general use of the compiler flags, causing the best possible
> performance is what we want to do in real use cases.
yes, of course, we should also run the tests in release mode. The goal
in making the debug mode the default one is to be able to debug broken
tests right away! Theoretically, using -DCMAKE_BUILD_TYPE=release
should do the job, but with MSVC I think you still have to choose
"release" from the UI. I don't know about NMake projects.
> I will take a look inside this and post valuable result, if any.
> Having in mind additionally test in regard of e.g. the /fp flag in terms of
> correctness and performance.
> I all is going fine, I consider to cdash several configuration on a regular
> basis. Objections ?
no pb
> FYI:
> Your original form "process initial unaligned coeffs" cachfriendlyproduct.h
> will to the job now perfectly, even with "complete optimization" (/Ox) flag
> set for all use cases. I have attached the revert patch. Maybe the your
> original form is cleaner and should be recreated?
ok, I'll do that.