Go compiler now committed to gcc mainline (to be gcc 4.6) | Hacker News Reader

Go compiler now committed to gcc mainline (to be gcc 4.6)

groups.google.com

81 pointsadulau32 comments

More information here: http://www.airs.com/blog/archives/448

"Release gccgo in gcc is going to introduce a difficulty for Go programmers who use it. The Go language continues to evolve, but gcc 4.6 will not. That means that people using gcc 4.6 will be using a language which will be increasingly out of date. I don’t think there is any way to avoid that problem at this stage. The language will become more stable over time."

Why bother with GCC when the medium to long term seems to favor the LLVM compiler infrastructure? (and yes, I know you can use GCC together with LLVM, but for example, in Apple's case, XCode 4 now favors LLVM+Clang instead of the LLVM+GCC setup of XCode 3)

There's more to compilers than desktop/server targets. Although LLVM now targets a number os architectures, it is nowhere near what GCC supports.

The long-term goal of the Go frontend is to be usable with both GCC and LLVM. GCC has excellent medium to long term prospects, too, you know.

In this particular case:

  - Go is created by google
  - Ian Lance Taylor, the author of gccgo, works for Google
  - Taylor has worked on gcc for more than a decade
  - Google uses gcc for all its infrastructure

I doubt they would object to an LLVM front-end, and I'm sure someone will create one in the future.

As to why Google doesn't use LLVM, the generated code is simply not as fast as GCC. Google (last I heard) employs about 30 compiler engineers to support gcc internally, so they're not about to switch over to a less mature platform, even though it shows great potential.

From Ars:

I was initially a bit surprised that Google chose not to use the Low-Level Virtual Machine (LLVM) compiler framework—it has a lot of LLVM expertise internally and is using it extensively for their awesome Python optimization effort. Pike says that LLVM was considered during the early stages of the Go project, but its compile-time performance was judged to be inadequate.

http://arstechnica.com/open-source/news/2009/11/go-new-open-...

Interesting. Google uses gcc for all its C++ code internally, and I would say that it has way more gcc expertise internally than LLVM. I heard some figures once that each extra percent of performance they get out of gcc is worth $1m dollars per product, for each of their 10 most important products. I think that's per year. (eg a 4% improvement in the speed of gcc-compiled code would save them $40m a year).

Anyone else has the problem that they need to log in with a Google account before being able to see posts on Google Groups? I even have this on the group I created, which I set to the most public settings.

Yes, I have noticed this. Although I am usually logged in to Google, it seems to want me to log in again, which I am much too lazy to do. So I just don't use Google Groups.

That seems to be if you're logged in an other Google service in the same browser/session: if I open a browser I only use for development (and not for personal stuff, so it's not logged into any Google service) such as Opera, I get the message. On the other hand if I open the link in my "usual" browser it asks me to log into Google Groups (if I'm not already logged into it)

If you're logged in to GMail in another tab, sign out and reload the Groups page.

Also, tack 'topics?gvc=2' onto the end of any Groups URL to get the nice tabular view (you can get there through clicks but this is quicker).

So why didn't java and python made it to gcc ?

Because java did make it and python doesn't compile to machine code (with the exception of using a jit compiler maybe)?

I suppose that we could retarget something like Jython to compile Python to native code?

Jython doesn't compile to JVM bytecode its just a Python interpreter/implementation written in Java that runs on the JVM.

I'm trying to work out at what level your question makes sense. I'm unaware of a GCC-based Python compiler, so surely there's nothing to merge there?

As for Java: http://gcc.gnu.org/java/ (this has been in for years)

There was a SoC project for a Python front-end to GCC this past summer. I don't know how far it got.

What's gcj? Oh, the Java compiler in gcc? Hmm.

As for why Python isn't in gcc... it's because nobody has sent a patch. There is no conspiracy here; Google wrote Go and sent the gcc folks a patch to add it to gcc. Simple.

Also, erm… Python is not compiled to native code, so a gcc plugin doesn't really make any sense.

Java normally isn't, either. You're discussing implementation details, not laws.

http://gcc.gnu.org/java/

Sort of. Scripting languages cross a bit of a line in that their implementation details leak out into the language. It simply isn't possible to statically compile Python (or PHP, Ruby, etc), and still cover the full breadth of the language. You need to handle dynamic code generation (for example eval()) which means you need an interpreter at run-time, which means you're no longer really statically compiling it.

In gcj, they added a java interpreter, and statically compile what they can. This works great when you have all the source code. It doesn't work great for things like Eclipse, where there are tons of dynamically loaded plugins which are then slow because they're interpreted.

Evidently you are not familiar with how many Lisp compilers work. You don't need an interpreter anywhere, just a compiler.

Note that eval(), as much as it makes sense in the C language, can be implemented in C too (inject the text into a stub, compile it into a shared library, dlopen(), dlsym(), call it).

    > Evidently you are not familiar with how many Lisp compilers work.

It would be better etiquette not to assume such things. A cursory google for my name (available from my HN profile I believe) would reveal that it's very very likely that I am familiar with how Lisp compilers work.

    > You don't need an interpreter anywhere, just a compiler.

In Lisp, sure. But Lisp is not Python. Lisp's eval is structured, making it far simpler to compile than Python(/PHP/Perl/Ruby/JavaScript)'s unstructured eval, which takes a string which is may be constructed at run-time. Even so, Python(/etc)'s semantics lazily look up imports, which means that an imported module may be changed at run-time.

The crux of the issue is that in Python the dynamicism is actually used by lots of modules and programs.

    > Note that eval(), as much as it makes sense in the C language, can be implemented in C too (inject the text into a stub, compile it into a shared library, dlopen(), dlsym(), call it).

C's dynamic loading has significantly less scope than that of Python or of Lisp. C loads already compiled code, meaning that the C implementation is not required to have a run-time compiler available (the user may decide to compile C code using a compiler already on the system, but that's for the user to implement, not for the C compiler writter).

