Menu
▾
▴
Re: [xmlvm-dev] C backend and library
|
From: Arno P. <ar...@pu...> - 2011-06-10 16:17:23
|
I think that is a good idea! For development mode the size of the itable does not matter. Arno On Jun 10, 2011, at 10:02 AM, Markus Neubrand <mar...@gm...> wrote: Forgot to mention: Alternatively we could color the app with a safe offset (e.g. 100) to avoid clashes in "development mode". But that would blow up tib sizes quite a bit. 2011/6/10 Markus Neubrand <mar...@gm...> > We would still need to store the selector graph: A class in the app could > implement its own interface as well as implement a JDK interface at the same > time. For this case I need to know how the original JDK interface was > colored to avoid clashes. > > For the vtable optimization implementing the "development mode" should be > simple. > > > 2011/6/10 Arno Puder <ar...@pu...> > >> >> I'm thinking of a "development mode" where no optimizations are performed. >> For vtable this means that all methods go into the vtable by default. That >> should be much easier than disabling itable optimizations. >> >> With regards to time savings: I suspect that a library would be >> beneficial. Keep in mind that compile time includes XMLVM compile time as >> well as Xcode compile time. XMLVM would only need to compile the application >> without computing the transitive closure of all referenced classes (let >> alone cross compiling these classes) and Xcode would "only" need to link a >> huge library (where I suspect that that will be faster than compiling >> everything). But of course I don't have empirical evidence. >> >> Arno >> >> >> On Jun 10, 2011, at 9:21 AM, Markus Neubrand <mar...@gm...> >> wrote: >> >> Hi, >> >> For the vtable optimization for non-overridden methods I don't see a >> possibility to do this at all. If we compile everything into a library we >> never know when a class of the application overrides something in the JDK, >> etc. >> >> For the selector coloring we could implement a possibility to save the end >> state of the colored graph for the library and use this information when we >> color the selector graph of the application. >> >> But I agree with Sascha: it would be nice to know if this would speed >> things up significantly before we start with something like that. >> >> Markus >> >> 2011/6/10 Sascha Haeberling < <sa...@gm...>sa...@gm...> >> >>> Are we even sure that linking against such a huge library would really be >>> that much faster? From my experience linking huge binaries can take a long >>> time as well. >>> >>> In the end it looks like this: timeSaved = (timePipelineNow - >>> timePipelineThen) - timeLinking >>> >>> If the times saved is small, the question is whether it makes sense >>> investing time into it at all. Therefore it would be good to have some >>> estimates first. >>> >>> // Sascha >>> >>> >>> 2011/6/10 Arno Puder < <ar...@pu...>ar...@pu...> >>> >>>> Yes, we've had this discussion before. Basically creating a Unix-like >>>> library (.a) that speeds things compilation time. However, the problem >>>> is that (at least) for now it wouldn't work with the C backend. We do >>>> optimizations that go beyond the simple decision "should this file be >>>> included or not" (what the linker typically does, and which, btw, is >>>> also performed by XMLVM at compile-time). We also optimize things like >>>> vtables, e.g., if a method never gets overridden, it will not end up >>>> in the vtable. This knowledge, however, only exists if we take the >>>> application into account. If the application overrides a library >>>> method, then the cross-compilation of the library also needs to >>>> change. >>>> >>>> I agree that for a regular development cycle it would make sense to >>>> have something like a library and only do full optimizations for the >>>> final release. We would need a way to cross-compile without >>>> optimizations. One big problem I see here are interface methods >>>> (because of the selector coloring scheme that is used), but I better >>>> let Markus respond to this since he implemented those optimizations. >>>> >>>> Arno >>>> >>>> >>>> On Jun 10, 2011, at 6:26 AM, Panayotis Katsaloulis >>>> < <pan...@pa...>pan...@pa...> wrote: >>>> >>>> > >>>> > On 10 Ιουν 2011, at 3:11 μ.μ., Sascha Haeberling wrote: >>>> > >>>> >> Panayotis, >>>> >> >>>> >> sorry, I didn't understand what you mean. What do you mean by "the >>>> library"? The C backend does compute all dependencies so that the number of >>>> classes that are compiled and outputted in the end is at a minimum. Only >>>> required classes will be pulled in. Why would you want to replace this and >>>> with what? >>>> >> >>>> >> // Sascha >>>> > >>>> > >>>> > This is from an old discussion. >>>> > >>>> > The idea is to compile the whole JDK and iPhone compatibility library >>>> (and probably other dependencies) into a C library (i.e. in a form of .a >>>> file) and compile the project against this library. >>>> > Thus the Xcode project will compile much much faster and even the >>>> production of the Xcode project will be faster (and smaller) since no files >>>> from the JDK and the compatibility library will be required any more. >>>> > >>>> > This idea was also in the earlier days of ObjC backend, but due to the >>>> way ObjC handled dependencies and late binding, the gain was far less. >>>> > Now with the strong typed C language, things should be much better. >>>> > >>>> > For example, if a function is not used at all, the C compiler >>>> understands that and never embeds it into the output binary - we have >>>> optimizations in the method-level, instead of the class-level. >>>> > >>>> > >>>> > I don't know how virtual functions are handled and probably Arno could >>>> help with this. >>>> > >>>> > >>>> > PS: I remember that ProGuard is also able to perform this type of >>>> optimizations and it is already used for this reason in Android projects. >>>> Probably we should also do something similar? >>>> > >>>> ------------------------------------------------------------------------------ >>>> > EditLive Enterprise is the world's most technically advanced content >>>> > authoring tool. Experience the power of Track Changes, Inline Image >>>> > Editing and ensure content is compliant with Accessibility Checking. >>>> > <http://p.sf.net/sfu/ephox-dev2dev>http://p.sf.net/sfu/ephox-dev2dev >>>> > _______________________________________________ >>>> > Xmlvm-developers mailing list >>>> > <Xml...@li...> >>>> Xml...@li... >>>> > <https://lists.sourceforge.net/lists/listinfo/xmlvm-developers> >>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> EditLive Enterprise is the world's most technically advanced content >>>> authoring tool. Experience the power of Track Changes, Inline Image >>>> Editing and ensure content is compliant with Accessibility Checking. >>>> <http://p.sf.net/sfu/ephox-dev2dev>http://p.sf.net/sfu/ephox-dev2dev >>>> _______________________________________________ >>>> Xmlvm-developers mailing list >>>> <Xml...@li...> >>>> Xml...@li... >>>> <https://lists.sourceforge.net/lists/listinfo/xmlvm-developers> >>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> EditLive Enterprise is the world's most technically advanced content >>> authoring tool. Experience the power of Track Changes, Inline Image >>> Editing and ensure content is compliant with Accessibility Checking. >>> <http://p.sf.net/sfu/ephox-dev2dev>http://p.sf.net/sfu/ephox-dev2dev >>> _______________________________________________ >>> Xmlvm-developers mailing list >>> <Xml...@li...> >>> Xml...@li... >>> <https://lists.sourceforge.net/lists/listinfo/xmlvm-developers> >>> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers >>> >>> >> > |
