• Magnus Hem (47/47) Feb 11 2007 Hi! Unlike everybody else in this forum, I'm not a compiler expert. My

Magnus Hem <mag72nus hotmail.com> writes:

Hi! Unlike everybody else in this forum, I'm not a compiler expert. My
expertise is image processing, and I badly need speed for heavy calculations.


However, I doubt that the D is made for the future computer architecture.
I assume that future computers will be characterized by massive parallelism
1. SIMD, streaming and saturation arithmetics (e.g. MMX, SSE)
2. Multiple cpu cores
3. Latency of memory access
4. Branch penalty
5. Parallel pipes of execution, within the same thread, such as in the Cell
processor, see   http://www.research.ibm.com/journal/sj/451/eichenberger.html
 and  http://en.wikipedia.org/wiki/Cell_BE


My focus is (5), but first a few words about (1)-(4)

1. SIMDization seems to be a challenge in compiler technology. Saturation
arithmetics requires special data types. Let's focus on (5).Each thread can
run different. Memory alignment improves performance, in particular for
writes. (I guess Walter is well aware of this when designing multi-dimensional
arrays)

2. Multi-core calls for simpler thread handling. This doesn't have to be part
of the language. A library will do. OpenMP pragmas are also useful. I do
however like the way Ruby loop constructs. What about the following syntax?
ThreadLibrary::ForEachCPU() { |int iThread, int numThreads|
  compute_something;
} // wait here until all threads exit


3. Prefetch instructions are crucial for speed. I hope the compiler can handle
this. Maybe

4. Branch prediction may be handled by standardized pragmas, or an additional
argument to each statement causing branches. Example if( x==5; 0.1) where 0.1
is the probably is true. While (x<100; 0.01)


5. Parallelism within the same thread calls for changes in the programming
language. The average programmer shall not worry about threads and
synchronization. We've learnt from Haskell that the compiler can handle all
synchronization in a purely functional language. I suggest the following
changes to D:
  5.1 Possible to declare functions as purely functional.
  5.2 Pure functions may return multiple output arguments (Matlab/Octave)
  5.3 Procedures may declare side effects. Which parameters are input only,
      which are output-only, and which are both input and output. Member
procedures may also tell whether they change 'this'
  5.4 Class Methods shall also be declared whether they read/write member
variables. Example syntax
     function [int x, int y] = Compute(this, int a, double b)
  5.5 And statements (a&&b) shall be allowed to evaluate b despite a
      returns false.
  5.6 for-while-foreach() shall be allowed to loop in any order, or in parallel
  5.7 Introduce loops without order. I like Ruby syntax integer.times()

What do compiler experts think?