> That compiler is the Apple one... switching away from it is essentially
> impossible (I don't know of anyone, anywhere that has ever been able to get
> Fortrran and C++ to link together on OSX using non Apple GCC). The Intel
> compilers used to be an option... but they have their own issues (
Good information guys! Our Mac user base is large so we'd have to consider the
cost of maintaining fink packages on end-user machines... so we'd probably
rather not go that route but it's good to know somebody is doing that. If I'm
not mistaken, the "compile" time of Apple's branch of the GNU
On Jun 16, 2011, at 1:09 PM, Boyce Griffith wrote:
> On 6/16/11 2:00 PM, Derek Gaston wrote:
>>
>> You have to remember that we use Macs
>>
>> That compiler is the Apple one... switching away from it is essentially
>> impossible (I don't know of anyone, anywhere that has ever been able to
On 6/16/11 2:00 PM, Derek Gaston wrote:
>
> On Jun 16, 2011, at 11:46 AM, Roy Stogner wrote:
>
>> I'm just saying that, even if we do make the switch, you should
>> upgrade your compiler too. If it flubbed std::fill that badly then
>> there's probably lots of other stuff it's not optimizing as w
On Jun 16, 2011, at 11:46 AM, Roy Stogner wrote:
> I'm just saying that, even if we do make the switch, you should
> upgrade your compiler too. If it flubbed std::fill that badly then
> there's probably lots of other stuff it's not optimizing as well as it
> should be.
You have to remember that
Apologies if I sent out an earlier version of this email already; our
NFS server is going nuts today...
On Thu, 16 Jun 2011, John Peterson wrote:
> We've stuck with the std::fill method for std::complex for now... I
> think in 99% of implementations memset should work there too, but I'm
> not su
On Thu, 16 Jun 2011, Roy Stogner wrote:
On Thu, 16 Jun 2011, John Peterson wrote:
On Thu, Jun 16, 2011 at 10:43 AM, Roy Stogner
wrote:
What compiler and flags are you using? It looks like the real
optimization you need here is a change in one or both of those!
GCC 4.2.1, -O3
And now
On Thu, Jun 16, 2011 at 19:16, Roy Stogner wrote:
> The GNU STL implementation is a twisty maze of passages, all alike, so
> I may have missed something, but the only obvious specializations I
> see are the memset-based char one and the vector implementation.
>
Why don't you disassemble the func
On Thu, 16 Jun 2011, John Peterson wrote:
On Thu, Jun 16, 2011 at 10:43 AM, Roy Stogner wrote:
What compiler and flags are you using? It looks like the real
optimization you need here is a change in one or both of those!
GCC 4.2.1, -O3
And now we know which one you need to change. ;-
On Thu, Jun 16, 2011 at 10:43 AM, Roy Stogner wrote:
>
>
> On Thu, 16 Jun 2011, John Peterson wrote:
>
>> Some results on my workstation for doubles: memset is roughly 2 orders
>> of magnitude faster than std::fill when it is measurable.
>>
>> N Fill method Memset method
>> 100 0.0121
On Thu, 16 Jun 2011, John Peterson wrote:
> Some results on my workstation for doubles: memset is roughly 2 orders
> of magnitude faster than std::fill when it is measurable.
>
> NFill method Memset method
> 100 0.012151s0.000625s
Here's what I get with a few compiler/optimiza
Excellent. Any objections to including and making it std::memset
instead?
On 6/16/11 11:07 AM, "John Peterson" wrote:
> Hi,
>
> We were doing some profiling here recently and were surprised when
> DenseMatrix::zero() showed up as 11% in a particular application!
>
> (You'll have to ask Dere
Hi,
We were doing some profiling here recently and were surprised when
DenseMatrix::zero() showed up as 11% in a particular application!
(You'll have to ask Derek why he was calling DenseMatrix::zero() so
many times ;-P)
If you replace std::fill() in this method with a call to memset (which
is l
13 matches
Mail list logo
