OSDev.org

Why doesn't someone just make a compiler for these high level languages? It's obscene to a 10,000 line interpreted Perl script. If the Perl langauge lets you do stuff easier than C, fine. But just compile the damn code. Is that asking too much?


(and don't mention perlcc because it sucks horribly)

Well, I think the issue is that some language constructs are very hard or inefficient to compile. It sure is possible, but the compilers would be massive if you also tried to do optimizations. That's probably why perlcc isn't so good.

It's actually oddly similar to the issues with the high level regexps used in Perl. Because of a couple of features in Perl regexps, they are thousands of times slower and asymptotically terrible in comparison to regexps used in the UNIX utilities.

The point is that these languages include features that are really hard and inefficient to compile, because the designers don't intend for them to be fast or compiled. This means the languages can be much more expressive, at a very large inherent speed cost.

Although, it's surprising that Lisp, a language that has as many if not more high level features than Python, can be compiled and run with only about double the overhead of C. Maybe that's due to the functional language restrictions?

Ah, where to start... I guess the beginning is best?

NickJohnson wrote:I'm not talking about making another Python interpreter, and I'm not talking about premature optimizations either. I mean you could actually have a C library with functions that allow you to make things work like Python in *native C code*. The syntax would be odd, but it is undoubtedly possible.

I get what you're saying, I'm being snarky. But there's a reason for that, elaborated upon below. Also, remember that bold for later!

Here's an example of how I could implement slices in C. First off, you make a string structure with two elements. The first is an integer, and the other a pointer. The integer lists the length of the string (essentially making a Pascal-style string) and the pointer points to the string. If you want a slice, a function called slice() would pass back a string structure pointing to a section of the original, with a different length. You can then concatenate strings with a special version of strcat(). GC can be done with some special restrictions on pointers as well as threading. If C had a more flexible syntax, more like Lisp, you could make nearly anything work, and at a smaller speed price than a very high level language.

... and now you've destroyed all of the speed benefits you were talking about before. Also, you're adding a lot of memory overhead.

The whole optimization thing doesn't even really apply. If you match completely unoptimized C code to even horrendously optimized Python, also assuming the same algorithm, the C will always beat the Python. So if you could get C to look decent while doing high level stuff (which I'm not claiming is possible), why not use it?

Compare the two bold statements.

Also, it may beat it, but the issue is not pure speed. The issue is, is it fast enough? You're going to be hard-pressed to find a high level application which you need the .02ms speed increase that C gives you. And if you do, you can rapidly develop most of the app in Python itself, and then use the C FFI to get that necessary speed out of it.

The main reason why we aren't using C for more things is it's lack of really good, powerful libraries.

Agreed. Sort of. It's a lot of work to implement things. C is a bit too low level most of the time.

There's nothing magic about very high level languages - everything is equally powerful (although C also has pointers, which are a big plus). It's just the syntactic sugar that sets things apart.

You're sort of abusing 'syntactic sugar.' Usually syntactic sugar is certain syntax that's more convenient than another syntax. But you're using it to mean "entire libraries that people have put X hundred man years into."

What I really mean to say is that: A. it would be really cool to make C do much that Python can, and B. why waste so many clock cycles by restricting ourselves to languages that have such strict requirements if we can adapt something with more control? I don't mean to sound like a zealot: I just think it might be an interesting idea.

You're completely right. It's just that it's not possible.


Switch!

dude101 wrote:Why doesn't someone just make a compiler for these high level languages? It's obscene to a 10,000 line interpreted Perl script. If the Perl langauge lets you do stuff easier than C, fine. But just compile the damn code. Is that asking too much?

Many people do. Haskell is about as high level as you can possibly get, and ghc is an amazing compiler. The "problem" is that it's not worth the huge effort to make one of these compilers. It's not like compilation magically makes things faster.


And back!

NickJohnson wrote:The point is that these languages include features that are really hard and inefficient to compile, because the designers don't intend for them to be fast or compiled. This means the languages can be much more expressive, at a very large inherent speed cost.

Yeah. Ruby (my preferred interpreted language) is exactly like this. Matz is more of a visionary than an implementer. Only recently has Ruby gotten any kind of real speed improvements, and that's with the move to someone else's interpreter.

Although, it's surprising that Lisp, a language that has as many if not more high level features than Python, can be compiled and run with only about double the overhead of C. Maybe that's due to the functional language restrictions?

Lisp is not functional, it's mutliparadigm. Then again, "Lisp" is sort of a useless term. Scheme is functional, Common Lisp is not.

If engineers are intel and AMD are working hard to bring us faster and faster chips, we shouldn't crap on their work by making a i7 run at 486 speed by using interpreted code.

dude101 wrote:If engineers are intel and AMD are working hard to bring us faster and faster chips, we shouldn't crap on their work by making a i7 run at 486 speed by using interpreted code.

Nobody should do anything. I mean, hey, if you want to develop your next web site using CGI scripts, go right ahead. I'll be so much more productive than you, it won't even matter that your app runs in 10ms while mine runs in 75ms.

Okay, fine. I guess my only real argument is that we already have good optimizing C compilers, and you can use high level libraries to do what other languages do in C, so why not try. If you had good optimizing Python compilers, the C with libraries and compiled Python would probably run at similar speeds.

And what I mean by syntactic sugar really sort of is syntactic sugar - it is syntax that makes it less cumbersome to use high level constructs. For example, assuming I wrote the slice-manipulation library I proposed:

string = "hello, world\n"
slice = string[2:5]

and

pstring_t string = pstring_make("hello, world\n");
pstring_t slice = pstring_slice(string, 2, 5);

would be equivalent. But the syntax of the Python is a ton simpler and nicer.

Edit: Oh, and those statements you bolded are referring to different things. I said it is undoubtedly possible to make a library to do this stuff, but I said I wasn't warranting it will be syntactically pretty in C.

NickJohnson wrote:Okay, fine. I guess my only real argument is that we already have good optimizing C compilers, and you can use high level libraries to do what other languages do in C, so why not try. If you had good optimizing Python compilers, the C with libraries and compiled Python would probably run at similar speeds.

I'm not saying that anyone shouldn't try, either. I just don't think that it's easy, or a worthy problem. If you could manipulate strings in a way similar to Python's, Python would already be using that implementation. I'm sure they're not choosing to be slower.

And what I mean by syntactic sugar really sort of is syntactic sugar - it is syntax that makes it less cumbersome to use high level constructs. For example, assuming I wrote the slice-manipulation library I proposed:

string = "hello, world\n"
slice = string[2:5]

and

pstring_t string = pstring_make("hello, world\n");
pstring_t slice = pstring_slice(string, 2, 5);

would be equivalent. But the syntax of the Python is a ton simpler and nicer.

We'll have to agree to disagree. It's not important anyway.

Edit: Oh, and those statements you bolded are referring to different things. I said it is undoubtedly possible to make a library to do this stuff, but I said I wasn't warranting it will be syntactically pretty in C.

Ahh, my bad. Looks like I need to fix my own parser