Re: [Monetdb-developers] RFC: Upcoming release of MonetDB 4.10: Burkowski Code
On Tue, Jan 17, 2006 at 10:47:33PM +0100, Martin Kersten wrote:
Wouter Alink wrote:
My opinion, for what it is worth...
I would like to ask to leave the code in, because it (probably) would not harm anybody, and I would be happy.
But are you planning to stick to the stable release then? or do you switch to the development head directly? Does your users work with that stuff from the release?
I think that it can be removed from the release and stay in the development branch. This would make you happy and does not distract outsiders to use it too early.
Exactly that was my proposal: leave the Burkowski code in the development runk, but keep it out of the release. Since the release will not be configure with `--enable-burk` (most; see * below) of the respective code will not be compiled and the features will not be usable with the (binary) release, anyway.
Moreover, if I understand the comments of Jan & Jens (separate mail discussion between Wouter, Jens, Jan & me) correctly, the current burK implementation/integration does cause some significant(?) performance penalty in the burG generated code, which will harm the performance of XQuery translation significantly(?).
Hence, unless Wouter has some clients that need to use the release with Burkowski features (i.e., self-compiled from the sources), I make a strong point to keep the Burkowski code out of the release --- the next release (then with Burkowski code) will (must ;-)) be ready within 2 months from now.
(*)
"Even" for the development trunk, I'd suggest to try an use the macro BURKOWSKI (and an AC_CONDITIONAL that we should add), that is/are set with the --enable-burk configure switch, to remove ALL Burkowski related code from the compilation; i.e., (if possible) also the declarative parts in compiler/algebra/core2alg.brg, compiler/core/coreopt.brg, compiler/core/simplify.brg, compiler/semantics/typecheck.brg, as well as the changes in compiler/parser/parser.y, compiler/parser/scanner.l, & runtime/pathfinder.mx. In fact, Jan & Jens suggest to even reduce the changes in (at least) compiler/algebra/core2alg.brg to a minimum. Maybe, Jan & Jens can help with the *.brg file (also optimizing the indices), I could help with runtime/pathfinder.mx, and the AC_CONDITIONAL to avoid compilation of pf_burk unless configure with --enable-burk.
If we agree on keeping Burk out of the release, we have almost tow month to implement these improvements in the development trunk ;-)
Kind Regards,
Stefan
ps: the release must be ready by Sunday Jan 22, 23:59:59, hence a quick reply is appreciated; sorry for the hurry, but "external constraints" forced us on short notice to finish the release a few days earlier than planned ...
On Thu, Jan 19, 2006 at 03:13:30PM +0100, Stefan Manegold wrote:
[...]
Moreover, if I understand the comments of Jan & Jens (separate mail discussion between Wouter, Jens, Jan & me) correctly, the current burK implementation/integration does cause some significant(?) performance penalty in the burG generated code, which will harm the performance of XQuery translation significantly(?).
I don't have any numbers, but I think the performance penalty is not "significant". Don't worry.
[...]
"Even" for the development trunk, I'd suggest to try an use the macro BURKOWSKI (and an AC_CONDITIONAL that we should add), that is/are set with the --enable-burk configure switch, to remove ALL Burkowski related code from the compilation; i.e., (if possible) also the declarative parts in compiler/algebra/core2alg.brg, compiler/core/coreopt.brg, compiler/core/simplify.brg, compiler/semantics/typecheck.brg, as well as the changes in compiler/parser/parser.y, compiler/parser/scanner.l, & runtime/pathfinder.mx. In fact, Jan & Jens suggest to even reduce the changes in (at least) compiler/algebra/core2alg.brg to a minimum. Maybe, Jan & Jens can help with the *.brg file (also optimizing the indices), I could help with runtime/pathfinder.mx, and the AC_CONDITIONAL to avoid compilation of pf_burk unless configure with --enable-burk.
I think Wouter did the best we can do here already. BURG does not provide any preprocessing features, so we cannot skip any declarations based on ./configure options. The same argument holds for the Yacc grammar as well. Wouter did use preprocessor macros in the action code in both cases (right?), so I think the impact of the Burkowski stuff with --disable-burk is as small as we can get.
(Please don't come up with ideas such as feeding .brg and .y files into other preprocessors first. I really don't want to have that trouble in our code.)
Regards,
Jens
ps: the release must be ready by Sunday Jan 22, 23:59:59 [...]
Is Peter still in Argentina? Due to the time lag that could save us some hours. :-)
On Thu, Jan 19, 2006 at 03:45:44PM +0100, Jens Teubner wrote:
On Thu, Jan 19, 2006 at 03:13:30PM +0100, Stefan Manegold wrote:
[...]
Moreover, if I understand the comments of Jan & Jens (separate mail discussion between Wouter, Jens, Jan & me) correctly, the current burK implementation/integration does cause some significant(?) performance penalty in the burG generated code, which will harm the performance of XQuery translation significantly(?).
I don't have any numbers, but I think the performance penalty is not "significant". Don't worry.
Ok... So, we leave it as is (at least for now, and hence for the release) ?
[...]
I think Wouter did the best we can do here already. BURG does not provide any preprocessing features, so we cannot skip any declarations based on ./configure options. The same argument holds for the Yacc grammar as well. Wouter did use preprocessor macros in the action code in both cases (right?), so I think the impact of the Burkowski stuff with --disable-burk is as small as we can get.
Right. I didn't know about burg, but should have known about yacc/lex... Thanks!
(Please don't come up with ideas such as feeding .brg and .y files into other preprocessors first. I really don't want to have that trouble in our code.)
hm no .brg.mx.in |-(( ... well, I completely agreed, we shouldn't make it worse! ;-))
Regards,
Jens
ps: the release must be ready by Sunday Jan 22, 23:59:59 [...]
Is Peter still in Argentina? Due to the time lag that could save us some hours. :-)
He's back --- and I in fact mean(t) Sun Jan 22 23:59:59 CET 2006 ... ;-)
Stefan
participants (2)
-
Jens Teubner -
Stefan Manegold