Slashdot Mirror
Perl6 Being Rewritten in C++
jamiemccarthy writes "A rewrite of Perl in C++ is underway. The audacious plan, now called Topaz, will become Perl6 if and when it's successful. Its author, Chip Salzenberg, will
tell you all about it. " Wow. That's quite a project - you can also listen to Chip's talk given at the OpenSource Convention. For those you unaware, Chip is one of the Perl core developers.
And they're off! We already have some vague allusions to C++ being a bad idea, and the cross platform card has been played mighty early, implying that C is better than C++ for that. This is an exciting match, ladies and gentlemen, and we'll keep you updated as the race continues. We have yet to see any real material claims, be we expect plenty of personal anecdotes and opinions this match. It promises to be an exciting time, so stay tuned!
(
Sather is an interesting language, but the resultant portable C code is, according to the testimonials on the Sather pages themselves, only as fast as the equivalent code written in C++.
;-)
Object Orientation is a relatively new paradigm, and work is still being done in making OO code run faster - in general. It is the OO heirarchy that slows down C++ compared to C, it is what helps make Java slower even though the JVM is a relatively efficient interpreter/VM, and it is what "crippled" languages like Smalltalk and Eiffel in the eyes of "real" developers. However, the ease of design and maintainability of OO code has inspired a lot of research into trying to speed up OO languages so they can compete with their functional counterparts.
The advantage of Sather isn't speed (not yet, maybe someday), but, according to the authors, ease of maintainability. This, however, might be a reason to make the choice to use this language. As C++ is fairly broken in some places due to the ad-hoc OO/C integration, it can be very quirky to work with, and it's easy to write bad C++. I'd need to study Sather in detail to say it is actually more elegant and maintainable than C++, but I rarely doubt claims that something is more elegant than C++
Unfortunately, though, to port the Perl source to Sather one would first need to port the Sather compiler to Windows, as Berkely hasn't bothered doing so... and the Perl6 team will obviously need to support Perl on Windows as that's been in the core Perl for a bit of time now...
Creating a formal language base to bootstrap a framework into C through LISP is a great idea... but according to Larry Wall, PERL can not be formally specified in such a manner, and therefore I believe that this tactic would not work in this case, though I have not really studied the possibility in any great detail.
The suggestion of rewriting Perl in Python is a bit silly... why not rewrite Perl in Scheme, TCL or Java... or Perl? Talk about speed not being an advantage... While Python is pretty fast, Java with a good compiler (such as Jikes) and a good JVM (such as Java2 with HotSpot) is faster, at least on our tests on WindowsNT and Linux.
If raw speed at the expense of maintainability (and therefore the possibility of speed lost to bad programming rather than a "bad language") is one's goal, C is still the language to use (or assembler if you're both wed to one chipset and a total maniac). Otherwise, there are a lot of choices, including C++.
I think C++ was chosen because porting from C to C++ isn't that difficult to do (at least to do very badly), and can be done incrementally. I think the efficiency of Perl in C vs C++ will depend entirely on the programmers and how they use the language. As one person already pointed out, if they use C++ for some added maintainability but with an eye towards speed (that is, use the parts that don't slow the program to a crawl), they'll do just fine on the speed front...
o/~ we are pissed, we are pissed, we have to resist... o/~ - ec8or
"Macros are the reason to dump C for C++? "
Macros are evil. Each time you use a macro you are working around a language limitation. C++ has more language constructs than C so you can avoid macros more often. The nice thing about C++ is that the use of those language constructs is optional. I.e. if the use of a certain language construct in a certain spot of your program has a serious performance impact on your program the solution is simple: don't use it.
"Overall this will end up one of two ways: 1) it will fail because C++ is too slow or 2) it will succede because he uses C++ only for what advantages the syntax can provide him without being trapped into the glitzy (and mostly useless) constructs that make C++ about as speedy as my grandmother on a cold winter day."
I would go for number 2 and would like to add the prediction that if this thing is designed in a proper way, performance might actually be better than the old C version.
One of the arguments for reimplementing was that the current version is so complex that there are only a handfull of programmers who have enough knowledge to make non trivial changes to the code. A nicely designed C++ version of Perl could change this. An example of an increasingly successfull C++ implementation is Mozilla. It is fast, well designed and progressing really fast.
This discussion seems to be drifting in the "you can do anything in C" direction. While this is certainly true, it does not mean that C is the best solution for everything. Most perl users at least wouldn't dream of using C for the stuff they normally use perl for. Why?? perl is a better solution for their problem.
Likewise, C++ is a good language for large, complicated software. It's OO features allow for better structuring of the programs, and its C inheritance allows for performance optimizations should they be needed.
"Along those lines: I heard a good joke recently. A JIT compiler for Java that claimed to run code "just as fast as C++"! I laughed for minutes. Then I cried when I realized that this will likely work as an add campaign. Sigh."
You'll be crying a lot in the coming few years. Probably Java is not a good solution for implementing perl right now. But I wouldn't be surprised if it becomes an option in a few years. Perl is used mainly for server side processing of scripts. Good performance is essential there. Java has been coming quite nicely in this area and can be expected to improve even further the coming few years.
from the article: "I finally realized that Perl may be competing with Java in the problem space, but when you're writing Perl, implementing the Perl runtime, really what you're doing is something equivalent to writing a JVM. You're writing the equivalent of a Java Virtual Machine. Now, would you write a JVM in Eiffel? I don't think so. No, so neither would you write the Perl runtime in Java or in Eiffel"
While this may be true, implementing Perl in Java would mean that pearl benefits from all the optimizations in the Java vm (that would otherwise have to be implemented in the C++ version of perl). It would also mean that Perl would benefit from the portability of Java. One major advantage of a Java implementation would be that it would be far easier to maintain than a C or C++ implementation.
Jilles
I don't know where this idea that C++ generates slow exectuables came from. Bad programming create slow executables.
Early OO systems did a lot of runtime message passing, so they _were_ slow. C++, on the other hand implements a lot of the OO paradigm at compile time for more speed.
Virtual function DO add a table lookup each time they're called, but this would only have any effect during a tight loop. And you don't have to use them if you don't want them, but they do provide the benefit f reducing the need for type unsafe downcasting.
The other argument I've seen about C++ has to do with it somehow not being as "close to bare metal" as C. This impression comes from the fact that C++ does a lot of weird things like construct temporary objects to fit an object into an expression where it otherwise can't be used. Of course C does this too; if f takes a float and i is an int, then in the expression "f(i)", C constructs a float out of i for you. The difference is that C++ allows you to create bonafide first class types.
If you don't want temporary objects constructed, code around this problem. After all, in C++ you can always define both f(int) and f(float), but in the end it won't make any difference because most of the time you'll be doing the equivalent conversion in the function anyhow.
A lot of the hot opinion about C++ "inefficiency" reminds me of all my CS professors who used to say as an article of faith that "recursion is inefficient", and then go on to code elaborate ugly iterative algorithms to get around this. Well, one day I went home and ran a few algorithms through the profiler, and guess what? Most of the time there was no difference, and some of the time the recursive algorithm was a tad faster.
You can't trust your intuition about what is fast and what is slow. So, profile your code. If a virtual function or constructor for a temporary is taking a lot of time in a tight loop somewhere, optimize just that one piece by coding around the problem. Usually performance problems tend to be in a very tiny fraction of code.
I think that a lot of bad C++ comes from the fact that some programmers can't effectively use the extra flexibility that the language provides. They say if all you have is a hammer, every problem looks like a nail. If you have a hammer and a screwdriver, you're not in any better position unless you can tell the difference between a nail and a screw.
In the end, I personally prefer C, because I find it small and elegant. Look at how thin K&R is! C++, because it exposes so much language definition machinery to the programmer, will never be as elegant, but it is nonetheless in most respects very well thought out.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
We run Perl5 in development but have been working very diligently to get it approved for prod, which currently uses v4. In my travels writing Perl code for Fortune 500 companies, this is a much more serious impediment to acceptance than the majority of Perl users realize. My largest clients are commercial banks and brokerage houses, and you constantly find machines at these places running versions like 5.002 or earlier.
The normal reaction from a Perl user at an ISP or an academic institution is that the people running that system must be really dumb or must not use Perl. This is not the case.
Many consultants like me and the software development staffs we work with are not the people that decide which development tools are used. These decisions are made by people at the Chief Technology Officer level at many companies. They tend to spend most of their time evaluating Closed Source Software because this is the software that is promoted through the corporate IT news, sales, and marketing channels.
OTOH, software that is actually used, like Perl, is considered an ancillary part of the UNIX OS build that is installed on each Sun, HP, or IBM server. The geeks in the back room often have to resort to civil disobedience in order to get a new version of Perl approved and installed.
Sorry if this seems slightly off-topic. To tie it back to the discussion about Perl 6 I would have to say, with all the new features we would like to add, we in the community need to re-double our efforts at advocacy. We need to do a better job of identifying places where obsolete Perl versions are still installed, and figure out ways to remedy the situation.
-- Dave Aiello
Ok, a lot of people seem to really hate C++. I think part of this is because Linus rejected for the kernel. This makes sense, though. The kernel is very low-level and you want as much control as possible. C++ is a bigger language, and it does more stuff behind your back. C is very predictable, and thats why C is such a good systems language.
But for a big, non-nuts and bolts project like perl, C++ has a few important advantages.
1. OO. I think this is obvious. Of course you can do OO in C, and C++ doesn't garentee a good object model, etc. But it is less work, "cleaner", and requires fewer dodgey practices like macros to make things work. Additionally, there is far more tool support for doing OO in C++ as opposed to C.
2. Templates/generic programming. Now that there is a cross-platform compiler that does these relatively painlessly (ecgs/gcc3), Open Source C++ programmers should have no qualms about exploiting this feature, as they have in the past. What do templates give you that macros and typecasts don't? Well, first of all, type safe containers. That means you can't add a string to a list of ints. It won't even compile. Compare this to the best C containers, which can only catch it at run-time (with a performance hit). If type safe containers aren't enough, the C++ standard template library gives you iterators. To make a long story short, iterators allow you to write container independant algorithms. Your sort routine will run on a tree, a hash, a list, a vector, etc. Try doing that in C without enough casts and macros to sterilize a rat. And of course, the STL comes with nice implementations of most of the well-known algorithms you are likely to need.
3. Exceptions. Exceptions are simply a more elegant way to program, as any Java programmer will tell you. It nicely solves the ever-recurring problem, "How do I return both an error code and a result?". No more if (foo() == -1) return -1; everywhere and wondering if returning TRUE means success or failure.
In summary, C++ isn't for everyone or every project. But it has some nice features that make it nice for large projects.
After reading the article and the posts, I feel compelled to share my thoughts and experiences with both languages.
I've been a software engineer for 13 years. My first exposure to C came during a junior year course, Survey of Programming Languages, at ULowell, now UMass/Lowell. Once exposed, there was no going back. I was hooked. IMHO, it was so much better than Pascal. Once exposed, my Turbo Pascal went back to the bookshelf, never to be used again.
My initial exposure to C++ came during my senior year. I was enrolled in a compiler design course and the professor was a Modula-2 fanatic. Since half of the class were budding C gurus, he relented and allowed us to use "this new language", C++. We shelled out the $$$; he went to the Harvard Coop to buy copies Stroustrup's book.
I was impressed by the differences between C and C++. I particularly liked the organizational improvements that class definitions had over struct definitions. I found it a joy to code.
The project for the course was to build a Pascal-subset compiler. We couldn't use global variables and all functions, except for the tokenizer, had to fit on one page of hard copy printout. At the end of the course, he ran informal benchmarks for our compilers in terms of output size and compilation speed. My C++ compiler was the fastest and 3rd in efficiency!
Fast forward to the real world. After working for Omtool and Phoenix Technologies coding C and x86 assembler respectively, I worked as chief software engineer at Image Concepts. As chief software engineer, I was to design and develop their image cataloguing database product. To do so, I had the freedom to pick and choose the development tools and platforms for development. Since our product was slated to run on Unix/X11, Mac System 7 and Win3.x systems, I chose C. Again, portability, and the fact that Unix shipped with free compilers and Image Concepts was a very small company...
Once I started working at Pegasystems, after 6 years at Image Concepts, C++ became the language of choice, both for day job and night coding. Why? Code organization. Even though I wrote my C code in a C++ style, first argument to functions written for a particular struct was a pointer to a variable of that struct, C++'s constructors, destructors and exceptions made error management much, much better.
Typical C function (pseudo-code):
open file
if error: return
alloc memory
if null: close file and return
read from database
if error: free memory, close file and return
do something else
if error: yada, yada, yada...
C++:
open file object
if error: return
init buffer object
if error: return (file object destructor closes file)
read using database object:
if error: return (buffer object frees memory, file closed)
-or-
throw exception on error, which will also call destructors
You get the idea. When using C, I spent more time writing error management code than writing the algorithm. Worse, the algorithm was hidden amongst the error checking and management code. In C++, I build my libraries of well-designed classes and exceptions and, wow, you can actually see the logic. What a concept!
C++ isn't perfect, particularly some implementations. However, now that the language has been standardized, it should become more portable.
Languages are tools. We use them to design apps. We use the compilers to build the apps. Some are better than others in some areas. Each has a place. I use C++ for systems programming. I use Perl for CGI programming. For pattern parsing and portable scripting, Perl gets the nod. For outright speed, C++ gets the nod.
Is C better than C++? Vice versa? Is Java better? Is C++ purely OO? Does it really matter? Just pick a language, write the app, and distribute your work and add some value to the computing community at large. 'Nuff said.
One caveat to note regarding C++: templates and shared libraries are a bitch to implement well, that is, if you don't want multiple copies of stack scattered throughout your libraries. Both Visual C++ and Metrowerks CodeWarrior had ways of working around this, to have stack in one library and have other libraries link back to the first one, but the syntax each used were extensions off of standard C++. I don't how G++ will handle this.
Might I inquire what would give one such an impression? C is covered by ANSI standards, and so is C++ (not to mention, yay! ISO!), which means just about any compiler worth anything can compile perfectly ANSI compliant C or C++ code. Both are just about the epitome of portability (unless you count Java.. but you know, I don't feel like it), which aside from their being quite powerful languages, is what makes them languages of choice. C being a subset of C++, etc.. I'm not sure what would cause one to think of C++ as "less stable". Perhaps I'm not understanding the question? After all, it is rather early..
And since C++ is object oriented, it's a lot more.. useful.. in most situations than C. C still has its uses where C++ would be considered blatant overkill, but for anything that's going to be complex enough and is going to need to evolve a lot, C++ is the better alternative.
~ Kish
Well, so what the article says is basically this: "over long time we have done a shitload of
adhoc programming without order or system. Now
we look at it and we are scared. So we will just
drop everything we'v done and rewrite this whole
thing in some other language. We hope that objective nature of C++ will solve the problems
we as programmers cannot resolve (such as writing
a good structural code)."
Well, it won't... It will be slow as hell, Perl
not being a jetrocket now will be worse then your
java in Netscape on a 486:) And if they can't
keep their code neat - no OO language is going
to save them...
Sad..very sad.. they are smart people but that
doesn't necessarily gives discipline.
From the article:
Why not use C? Certainly C does have a lot to recommend it. The necessity of using all those weird macros for namespace manipulation, which I'd rather just use the namespace operator for, and the proliferation of macros are all disadvantages. Stroustrup makes the persuasive argument that every time you can eliminate a macro and replace it with an inline function or a const declaration or something or that sort, you are benefiting yourself because the preprocessor is so uncontrolled and all of the information from it is lost when you get to the debugger. So I'd prefer to use C++ for that reason.
Macros are the reason to dump C for C++? Woah, I got off of perl5-porters way too soon. Not to start a language war or anything, but this article read like a C++ lovers manifesto, not a reasonable set of excuses to use the language to re-impliment one of the most powerful and stable interpreted languages ever.
If you want a clean object model, just look at GTk+. If you want to eliminate macros just use inlines. Most people have a hard time with the idea of building inlines in header-files, and I don't blame them, but that's how you're going to end up doing it in C++.... And, don't try that "inline isn't in most C compilers" because most OSes don't ship with a C++ compiler. If you say that you can just buy one or get GCC, then the one you buy will almost certainly also be a C compiler that handles inline, and gcc supports inline (or __inline__ if you have -ansi turned on).
OTOH, macros are a good thing. Yep, I said what you thought I said. When a macro performs only a simple syntactic transformation, that's fine. I've never once been caught by such a thing. When a macro is a few lines of code, you've failed to correctly design your program, and I've lived in debugger-hell for that one. I can certainly see the value of consts over macros for variables, but that's not even something that's hard in C.
Overall this will end up one of two ways: 1) it will fail because C++ is too slow or 2) it will succede because he uses C++ only for what advantages the syntax can provide him without being trapped into the glitzy (and mostly useless) constructs that make C++ about as speedy as my grandmother on a cold winter day.
Along those lines: I heard a good joke recently. A JIT compiler for Java that claimed to run code "just as fast as C++"! I laughed for minutes. Then I cried when I realized that this will likely work as an add campaign. Sigh.
Why doesn't someone bootstrap a perl compiler written in perl? This is usually the way it is done?
- There not being a normative standard.
- There not being a good free compiler.
- Interoperability of LIBC++ versions has not been real good.
What this adds up to is that C++ on Linux has had some fairly severe handicaps. Several are no longer in effect; we'll see if this allows C++ to "get up and walk."That became untrue a year or so ago, when the ANSI C++ committee released the "final" standard.
G++ only fairly recently has started to be both "reliable," "correct," and "nearly completely conformant to standard."
The gyrations between GCC and EGCS, which has recently become GCC, did not help.
The claim is that there shouldn't need to be Yet Another Noninteroperable Version of the GCC libc++ library; I'm inclined to wait six months and see...
(My personal suspicion is that there may continue to be some LIBC++ gyrations for a while...)
If you're not part of the solution, you're part of the precipitate.
I believe difficulty in code maintenance with languages such as C was one of the primary reasons for the spawning of object oriented programming languages (complex and sometimes unwieldly though they may be to many), such as C++.
~ Kish
If you use features such as polymorphism or RTTI, of course you get a performance hit, but if you try to implement the same things in C manually, you won't get any better results.
Slowness of the program comes from sloppy programming, it has nothing to do with the language.
Something that's been rumbling in my head for a little while. Where do we draw the line between real C++ and pseudo-C++?
:)
For instance, if I write something using MFC (CMapStringToPtr or the less disgusing CMap template) then, well, it isn't real C++ is it? I won't be able to compile it anywhere else. I'll be stuck with that god awful library.
So you start using STL, beacause it's ANSI'd and open and designed by adults who knew what they are doing. You go looking for (and find) a convenient map template and in the process notice templates for near as dammit everything else! Strings, memory allocation, streams, the whole enchelada.
So, to be *real* C++, should I only be using the stl library, doing #include "string" and only stretching as far as #include "cstdio" when I feel a nasty hack urge coming on? Can I say goodbye to the happy days of getting a char* to the first byte and bouncing along the string until it dereferences to zero? Do I, in short, have to clean my act up?
And to what extent do other major C++ projects do this, especially given the relative newness (in terms of C++ standardisation) of the STL?
Dave
(offtopic note) MFC is horrible. Immense kudos to the ATL team for a fine piece of work.
I know they should be angle brackets, couldn't remember the HTML to make the browser not think they were tags. At least I previewed.
I write a blog now, you should be afraid.
I've ported perl to a new OS and I've written my own modules, so I feel I have a relatively valid viewpoint on perl's internals.
Basically, the internal datastructures are hoary. They're awful to dig through, and even worse to try and modify. Even writing external modules for use in perl can be horribly nasty because of the structures involved, the reference counting, etc.
I'd say at this point there are about 10-20 people (at most) who are competent to go and change the guts of perl. That's not a large number, especially when they don't have all that many tuits.
One of the prime motivations of rewriting perl in C++ is so that things will be modularized so that the knowledge barrier is greatly reduced. Right now, you need to know how _everything_ works before you can modify _anything_.
I'll be quite glad to get rid of things like
return sv_2mortal(newSVpv(ret,len));, thank you very much.
How about, say, Sather? A clean, fast, free (libre and gratis), object-oriented, garbage-collected language, which (and this is the beauty) compiles into portable C, so you can bootstrap Perl without first bootstrapping Sather. You only need Sather if you want to tweak Perl.
If that's too much effort, then you've basically already made the decision that only C or C++ will do since that's the compiler that machines will already have, so there's not much point in talking about other languages you might have used were it not for that condition. But I think it would be a mistake for free software projects to mandate that only these languages will do - it's not a restriction that proprietary, binary-only releases labour under.
--
Xenu loves you!