[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: octave and LLVM google summer of code project
From: |
John W. Eaton |
Subject: |
Re: octave and LLVM google summer of code project |
Date: |
Sun, 20 Apr 2008 17:28:43 -0400 |
On 20-Apr-2008, Eugene I wrote:
| Right now we simply jit compile loop blocks. Either the whole block is
| compiled or it is interpreted. Functions are expanded in jit compiled code
| (almost treated like macro) - not ideal, but simplifies everything. For type
| inference you can take a look in JITFunc::compile_assignment.
| How about something like this:
| function tjit1
| A = zeros(512,512);
| for i=1:512;
| for j=1:512
| k = i-j;
| if ((k<5) && (k>-5))
| A(i,j) = k;
| else
| A(i,j) = 0;
| end
| end
| end
|
| In this case jit compiler can generate code which is almost as fast as
| equivalent C code.
For the above function, how does performance compare to
nr = 512;
nc = 512;
a = zeros (nr, nc);
for i = 1:3
a(1+i:nr+1:(nr-i)*nc) = i;
end
for i = 1:3
a(i*nr+1:nr+1:nr*nc) = -i
end
I'm not saying that the JIT compiler it isn't useful, or even that my
semi-vectorized solution is great (it is not really easy to read), I'm
just curious about the difference. OTOH, I would really hate to see
people start to write things like
for i = 1:512
for j = 1:512
a(i,j) = (j-1)*512+i;
end
end
instead of
a = reshape (1:512*512, 512, 512);
even if the performance is the same...
| It even knows how to compile array indexing directly.
Just when the array indices are scalars or any values? If they are
any values, doesn't that mean relying on some library code to do the
indexing? In Octave, that code is fairly complicated to handle
logical indexing, array indexing, indexing when there are more or
fewer indices than array dimensions, etc.
I assume we are talking about the LLVM JIT compiler. Looking at the
LLVM web page, the JIT compiler apparently supports X86, X86-64,
PowerPC and PowerPC-64 systems. This may be the majority of systems
today, but what about other systems? For example users of Octave on
SPARC or Itanium systems might want to see the improved performance as
well (I'm not saying that it is not worth doing even if only a limited
number of systems are supported, just that there may be some
limitations).
jwe
- Re: octave and LLVM google summer of code project, (continued)
- Re: octave and LLVM google summer of code project, David Bateman, 2008/04/09
- Re: octave and LLVM google summer of code project, Eugene I, 2008/04/19
- Re: octave and LLVM google summer of code project, dbateman, 2008/04/19
- Re: octave and LLVM google summer of code project, Eugene I, 2008/04/19
- Re: octave and LLVM google summer of code project, dbateman, 2008/04/20
- Re: octave and LLVM google summer of code project, John W. Eaton, 2008/04/20
- Re: octave and LLVM google summer of code project, John W. Eaton, 2008/04/20
- Re: octave and LLVM google summer of code project, Eugene I, 2008/04/20
- Re: octave and LLVM google summer of code project, John W. Eaton, 2008/04/20
- Re: octave and LLVM google summer of code project, Eugene I, 2008/04/20
- Re: octave and LLVM google summer of code project,
John W. Eaton <=
- Re: octave and LLVM google summer of code project, Eugene I, 2008/04/22
Re: octave and LLVM google summer of code project, Wolfgang_M, 2008/04/15