|Re: [eigen] about changeset 6eb14e380|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] about changeset 6eb14e380
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Wed, 18 Aug 2010 11:21:39 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=4CP5/WErJm0eEUZMfwd4JJIdlGtV6D+YXc5f7QF3feM=; b=tAG8LRxbMSw7i6PTu5AUbyuq2JAJA4JojobODRt7OtG7u6qB6pLiuChOlxwINIrUcD dPOt/Dn+BfbxtcOrgyEShyPLTKk4GSQOsRLZNffYmed5UuYiZPSdsafkvOfPPuqxtmFh P6CnZQFNhPG/QOieFzMj+TqXemM2pAcSpPxHA=
- 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; b=pt6IeUEpQUnM4KCAHN4B0QmOTn6k9aGevlHuKfUhUpxMfrmqChfikfs+NI68y29O81 L9QjdzQwhc4QuMoYbsICsQiQvG5VKvm4SR4xJgegtg9n+eiauLMgudd7C60lp4TXVNkp oyYriFJYAfbMy0TePhPVazd0H9nAUem+kUAic=
2010/8/18 joel falcou <joel.falcou@xxxxxx>
Now you make me doubt. I'll check again. Fact is our alignment code use the cache line size as boundary so we never really checked.
On 18/08/10 17:07, Benoit Jacob wrote:
ah OK. I was naively hoping that alignment requirements wouldn't necessarily keep increasing with the packet size :-(
I was going to ask about that. Do you think this makes for a significant performance improvement for real-world dynamic-size matrices (size at least 32x32) ?
Next question: can't cache line size vary even within a particular architecture? Although that probably doesn't matter since I guess it'll always be bigger than any alignment _requirement_ (it'll be at least 64 bytes, right? which is bigger than any SIMD instructions require, right?)
Well, I can comment as we don't support such use-case (new arch == new compilation)
It is my understanding that when x86 and x86-64 cpus come out with AVX instructions, people will want to generate executables that determine at runtime the availability of AVX, and switch between AVX and non-AVX code based on that. So ABI compatibility is going to be more important than ever. Right?
For us too, new simd platform == new compilation, but we support the use case that consists in compiling the same code N times for N different SIMD configs, and switching between these N paths at runtime. This requires Eigen data structures to have the same ABI across different SIMD configs (i.e. SSE / no SSE), withing a given CPU arch (i.e. x86).