On the 0x3CF day of Apache Harmony Xiao-Feng Li wrote: > On 17 Jan 2008 18:06:54 +0300, Egor Pasko <[EMAIL PROTECTED]> wrote: > > On the 0x3CE day of Apache Harmony Simon Chow wrote: > > > Actually, we are targeting at x86 platform :) IPF is not concerned until > > > now. > > > > Now it turns to be more real > > > > > I am sorry that I did not make this clear before. > > > Now we just plan to enhance OPT using Open64 only for loops and other > > > computation-intensive sections. > > > > > Does it have some opportunities for performance improving? > > > > OK, so, you probably are most interested in high-level > > optimizations. There are opportunities. We are constantly working on > > this kind of optimizations and constantly get improvements here and > > there. > > > > many optimizations benefit from knowledge of Java specifics, for > > example, semantics of virtual calls (we can "devirtualize") or > > eliminating unnecessary array bounds checks. A C/C++/Fortran compiler > > won't do it for you. So, I guess, you will need to apply open64 > > optimizer after all inlining, unrolling, etc., etc. by Jitrino.OPT. > > > > And since Java code is naturally full of explicit null-checks, > > bounds-checks, virtual and interface calls, C compiler won't be able > > to optimize across these things unless you teach it to do so. > > > > Looks like a lot of work to do, but not actually much room for > > performance improvement. This is my humble opinion. > > > > > As you said, code motion and prefetch optimizations is more helpful in C > > > compilers, > > > and what is the advantaging we can take using JIT compiler? profiling? > > > and? > > > > ..and in-depth knowledge about Java specifics > > > > > I have little experience here. > > > > > > And I have not tried DRLVM on IPF yet... > > > > me too :) > > > > P.S.: Xiaofeng, I am personally fond of your way of generating a lot > > of research around Harmony. I would be happy to learn from you. But > > don't you think that this specific task is overkill? Maybe, we can > > find some equivalent cool optimizer-related subject within Harmony? > > For example, we could know that Open64 does optimization A better than > > Jitrino. The task is: investigate and reimplement A in Jitrino. This > > eliminates the licensing problem as a bonus. > > Egor, I should not talk too much here about their project, but it's > not Harmony project, it's Open64 project.
Ah, OK then, sorry, I probably talk too much :/ > Thanks, > xiaofeng > > > > > > Thanks > > > > > > On 17 Jan 2008 15:41:08 +0300, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > > > > > On the 0x3CE day of Apache Harmony Simon Chow wrote: > > > > > On 17 Jan 2008 13:31:05 +0300, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > On the 0x3CE day of Apache Harmony Simon Chow wrote: > > > > > > > On 17 Jan 2008 11:08:54 +0300, Egor Pasko <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > > > > > > > On the 0x3CD day of Apache Harmony Simon Chow wrote: > > > > > > > > > I am studying OPT in jitrino. For understanding the process of > > > > > > building > > > > > > > > CFG, > > > > > > > > > I have read some code of JavaByteCodeTranslator. > > > > > > > > > In the constructor of JavaByteCodeTranslator, there is an > > > > additional > > > > > > > > pass > > > > > > > > > named JavaLabelPrepass, > > > > > > > > > I would like to ask what is the exact purpose of this pass? > > > > > > > > > > > > > > > > the purpose is to mark basic blocks and inference stack > > > > > > > > variables > > > > and > > > > > > > > local variables with their types. > > > > > > > > > > > > > > > > This information goes to the input of JavaByteCodeTranslator, > > > > which in > > > > > > > > single pass goes through each bytecode instruction and converts > > > > > > > > it > > > > to > > > > > > > > operand-based representation from the stack-based in bytecode. > > > > > > > > > > > > > > > > The problem is a little tricky (with variable merging logic) and > > > > > > > > current design is poor. > > > > > > > > > > > > > > > > > Besides this, It is seems that the translator part will be > > > > refined, > > > > > > > > which I > > > > > > > > > saw in the wiki. Has it already been done in the current > > > > version? > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > no, translator is not refined, low priority task. > > > > > > > > > > > > > > > > Why do you study the process of building CFG? If you want to do > > > > > > > > something with it, I would suggest to try some other place since > > > > all > > > > > > > > JIT people here will agree that debugging JavalabelPrepass is > > > > > > > > brain-damaging. > > > > > > > > > > > > > > > > > > > > > Thank! > > > > > > > I am doing a project for combining static compiler with dynamic > > > > > > compilation > > > > > > > environment (jitrino.OPT) > > > > > > > As first step, now I am planning to translate the Harmony IR to > > > > WHIRL. > > > > > > > > > > > > hm, do you have a kind of draft design document on how you want to > > > > > > do > > > > > > this? ..probably Harmony gurus can give some valuable input having > > > > > > read this doc. > > > > > > > > > > > > > > > There is no document for this yet, but I will write one in the next > > > > > few > > > > days > > > > > after having a discussion with others in my group. > > > > > Our static compilation platform is Open64, some of my teammates are > > > > working > > > > > on it. > > > > > > > > just to make sure.. is the primary goal to replace/enhance Jitrino.OPT > > > > on IPF machines? Oh, those itanics.. > > > > > > > > > I only have a little understanding of jitrino.OPT. > > > > > For achieving higher performance, which part or phases of > > > > > jitrino.OPTcould > > > > > be refined or replaced by Open64 optimization? > > > > > Could you give me some suggestion? > > > > > > > > I am afraid I am not familiar with Open64 at all, and there are > > > > concerns using a mix of Jitrino.OPT and Open64 since the latter is > > > > licensed under GPL. So, do not show me their code :) > > > > > > > > Jitrino.OPT/IPF is rather immature/experimental/untested/etc. So, if > > > > using Jitrino.OPT on IPF consider throwing away the code generator > > > > (but take care about generating the right calling convention and > > > > VM-related stuff like threading) > > > > > > > > As for the High-level optimizations, I do not know, where Open64 is > > > > better, maybe Xiaofeng knows? :) > > > > > > > > I may try to forsee something: Fortran & C compilers have more freedom > > > > for code motion and prefetch optimizations than a Java JIT compiler > > > > (which has a more dynamic nature), so, when ported to Java realities a > > > > C compiler is likely to behave not very cool. > > > > > > > > I would suggest you to enhance Jitrino IPF codegenerator in > > > > if-conversion and register allocation, that looks like more > > > > interesting and performance-beneficial. However, I am not sure if it > > > > suits you good as a subject of research. > > > > > > > > Did you try running DRLVM on IPF? Does it work? Does it even compile? > > > > > > > > > By the way, This idea is original from Xiaofeng :) > > > > > > > > > > Thank you every much! > > > > > > > > > > > But I can not find more information for the CFG structure in > > > > jitrino.OPT, > > > > > > > which leads me to read the code in translation part. :( > > > > > > > Any advice for this? > > > > > > > > > > > > there is no complete reference guide for HIR instructions yet. Once > > > > > > I > > > > > > gave advice on this: > > > > > > > > > > > > http://article.gmane.org/gmane.comp.java.harmony.devel/24474/ > > > > > > > > > > > > feel free to ask specific questions on CFG and instructions :) > > > > > > > > > > > > -- > > > > > > Egor Pasko > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > From : [EMAIL PROTECTED] School of Fudan University > > > > > > > > -- > > > > Egor Pasko > > > > > > > > > > > > > > > > > -- > > > From : [EMAIL PROTECTED] School of Fudan University > > > > -- > > Egor Pasko > > > > > > > > -- > http://xiao-feng.blogspot.com > -- Egor Pasko