Furthermore, almost none of the work of the compiler writer is affected by dynamic loading. Sure, it means they might not know all the entry points of some externally exported symbols, or they might not have a complete call-graph, or they might not be able to statically-infer all the run-time types or aliases of some static name. However, this limits the scope of optimization, it does not hamper implementation. And even then it rarely hampers local optimization, which the Python dynamic loading does (see my PhD chapter 6 for a discussion).

1. I was replying to your statement that eval() required an interpreter. My antagonism was mostly in jest since I vaguely remembered your name, but I also believe in discussions without arguments from authority.

2. Lisp can eval a string that has been constructed at runtime. That's kind of the point of a repl, for example, which can be implemented by compiling each unit of input to native code before executing it.

3. The Python community shuns the use of eval. Are you really claiming that Python's eval is used in fundamentally more dynamic ways than Lisp's? Or is it that Lisp's eval usually operates on input that is constructed differently? Or that Lispers tend not to put eval in an inner loop, but some important Python programs do? I understand that there are attributes of Python that make compilation hard compared to a Lisp, but I'm not aware of something that makes it impossible or guarantees that compilation cannot be performant. Maybe I need to read chapter 6 of your thesis.

1 (authority). Sure :)

1 (eval). eval() is different in Python and Lisp. I was talking about Python eval(), which requires an interpreter.

2. Lisp "strings" aren't really strings in the way they are in python, which is what I was trying to say by "structured".

3. They may shun eval, but they don't shun import, which is the same thing.

What I'm saying is that the techniques Lisp compilers use do not apply to Python (or at least, no-one has ever shown how they do apply). I don't know enough Lisp to be confident as to why that is, but I believe it's because they don't do such massively dynamic things at run-time (that is, they can, but don't). Or perhaps they do, in which case their programs can't really be statically compiled in a gcc-like manner, which brings us back to our original point.

2. How is a string read from the terminal fundamentally different in Lisp than in Python? How is

  (eval (read-from-string "(anything here)"))

different from Python's

  eval('anything(here)')

? Just because it's possible to build the arguments of eval without using strings in Lisp does not mean that they are somehow less arbitrary.

3. I don't see how Python's import is different, the SBCL runtime, for example, locates and reads the source file when you import it, compiles it to native code (if a cached copy is not available), and runs it.

4. I missed the (apparently) implicit "that easily fits into GCC's present compilation model" in your earlier comment. I'm have no arguments with that statement, and indeed, I don't think GCC would be a good place to work on static compilation for Python. Rather, my argument is with a claim (intended or not) that Python is just too dynamic to ever be compiled, for which I think Lisp compilers are a living counter-example. From the sbcl man page:

  SBCL  compiles  by  default:  even  functions entered in the read-eval-print
  loop are compiled to native code, unless the evaluator has been explicitly 
  turned on. (Even today, some 30 years after the MacLisp compiler, people
  will tell you that  Lisp  is  an  interpreted  language.  Ignore them.)

We are not discussing the difference between Python and Lisp (that is merely a short detour into something I know little about).

The argument is whether we can compile Python with gcc. We cannot, because of eval(). Can Lisp compile eval()? Yes, for a different value of 'compile' and a different value of 'eval'. You argue that the values of 'eval' are the same in Lisp and Python - I honestly don't have enough knowledge to evaluate that. All I know is that if they are, then Lisp compilers are not static compilers, in which case the argument has no bearing on the discussion about python and gcc.

You have implied that you can statically compile python eval()-statements, but you have not backed that up.

Perhaps we disagree about the term "static compilation". SBCL and other lisp compilers read a source file and produce native code which is then executed. If certain dynamic features are not executed, then the compiler (also part of the runtime in much the same way as libc is part of a C executable) is not invoked at runtime. If dynamic features are needed, then the expression is eval'ed by compiling it to native code and executing it. This is lighter and more powerful (for language reasons) than spawning a process to invoke a C compiler that produces a shared library which is dlopen'd on the spot, but I claim it is a closer analogy to what is happening than a JIT.

In summary, I submit that (i) Python eval is no more dynamic than Lisp eval and (ii) it is acceptable to use the term "statically compiled" even if the standard library includes "compile".

How about this:

(i) to compile python into an executable, you must include the entire compiler in the run-time (ii) this is inappropriate for gcc

I agree completely. :-)

> You don't need an interpreter anywhere, just a compiler.

This is one of those claims that is technically true, but is misleading. Really, there isn't an interpreter/compiler dichotomy, they are just variations on a theme. Or, standard definitions of them are variations on a theme, but often the line between them is very blurred (especially when just-in-time compilers come into it).

People typically consider 'compiler' to mean 'static compiler'. It generates native code into an executable, and then the 'program' is the executable. Lisp compilers are clearly very different to this, but GCC falls clean into it.

So it's wrong of you to allege that "you don't need an interpreter". You need a run-time component. Sure, this can be a compiler, rather than an interpreter, but its wrong to imply that you can support eval() simply with a static compiler such as gcc.

Reply on news.ycombinator.com