JIT compile failed

[Wei D.]

Hi!

I am currently using Freemat to write a few very simple codes to help
me manipulate data in Excel. It's basically opening a file, and do
some operation, the main part is 3 for loops one inside another.

However, I always get this message "JIT compile failed:" JIT compiler
does not support complex, string, END, matrix or cell defs" at line 22
of "docli".
On this line, all I have is a for loop (say, for i=1:m). The code
itself still runs, but very slowly without JIT (So i know all my
variables are real numbers and there are no grammar mistakes
anywhere). This also happens when I try to put a % infront of every
line except a random command like c=1, it would give me the answer of
"c", however, still points JIT failure at the same place (even if this
time, it's a simple comment instead of a for loop)


Also, when it's finally done compiling (after some 10 minutes) it
tells me "Cannot allocate enough memory to store an array of size
33998400", when all my loops multiplied together don't exceed 2
million operations...


It would be really helpful if I can get some help on this one!!

Thank you!

[Timothy Cyders]

Can you copy/paste your code? This would make troubleshooting much easier. The JIT compiler is very specific when it comes to how your for-loops are setup, and how matrices are defined. Example: if you say for i = 1:length(nels), JIT cannot compile this, because it can't compile the subfunction length(). If you say u = length(nels), then for i = 1:u, however, it _can_ compile this. It's all according to what's in the loop, and how it's defined. Hope this helps.

TJ

--
You received this message because you are subscribed to the Google Groups "freemat" group.
To post to this group, send email to fre...@googlegroups.com.
To unsubscribe from this group, send email to freemat+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/freemat?hl=en.

[Wei D.]

Hi!

Thanks a lot for the reply!

So my code starts with opening two matrices, reading their sizes, and
using these sizes as loop boundaries:

close all
clear all
clc

JUNE=dlmread('P:\some excel file.csv',',');

[p,q]=size(JUNE);
MINUTE=zeros(p,75);

c=1;
k=3;
for i=1:p
for t=2:38

MINUTE(c:c+9,k)=JUNE(i,t);

k=k+2;
end

c=c+10;
end


As you can see, it's a very simple code. When I write p, or q, it
gives the size of the file I read without problem...

Thank you again!

> >http://groups.google.com/group/freemat?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Timothy Cyders]

Looks like the problem is here:

MINUTE(c:c+9,k)=JUNE(i,t);

Specifically, the use of the colon operator to call elements in the matrix doesn't seem to get along with JIT. Since JIT does nested loops really well (and REALLY fast), I would propose that you nest a loop in it like so:

for i=1:p

   for t=2:38

      for u = c:c+9

           MINUTE(u,k)=JUNE(i,t);

      end

   k=k+2;
   end

c=c+10;
end

Give that a shot and let me know if it helps.

TJ

[Wei D.]

I actually started off with this third for loop, but replaced it with
the colon operator thinking that maybe it'll make the code run faster.
Both of these are not working...

I don't know if this is an indication, but everytime it finishes
running, a pop up window would say "Cannot read file docli, no such
file found on path list"...

> > > >http://groups.google.com/group/freemat?hl=en.-Hide quoted text -

[Wei D.]

And sometimes, instead of the previous error message, it will say "JIT
compile failed:"JIT compiler doesn't work with verbose statements" at
line 22 of "keyboard"...
this statement would be the same for loop (for i=1:p)

> > > > >http://groups.google.com/group/freemat?hl=en.-Hidequoted text -

>
> > > > - Show quoted text -
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "freemat" group.
> > > To post to this group, send email to fre...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > freemat+u...@googlegroups.com.
> > > For more options, visit this group at
> > >http://groups.google.com/group/freemat?hl=en.-Hide quoted text -
>

> > - Show quoted text -- Hide quoted text -

[Dominik Lenné]

Just to give some enrichment to the JIT problems:

I'm afraid to have a very similar problem with the JIT compiler. Any loop of the form

for i=1:250
  do something;
end;

creates a message like this

JIT compile failed:"Unsupported type encountered" at line 8 of "docli"

This happens only when used in a script, not when used in the command line window.

yours Dominik

[EI]

Dominik,

This is not an error. Basically every loop in a script Freemat first tries to compile into machine code. If it succeeds your code will run a heck of a lot faster. Otherwise we print a warning and interpret the script. JIT compiler is limited in the code it can compile - e.g. it helps mostly with loops that involve simple double arrays and standard functions. 

Eugene

--
You received this message because you are subscribed to the Google Groups "freemat" group.

To view this discussion on the web visit https://groups.google.com/d/msg/freemat/-/7LtDtD8SiyoJ.

[Dominik Lenné]

Yeah, I just recently found freemat and find it a gem. Are there rules and examples about what the JITC manages to compile and what not? This would be of great value for many, I suppose.

Dominik

[Jonathan Weaver]

Wie D,

I try to eliminate loops in my code whenever possible (I don't like leaning on the JIT Compiler).  Try this:

a = zeros(q, 10, p, 2);
a(:,:,:,1) = shiftdim(repmat(JUNE,[1,1,10]),1);
a = shiftdim(a,1);
MINUTES = [zeros(10*p,1), reshape(a,[10*p, 2*q])];

-Jonathan

[EI]

We don't really have rules written down. With a bit of additional effort JIT can be expanded to allow accelerating more and more code (if you followed matlab jit evolution, that's what they are doing with each release, at least judging from my code performance). 

Some things are almost impossible to jit compile (at least without affecting performance for the "commong" case). For example compiling code where data types change during execution either require type checking before each operation (slow) or sophisticated type inference (too complicated). Same goes for functions where we can't determine return types (e.g. imported functions). 

Eugene