home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 31,543 of 33,346   
   nmm1@cam.ac.uk to loufoque@gmail.com   
   Matrix Class design [was Re: Using the S   
   05 Oct 11 03:32:01   
   
   98c84967   
   In article ,   
   Mathias Gaunard   wrote:   
   >   
   >For a dense matrix or nD array, you'll want to pad the lines on cache   
   >lines (not needed in 1D, but a very good idea in nD for decent   
   >performance)   
      
   Grrk.  It's not that simple, and depends on the use and architecture   
   (mainly associativity).  You can very easily overload the latter on   
   the very common 'other way' (i.e. row/column) accesses, which is   
   why LINPACK tests on both a power of two and on a non-power.  I am   
   assuredly not denying that it CAN help, a lot, but it can also harm,   
   a lot.   
      
   >and generate an iliffe index to avoid multiplications and   
   >additions when doing random access (not possible on certain hardware   
   >platforms that do not support pointers of pointers -- though those   
   >platforms are not really C++).   
   >Putting the iliffe buffer and the data in the same page can be a good   
   >idea too.   
      
   No, that's very 1970s, even in a relatively unoptimisable language   
   like C++ - Fortran has adopted the Algol 68 triple approach, and   
   evidence is that it is quite a lot faster nowadays.  Multiplications   
   are a LOT cheaper than even level 2 cache accesses, despite the   
   pig's ear that most architectures make of integer ones.  But the   
   real reason is that you can take an arbitrary rectangular section   
   of an n-D array and treat it just like a newly allocated m-D one.   
   That REALLY improves the clarity of code, as Algol 68 demonstrated.   
      
   I am going to look at boost::multi_array fairly carefully, but I   
   believe that a C++ class could be as efficient as modern Fortran   
   array handling.  For example, there is nothing stopping a class   
   having multiple iterator methods, which would provide the strength   
   reduction optimisation that is easy in Fortran but trickier in C++.   
   Yes, I mean strided iterators along any dimension, but it would   
   also be possible to support diagonals and iterators that deliver   
   sections.  Let's see how well boost::multi_array measures up :-)   
      
   >You'll also need write primitives for resizing, extending, reshaping   
   >and concatenating along a particular dimension.   
      
   And more ....   
      
      
   Regards,   
   Nick Maclaren.   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca