Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

groups.google.com

Post reply on HN
Print view View original

21–30 of 35 posts

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

#21

Post by pbiggar »

bretthoerner wrote: post #19
masklinn wrote: post #11

Earlier quoted context omitted.

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.

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

#22

Post by jedbrown »

pbiggar wrote: post #21
bretthoerner wrote: post #19

Earlier quoted context omitted.

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 gc…

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).

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

#23

Post by pbiggar »

jedbrown wrote: post #22
pbiggar wrote: post #21

Earlier quoted context omitted.

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 gc…

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).

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

#24

Post by jedbrown »

pbiggar wrote: post #23
jedbrown wrote: post #22

Earlier quoted context omitted.

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 fa…

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.

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

#25

Post by Q6T46nT668w6i3m »

pbiggar wrote: post #20
joubert wrote: post #10

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)

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 ab…

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-...

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

#26

Post by junkbit »

andrewf wrote: post #7

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."

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

#27

Post by pbiggar »

jedbrown wrote: post #24
pbiggar wrote: post #23

Earlier quoted context omitted.

> 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 fa…

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.…

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.

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

#28

Post by pbiggar »

Q6T46nT668w6i3m wrote: post #25
pbiggar wrote: post #20

Earlier quoted context omitted.

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 ab…

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/ne…

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).

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

#29

Post by jedbrown »

pbiggar wrote: post #27
jedbrown wrote: post #24

Earlier quoted context omitted.

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.…

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 (o…

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.)

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

#30

Post by pbiggar »

jedbrown wrote: post #29
pbiggar wrote: post #27

Earlier quoted context omitted.

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 (o…

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 an…

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.

Post reply on HN