[Gllug] Programming for performance on Linux

[James Courtier-Dutton]

On 14 May 2010 21:35, Shlomi Fish <shlomif at gmail.com> wrote:
> On Tue, May 11, 2010 at 2:58 PM, James Courtier-Dutton
>> Can anyone thing of a better or alternative approach?
>
> This seems like a good approach. Generally data proximity and
> sequentiality are a good strategy. Of course, like other people noted
> about premature optimisation, first get it to work, and work well and
> correctly; and only then see if it's not fast enough, and if so,
> optimise it after profiling it and finding the bottlenecks, (or
> possibly trying to tweak various parts of the algorithm and seeing if
> it yields an improvement.). Given modern hardware, and if you write
> the program in a fast language such as C or C++, with modern compilers
> (recent versions of gcc should be OK.), then your program will likely
> be fast enough without needing to tweak it to death.
>

Thank you for the links.
I also found a spectacular concept for speeding up algorithms.
http://85.17.209.13:6100/sc

The interesting bit is the FFdecsa documents.
This programmer has found a way to take an algorithm that is
inherently slow. I.e. decryption on the x86 CPU, and speed it up
12800%!!!
The slow bit is generally the S boxes where say, bit 1 must be moved
to bit 5, bit 2 moves to bit 3 etc. I.e. One would need as separate
shift instruction for each bit, but if this is done in hardware it
would be instant as one just connects the wires up to do the bit
moving.
The really excellent thing this programmer has done is realise that
although I need one instruction for processing bit 1, and another for
processing bit 2 etc. I can handle 128 bit1s per instruction. So, he
can actually handle 128 encryption sections for the same cost as
one!!!
I will obviously be using this idea for my algorithm if at all possible.
An immediate 12800% improvement in performance is worth a try at least!!!
The most specific question I was asking the group was how best to move
this from being on just one CPU to 4 CPUs in a single machine.

Kind Regards

James
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug