I Tried three things:
./double_precision_optimized_matmult_d -q -t -x 512 -i 10000
./double_precision_optimized_matmult_d -q -t -x 1024 -i 1000
./double_precision_optimized_matmult_d -q -t -x 2048 -i 100
All reasonable results, though a tad short of what I imagine should be possible with the hardware.
First is not a problem, second results in the system freezing for ~1 second every ~7 seconds (choppy), third results in the system freezing for ~10 seconds every ~11 second (unusable)
looking at processor usage I see that 1 (of 4) cores gets ~ 100% utilization by the matmult_d program (reasonable because it's not a multithreaded app), and that (especially noticeable in the second case) the freezing glitches coincide with a drop in utilization of the cpu running matmult_d, and a jump (to 100%) of the utilization of the cpu running Xorg. Also I see that often Xorg and matmult_d "swap cores".
This pattern suggests to me that matmult_d is doing something that causes it to block waiting for Xorg, and then Xorg does something that is (seemingly) not interruptible. My first hunches are either something bus/DMA related or something kernel space related (perhaps spending too long in the fglrx kernel module with interrupts turned off?).
Would this be a correct assesment of the situation, and does this mean that it is up to the application programmer alone to maintain responsiveness of the system? If this is the case I am a bit woried about the potential consequences for system stability of using the proprietary fglrx driver. (Of course it could be Xorg's problem, but I'm not used to this kind of behaviour - but then again, I'm no Xguru).