From: <kha...@ma...> - 2004-04-16 12:28:45
|
Hi all, hi Grzegorz > Valery, IMO your reply is slightly agressive. oh, there was no aggression implied in any form! i am sorry for inducing feelings like that :( > If you think JIT is imporant for OpenC++ project, please explain why. sure i'll try. below. > I am sorry, I am unfamiliar with LLVM and JIT. Perhaps you could give a > brief intro? JITing is nothing more then ability to compile, link and manage code in general in run-time. JIT means Just-In-Time compilation. The most popular JITers are JIT from Java, LLVM and Parrot. JIT compilations makes Java implementations as quick as C++ implementations are. Every Lisp is JITer in a way too. Look at Bigloo as Java JIT Scheme implementation. Bigloo is as quick as gcc. LLVM is a great back-end solution for languages like Lisp, C#, for the interpreter languages, and languages, which use computational reflection extensively. > To make sure people are motivated you need to explain your idea first, and > motivate people next. that exactly what i have meant. Point 1. (C++ is static language, but some dynamics is possible via "new") Although C++ standard does not push implementer towards compiler-only language implementations still AFAIK all C++ implementations are de facto *compilers* and not iterpreters/JITs. There is no things in C++ standards today, which might demand compilation in run-time. In practice, all run-time demands might be resolved with operator "new", i.e. dynamic object allocation. With C++ in run-time one can not create new types or new functions. Point 2. (OpenC++ is fully static, no dynamic is possible) Instantiation of metaclass object is not possible in run-time. Indeed this should demand run-time compilation of corresponding base level class and linking the code to already running code, which is not feasible with gcc. Point 3. (dynamics in OpenC++ would be a useful thing) Imagine that one has some command-line tool, where the *behaviour* of the running code is changing massively with options like "--verbose" or "--debug". Let's consider option "--debug" which tells us about every member function call and turns on some additional checks. A metaclass VerboseClass is a nice approach to introduce these different types of application's behaviour. But if for "--debug" and non "--debug" option we have the same code then non "--debug" version will never show perfect performance. Indeed, with every member function call one will obtain implicitly an extra statement like: SomeClass::SomeFunc { if(debug_option_is_set) // do output and additional checks ... } which will cause (many) redundant checks in non "--debug" program invokation. And will disallow nice optimisations. One could say here: "why not to create at compile time all needed classes and then in run-time just invoke the corresponding one?". Well, it is a solution, but creating a code instance for an every command line option combination will blow up the code enormously. Point 4. (metaclasses are adequate to change class behaviour in run-time) Let's look into example above. The metaclass VerboseClass is a nice place to switch on/off verbose output. Even in run-time as well. But the problem is that VerboseClass will not make performance of non "--debug" invocation as good as possible. Because the code for --debug can t be recompiled. Point 5. (creating classes in run-time needs JITing/interpreter) Quite clear, that creating of new types/functions in run-time needs JITing/interpretation in run-time. Even worse: the recently compiled ready for execution modules should be bound somehow to already running code. Point 6. (LLVM could help to introduce JITing to OpenC++) what is LLVM one could read at this page: http://llvm.cs.uiuc.edu/ Important here is that LLVM can also generate and manage code in run-time. In example above, after starting command line tool the corresponding classes might be created and *compiled* according to option like "--debug". Id est, compiled in run-time. Thus, one could expect that invocation without "--debug" will be as quick as possible, because classes instantiated without "--debug" option do *not* have any debug related code anymore. > A question: I can see you have an idea, but do you also have resources to > implement it? No. But at least I'd be happy to invest the idea and motivation. > We (at least myself) can guide you through OpenC++ > architecture, help with infrastructure, but that's it. In particular, do > you want to contribute your time into implementation of your idea? I just don't have enough free time for such a monster job :( Only such a brilliant guys like Chris Lattner, Moshe Bar, Linus Torvalds, ..., ..., could bring such ideas to the life being full-time involved in that though. > It > takes lots of advocacy work to make other people implement your ideas. You are right, but I should try at least to clear my conscience. > Unless you are a university professor, of course :-) hehe, not yet, not yet. > PS: I am not posting this e-mail to llvm dev list, as I find it to be OT > there. right. BTW, as OpenC++ team the team of Chris Lattner makes a lot of changes to gcc and tracks gcc' versions. Maybe some communication between both teams might be fruitful? Have a nice day anyway! P.S. if this long letter will be lost again while sending process as its long predecessor then one will find again some traces of "aggression" in my short posts :) -- Valery |