Hi all, Please forgive my ignorance, but is there any chance GiNaC might move away from CLN and in its place use a "softer" library such as NTL? (http://www.shoup.net/ntl/) At least then we might have a chance of moving away from (or at least not kneeling before) Mark Mitchell and his GCC henchmen ;-) What sort of obstacles would such a 'port' face? Just how many innocent undergrad students would need to be tortured for such a feat to occur? Disappointed with GCC, (albeit deleriously happy with GiNaC) Duraid
On Mon, 23 Jul 2001, Duraid Madina wrote:
Hi all,
Hi Duraid, nice meeting you again!
Please forgive my ignorance, but is there any chance GiNaC might move away from CLN and in its place use a "softer" library such as NTL? (http://www.shoup.net/ntl/) At least then we might have a chance of moving away from (or at least not kneeling before) Mark Mitchell and his GCC henchmen ;-)
What's so wrong about Mark and his henchmen? In my impression they are producing an excellent compiler. Both GiNaC and CLN should compile fine with GCC-3.0. (CLN-1.1.1 has compilation problems on non-x86 platforms with GCC-3.0, but I am working on these and plan to release 1.1.2 this week.) What is the exact problem? What alternative compiler are you having in mind? Note that CLN is ideally suited as a basis for computer algebra systems, mainly for three reasons: 1) Immediate types. An integer with absolute value smaller than 2^29 is immediate, not heap-allocated. Saves one indirection. 2) Honors the injection of integers into rationals automatically, many aspects are more algebraic than in any other comparable library. 3) Reference-counted memory management. This works seamlessly with GiNaC's memory management. Compare this with MuPAD, where the memory management occassionally clashes with that from the underlying PARI library or with Magma, which occassionaly blows up out of the blue sky because of interferences with some Kant remnants.
What sort of obstacles would such a 'port' face? Just how many innocent undergrad students would need to be tortured for such a feat to occur?
On the source-front only files numeric.h and numeric.cpp would have to be touched. But quite a number of functions would need to be implemented in GiNaC as opposed to delegating them to CLN. Hmm, I haven't gone through them and compared them with NTL's capabilities. Maybe one half or three undergrad students? Do you have some spare undergrads? ;-) There is of course also the packaging-front: NTL has no suitable packaging, in my opinion it badly needs to be libtoolized!
Disappointed with GCC, (albeit deleriously happy with GiNaC)
Oh, you shameless flatterer! Seriously, if making things work on another compiler is all you are concerned with, I can assure you that CLN is not so non-portable. Here is demo that it can be done with moderate effort: <http://www.ginac.de/lists/ginac-list/msg00028.html>. Be warned though: On non-GCC you must probably compile CLN with "-DNO_ASM -DNO_PROVIDE_REQUIRE", and build a static library only. By the way, all this nuisance is in order to prevent this: <http://www.awtechnologies.com/bytes/c++/faq-lite/ctors.html#[10.11]> from happening. Even then you can expect a fair number of compiler-sillinesses (no operator-> on iterators and bullshit of this sort) to happen. If you then still find CLN sillinesses I'ld definitely like to hear about them and see if they can be fixed. Cheers -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
What's so wrong about Mark and his henchmen? In my impression they are producing an excellent compiler.
You must be living in x86 land, then. We poor souls stuck with alpha and IA64 are not so lucky. (If you want to know what I mean, try searching for some combination of {stupid, insane, broken, disgusting, alpha, ia64} in the GCC mailing list archive ;-)
Both GiNaC and CLN should compile fine with GCC-3.0. (CLN-1.1.1 has compilation problems on non-x86 platforms with GCC-3.0, but I am working on these and plan to release 1.1.2 this week.)
Thanks for the heads-up :-) I'll see how I go with 1.1.2!
What is the exact problem? What alternative compiler are you having in mind?
The Intel C++ compiler, which rocks hard. It's turned into a hybrid of GCC and the KAI compiler, and it's just plain excellent, front-end and back!
Note that CLN is ideally suited as a basis for computer algebra systems, mainly for three reasons: 1) Immediate types. An integer with absolute value smaller than 2^29 is immediate, not heap-allocated. Saves one indirection.
Does NTL do this? I haven't looked. NTL feels a lot, lot faster than CLN, though this is just an awesomely subjective remark based on my experience with Not That Many programs I've written.
2) Honors the injection of integers into rationals automatically, many aspects are more algebraic than in any other comparable library.
This has to be pretty easy to wrap around. I'm talking 0.4 undergrads here. ;-)
3) Reference-counted memory management. This works seamlessly with GiNaC's memory management. Compare this with MuPAD, where the memory management occassionally clashes with that from the underlying PARI library or with Magma, which occassionaly blows up out of the blue sky because of interferences with some Kant remnants.
Hey, if memory management was ever a problem for me, I just threw the Boehm garbage collector at it, and hey presto, no more problem. ;-) I know, I know, I'm pretty damn lazy sometimes, but really, is anyone going to be using CLN in a life support machine? Hmmm.
What sort of obstacles would such a 'port' face? Just how many innocent undergrad students would need to be tortured for such a feat to occur?
On the source-front only files numeric.h and numeric.cpp would have to be touched. But quite a number of functions would need to be implemented in GiNaC as opposed to delegating them to CLN. Hmm, I haven't gone through them and compared them with NTL's capabilities. Maybe one half or three undergrad students? Do you have some spare undergrads? ;-)
I wish I did, the only one I can think of is my Significant Other and she's so busy with her thesis that I can therefore only donate 0.05 undergrads to GiNaC right now. There's a subject at our university 'Symbolic Computation', every student has to do some sort of 'project' to pass it. I might try talking to the lecturer...
There is of course also the packaging-front: NTL has no suitable packaging, in my opinion it badly needs to be libtoolized!
Hey! HEY! Are we _completely_ forgetting about the Win32 community? ;-) (Visual C++ 7 seems to be coming along half- (third-?) decently with regards to Compliance, it's funny how many MSVC 5/6 programs now break in 7 though.)
Oh, you shameless flatterer! Seriously, if making things work on another compiler is all you are concerned with, I can assure you that CLN is not so non-portable. Here is demo that it can be done with moderate effort: <http://www.ginac.de/lists/ginac-list/msg00028.html>.
Thank you! I will always maintain that CLN is a bit perverted, but I only praise NTL because it Builds Anywhere.
Be warned though: On non-GCC you must probably compile CLN with "-DNO_ASM -DNO_PROVIDE_REQUIRE", and build a static library only.
Thank you, thank you, I will be quiet now and see where I get with that!
If you then still find CLN sillinesses I'ld definitely like to hear about them and see if they can be fixed.
I can't remember the last time I ever built something without warnings disabled. (Please don't laugh/cry) So I can't promise too much, but if I have real problems, I may well come back jumping up and down!^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hsend you an email. Duraid
On Tue, 24 Jul 2001, Duraid Madina wrote: [...]
What is the exact problem? What alternative compiler are you having in mind?
The Intel C++ compiler, which rocks hard. It's turned into a hybrid of GCC and the KAI compiler, and it's just plain excellent, front-end and back!
The KAI compiler (now Intel) is definitely worth trying, as is SGI's compiler. Both are trying very hard to be standard conforming. Tell us if the static way works for you.
Note that CLN is ideally suited as a basis for computer algebra systems, mainly for three reasons: 1) Immediate types. An integer with absolute value smaller than 2^29 is immediate, not heap-allocated. Saves one indirection.
Does NTL do this? I haven't looked. NTL feels a lot, lot faster than CLN, though this is just an awesomely subjective remark based on my experience with Not That Many programs I've written.
I really do challange this statement. Dan Bernstein has made an effort and benchmarked some systems: <http://cr.yp.to/speed/mult.html>. This measures multiplication only, though, and it is quite old. For CLN-1.1 I have adjusted the break-even points for different algorithms anew and it should be about twice as fast now. NTL may also have gained in the meanwhile, of course. [...]
Hey! HEY! Are we _completely_ forgetting about the Win32 community? ;-) (Visual C++ 7 seems to be coming along half- (third-?) decently with regards to Compliance, it's funny how many MSVC 5/6 programs now break in 7 though.)
What is Win32? What is MSVC??? Regards -richy. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
On Tue, 24 Jul 2001, Duraid Madina wrote:
The Intel C++ compiler, which rocks hard. It's turned into a hybrid of GCC and the KAI compiler, and it's just plain excellent, front-end and back!
Err, I just gave the German distributor a call and this is what they claimed: KAI is a frontend-only compiler, it uses GCC or another C-compiler as backend. (?) Regards -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
Err, I just gave the German distributor a call and this is what they claimed: KAI is a frontend-only compiler, it uses GCC or another C-compiler as backend. (?)
Are you sure they're not talking about another KAI product, "Visual KAP". This is a preprocessor which automatically parallizes source code (and also performs some source-level optimizations even for serial codes) before passing it along to another compiler. It's not really a 'compiler' in and of itself, though. You'd require another compiler as a backend. (That product is about to be discontinued, by the way.) What seems to be happening (and is good news) is that the Intel compiler is slowly transforming from a "rebadged" EPC compiler (with Intel-tweaked) back-end to a KAI/EPC hybrid (with what appears to be a new back-end for IA64 (that or they did a LOT of work on an existing one) - the reason I spoke about "GCC front-end" is that the Intel compiler is doing a pretty decent job as a chameleon - on Windows, it acts just like Microsoft's Visual C++ and on Linux, it makes a pretty decent stab at acting like GCC. It's not enough to let you build a kernel, but it's pretty good! Duraid
On Wed, 25 Jul 2001, Duraid Madina wrote:
Err, I just gave the German distributor a call and this is what they claimed: KAI is a frontend-only compiler, it uses GCC or another C-compiler as backend. (?)
Are you sure they're not talking about another KAI product, "Visual KAP". This is a preprocessor which automatically parallizes source code (and also performs some source-level optimizations even for serial codes) before passing it along to another compiler. It's not really a 'compiler' in and of itself, though. You'd require another compiler as a backend. (That product is about to be discontinued, by the way.)
No, I wasn't talking about Visual KAP. This is from KAI C++ Compiler (KCC) Version 4.0f release notes which by the way lists (the triple-cursed) gcc-2.96-81 as a requirement: : The top level KAI C++ driver, KCC, is intended to be : used as a compiler. Under the top level driver there : are three distinct compilation phases. First, the front- : end parses the source file, performs high-level optimiza- : tions, and generates an intermediate file in standard C. : Next, a C compiler reads in the intermediate C file and : generates an object file. Last of all, a link process : combines the object modules and libraries, and takes care : of template instantiation and static object initialization. Err, am I supposed to be impressed by this? regards -richy. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
Talking about KAI's C++ compiler, I just tested it. It definitely is a frontend to the native compiler. Where else do all the notes in the local text sections `00000000 t gcc2_compiled.' come from? Other than that they did a pretty good job in standard conformance. There are two little issues in CLN, namely in the lines cln/src/float/misc/cl_F_leastneg.cc:44 cln/src/float/misc/cl_F_leastpos.cc:44 where you must manually change `&TheLfloat(erg)->data[0]' to `&erg->data[0]'. Dunno what's going wrong -- TheLfloat() is definitely defined at this point of translation. Then, static CLN indeed passed all the tests. This doesn't work for Debian, only for RedHat, because of this gcc-2.96 insanity. For GiNaC, I was less lucky. I don't understand enough about this compiler's template-resolution. I keep getting errors of this form: archive.o(.text+0xbe9): undefined reference to `void std::vector<T1, T2>::insert_aux(T2::pointer, const T1 &) [with T1=GiNaC::archive_node::property_info, T2=std::allocator<GiNaC::archive_node::property_info>]' The occurrence of `::insert_aux' hints at some problem in their library, since this is not declared in GiNaC or the standard. Duraid, does this ring a bell to you? How do you link your stuff with KAI C++? The very idea of having a C++ compiler produce C code for the system's native compiler appears as deeply anachronistic to me. There are some things that you'll *never* get correct with this approach and they will make life difficult. Consider inline functions which are just expanded at the appropiate place prior to feeding them to the native compiler. If something goes wrong at this point the native compiler will later be faced with unresolved mangled names and you'll see error messages of unbelievable verbosity. Like this one: /data/scratch/KCC/installation/KCC_BASE/include/vector:149: `__T146099832' undeclared (first use in this function) How do you debug this? How do you find the place where the error was triggered? I had to do binary searches over preprocessed source files. Ouuww, sucks... Bottom line: Real C++-compilers like g++ have definite advantages over `transpilers' like KCC. At least on x86 I see no performance gain from KAI's compiler. This is the third commercial C++ `Wunderwaffe' that flunked over here, but your mileage may vary. Bottom line of bottom line: Our efforts are better spent by helping to shake out the bugs of GCC-3. Regards -richy. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
On Tue, 31 Jul 2001, I wrote:
Talking about KAI's C++ compiler, I just tested it. [...]
Talking about Intel's Reference Compiler, I just tested the x86-edition, version 5.0beta for Linux on the CLN/GiNaC system. It detected a few minor glitches in the GiNaC code that went undetected by all GCC versions and by KAI and Portland Group. Those are being fixed in our CVS tree. The Intel compiler is really good w.r.t. ISO standard conformance. With the usual two preprocessor settings it compiled vanilla CLN-1.1.2 statically and passed all the checks. Then it came to GiNaC's timings and there the Intel compiler showed it is *not* doing a good job. Maybe if one tunes the whole system for Pentium-IV or such the picture will change. Maybe switching on Intel's global optimizations would help, too. I couldn't do that because the compiler chose to segfault every time I tried. :-( Without more ado, here are the timings in seconds (static, stripped binaries) on a P-III 800: commutative expansion and substitution (a.k.a. Denny Fliegner's test) size GCC 3 Intel-C++ 5 Ratio 50 0.08 0.11 1.38 100 0.35 0.50 1.42 200 1.57 2.19 1.39 Laurent series expansion of Gamma function order GCC 3 Intel-C++ 5 Ratio 15 0.27 0.38 1.41 20 1.219 1.74 1.42 25 4.879 6.73 1.38 determinant of univariate symbolic Vandermonde matrices dim GCC 3 Intel-C++ 5 Ratio 6x 6 0.006 0.010 1.67 8x 8 0.11 0.15 1.36 10x10 1.01 1.52 1.50 determinant of polyvariate symbolic Toeplitz matrices dim GCC 3 Intel-C++ 5 Ratio 6x 6 0.065 0.08 1.23 7x 7 0.30 0.39 1.30 8x 8 1.32 1.66 1.26 Lewis-Wester test A (divide factorials) GCC 3 Intel-C++ 5 Ratio 0.11 0.56 5.09 Lewis-Wester test B (sum of rational numbers) GCC 3 Intel-C++ 5 Ratio 0.010 0.026 2.60 Lewis-Wester test C (gcd of big integers) GCC 3 Intel-C++ 5 Ratio 0.149 0.71 4.76 Lewis-Wester test D (normalized sum of rational fcns) GCC 3 Intel-C++ 5 Ratio 0.309 0.72 2.32 Lewis-Wester test E (normalized sum of rational fcns) GCC 3 Intel-C++ 5 Ratio 0.25 0.43 1.72 Lewis-Wester test F (gcd of 2-var polys) GCC 3 Intel-C++ 5 Ratio 0.032 0.05 1.56 Lewis-Wester test G (gcd of 3-var polys) GCC 3 Intel-C++ 5 Ratio 1.08 2.39 2.21 Lewis-Wester test H (det of 80x80 Hilbert) GCC 3 Intel-C++ 5 Ratio 4.509 7.09 1.57 Lewis-Wester test I (invert rank 40 Hilbert) GCC 3 Intel-C++ 5 Ratio 1.30 1.98 1.52 Lewis-Wester test J (check rank 40 Hilbert) GCC 3 Intel-C++ 5 Ratio 0.74 1.07 1.45 Lewis-Wester test K (invert rank 70 Hilbert) GCC 3 Intel-C++ 5 Ratio 8.81 13.67 1.55 Lewis-Wester test L (check rank 70 Hilbert) GCC 3 Intel-C++ 5 Ratio 4.35 6.55 1.51 Lewis-Wester test M1 (26x26 sparse, det) GCC 3 Intel-C++ 5 Ratio 0.17 0.24 1.41 Lewis-Wester test N (poly at rational fcns) GCC 3 Intel-C++ 5 Ratio 483.47 512.52 1.06 Lewis-Wester test P (det of sparse rank 101) GCC 3 Intel-C++ 5 Ratio 0.59 0.73 1.24 Lewis-Wester test P' (det of less sparse rank 101) GCC 3 Intel-C++ 5 Ratio 2.76 4.03 1.46 computation of an antipode in Yukawa theory GCC 3 Intel-C++ 5 Ratio 59.78 75.21 1.25 One could argue that this result is restricted to x86 and the situation looks different on real RISC machines. However, after trying some simple template-heavy tests with Sun's WorkShop 5.0 for UltraSparc we realized that GCC-3.0 performs better on real C++ code, even on that platform. I hope this helps debunk the two myths that GCC does not perform well and that CLN/GiNaC is not portable. Happy heavy hacking -richy. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
participants (2)
-
Duraid Madina
-
Richard B. Kreckel