What's the point in compiling to the metal?

[Bienlein]

Hello,

my question may seem odd at first sight. But I think it is a valid one, because VMs meanwhile offer very good performance and portability anyway. Is generating machine code in Go a deliberate decision to get as much performance as possible or is it maybe simply a side-effect, because that's what the Plan 9 compiler puts out anyway?

Regards, Bienlein

[Rob Pike]

If the metal's there, why not use it? The JVM compiles to the metal,
but omitting the middle man is cheaper and faster. For example, a Go
instance starts up dramatically quicker than a Java instance.

Another way to think of it: not using the JVM is an example of
compile-time optimization.

Another way to think of it: Why is the JVM not written in Java?

Another way to think of it: The JVM does not provide unsigned
arithmetic or Go's type system. Interface dispatch would have to be
simulated, slowly; Scala has the same problem (and it's slow to use
this feature).

Another way to think of it: http://talks.golang.org/2012/splash.article

-rob

[Eric Palmer]

Also one less dependency to deal with. I'm drawn to golang because of the 1 executable file only is needed concept. I'm writing for the cloud and the easier it is to deploy or update an executable the better it is.

Eric

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
KK4MWM (Ham Radio)
About Me
http://www.thingiverse.com/DaddyOh
Join the 3DPrinter Revolution
http://makerbot.com

[steve wang]

Were Go vm-based, it would lose its shine, at least to me.

And not every one would like to have a huge and slow vm interpreter installed on his box. 

[minux]

On Tue, May 21, 2013 at 11:34 PM, Bienlein <jet...@web.de> wrote:

my question may seem odd at first sight. But I think it is a valid one, because VMs meanwhile offer very good performance and portability

yeah, good portability and good performance, choose either one.

[Jon Renner]

I just compiled one of my programs for linux/arm and ran it on my raspberry pi. The RPi comes with python, so i could have written it in python, but java would have been a hassle.

[André Moraes]

On Tue, May 21, 2013 at 1:23 PM, minux <minu...@gmail.com> wrote:
>
> On Tue, May 21, 2013 at 11:34 PM, Bienlein <jet...@web.de> wrote:
>>
>> my question may seem odd at first sight. But I think it is a valid one,
>> because VMs meanwhile offer very good performance and portability

I think Go proves that you can have both. :)
--
André Moraes
http://amoraes.info

[André Moraes]

>
> On Tue, May 21, 2013 at 11:34 PM, Bienlein <jet...@web.de> wrote:
>>
>> my question may seem odd at first sight. But I think it is a valid one,
>> because VMs meanwhile offer very good performance and portability
>
> yeah, good portability and good performance, choose either one.

[Paulo Pinto]

On 21 Mai, 18:07, Rob Pike <r...@golang.org> wrote:
> If the metal's there, why not use it? The JVM compiles to the metal,
> but omitting the middle man is cheaper and faster. For example, a Go
> instance starts up dramatically quicker than a Java instance.
>
> Another way to think of it: not using the JVM is an example of
> compile-time optimization.
>
> Another way to think of it: Why is the JVM not written in Java?

The default JVM from Oracle you mean, as there are others written in
Java actually and even
Hotspot is planned to get replaced by a Java version post Java 8
(project Graal).

[Paulo Pinto]

On 21 Mai, 18:31, Jon Renner <renne...@gmail.com> wrote:
> I just compiled one of my programs for linux/arm and ran it on my raspberry pi.  The RPi comes with python, so i could have written it in python, but java would have been a hassle.

Why? http://www.oracle.com/technetwork/java/embedded/resources/me-embeddocs/index.html

I would also use Go instead of Java, mind you.

[Ziad Hatahet]

On Tue, May 21, 2013 at 10:18 AM, Paulo Pinto <paulo....@gmail.com> wrote:

The default JVM from Oracle you mean, as there are others written in

Java actually and even
Hotspot is planned to get replaced by a Java version post Java 8
(project Graal).

Interesting.

Furthermore, the original question was asking about VMs in general, not the JVM -- which does have some warts. The .NET VM for instance, does support unsigned types.

--
Ziad

[quarnster]

Personally I've yet to find a compelling reason to use a VM in the first place. Good old C is by far much more portable than any other language I've stumbled upon, but then I work on a variety of odd embedded CPUs for which no VM has been ported and even if it was the required memory needed to run them just doesn't exist. People like to beat the "portability" drum and then appear to forget that there's a huge runtime to support running that "portable" program that not only needs to be ported to any new platforms, but it must also be installed on any system that wants to be able to run the application.

Thank you brains behind Go for not making it VM based and for statically linking in the runtime.

/f

[Paulo Pinto]

I agree with you, even if my previous answers might seem otherwise.

There are many scenarios where VM are better and also others where
native compilation
is preferable.

Personally since languages and implementations are different things,
although one
can influence the other, I prefer the approach taken by functional
programming environments.

A VM with REPL for development time, with compilation to native code
when deploying the
application.

[Michael Jones]

Because programming a real computer instead of a software pretend computer is more efficient and allows more optimization by targeting (by hand or compiler) the actual features of the machine. It is also, by very loose analogy, more satisfying in the same way that kissing my wife is more interesting than kissing a picture of my wife.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[Ziad Hatahet]

On Tue, May 21, 2013 at 1:08 PM, Michael Jones <m...@google.com> wrote:

Because programming a real computer instead of a software pretend computer is more efficient and allows more optimization by targeting (by hand or compiler) the actual features of the machine. It is also, by very loose analogy, more satisfying in the same way that kissing my wife is more interesting than kissing a picture of my wife.

Not that I am in favor of VM-based languages in general, but isn't one of the proclaimed benefits of using a VM + JIT is that this allows certain optimizations that are just not possible using a to-native compiler? Things like inlining virtual method calls, removing branching conditions that are never taken, and having a global view of the program at runtime. Does LLVM help in any of these cases? I am not really a compiler person.

I agree though that it is very convenient to be able to just deploy a single binary and be done, without having to worry about dependency issues.

--
Ziad

 

[minux]

On Wed, May 22, 2013 at 4:57 AM, Ziad Hatahet <hat...@gmail.com> wrote:

On Tue, May 21, 2013 at 1:08 PM, Michael Jones <m...@google.com> wrote:

Because programming a real computer instead of a software pretend computer is more efficient and allows more optimization by targeting (by hand or compiler) the actual features of the machine. It is also, by very loose analogy, more satisfying in the same way that kissing my wife is more interesting than kissing a picture of my wife.

Not that I am in favor of VM-based languages in general, but isn't one of the proclaimed benefits of using a VM + JIT is that this allows certain optimizations that are just not possible using a to-native compiler? Things like inlining virtual method calls, removing branching

in theory, right. but the sad truth is that state of the art AOT compilers can still produce better

code than JIT compilers, unless you're satisfied by theoretic performance, the best performer

is AOT compilation.

for example, you need to take the analysis overhead into account for JIT, so JIT compilers typically

won't use the best algorithm available for one task, and all these small parts will add together to

make a big difference.

conditions that are never taken, and having a global view of the program at runtime. Does LLVM help in any of these cases? I am not really a compiler person.

yes, LLVM does have facility for all these.

and there is a llvm based Go toolchain in active development: github.com/axw/llgo

[Ian Lance Taylor]

On Tue, May 21, 2013 at 2:29 PM, minux <minu...@gmail.com> wrote:

> yes, LLVM does have facility for all these.
> and there is a llvm based Go toolchain in active development:
> github.com/axw/llgo

And as a long-time GCC developer let me assure you that GCC also
implements all of those optimizations. (GCC still beats LLVM on most
run-time benchmarks.)

Ian

[Sod Almighty]

Sheesh, what a dumb question! Coding for a VM requires that the VM be installed on the machine. Simple as that. VM-advocates prate on about "portability" and such, but they're talking crap. How is something "portable" if it needs runtimes? Portability is the ability to put the .exe on a goddamn flash drive, whack it in and hit "run". Anything else is just bullshit.

I'm primarily a VB.NET developer, so I know of what I speak, and s the most annoying thing about .NET is the inability to compile it to native code. M$ like to claim platform independence, but that's just utter nonsense. Name one platform that a .NET app will run on, besides Windows. And no, Mono doesn't count, because it hasn't advanced since .NET2.0, and is therefore as much use as a sugar umbrella.

[Sod Almighty]

I have a question, however. Why did this forum add a link to something completely different when I wrote "VB.NET"? Goddamn adverts, they get everywhere. Isn't it bad enough that they're all over everyone's screens every minute of the day, without putting them in my mouth as well?

[André Moraes]

I just read you message on my mail client, no extra link is set.

But since vb.net ends with .net and .net is a valid domain suffix, the
google groups server probably tried to make sense of that and pointed
to the host at "vb.net"

[Matt Silverlock]

> Sheesh, what a dumb question! Coding for a VM requires that the VM be installed on the machine. Simple as that. VM-advocates prate on about "portability" and such, but they're talking crap. How is something "portable" if it needs runtimes? Portability is the ability to put the .exe on a goddamn flash drive, whack it in and hit "run". Anything else is just bullshit.

A naive question maybe, but not an outright "dumb" one (and you wondered why people see you as abrasive). Also note that the "VB.NET" thing is not an ad, but more-so just some overly aggressive parsing for URLs. The same thing happens if I write ASP.NET

As for the topic: one of the great things about Go is how easy it is to cross-compile; alongside the fairly wide variety of systems supported natively. Knowing I can dev on OS X for the web (a Linux box) and automation (RPi) is fantastic. Perhaps not as "simple" as Java, but I'd daresay it's pretty close.

[Ugorji Nwoke]

I don't even think the question is naive. It's a very fair question. In theory, there's a fair amount of optimizations that are available to VM's because they can optimize based on runtime heuristics, hot-spots, etc. Minux alluded specifically to it. Static compilation may skip these for diff reasons (code bloat, etc) but they may make sense at runtime. The JVM does a fair amount of this (I was a tech specialist in the field for JRockit JVM while at BEA/Oracle). 

[Lucio]

OK, let me put the cat amongst the pigeons here, seeing that no-one else did.

Go's most immediate predecessor (in my opinion, of course) is Limbo see <vitanuova.com>, which is still supported by a VM, one that has been ported to many more platforms than the JVM and that, again in my opinion, has been designed with a lot more TLC than the JVM (Charles, where is the document that compares Limbo to Java?).  That said, there are too many different ports of the Limbo VM to be comfortable and Go is so much more easily cross-compiled than any other compiled language I know.

Lastly, I like to think that the Go tool chain ought to be extended, rather than rely as we do now on CGO to produce Go executables for otherwise unsupported platforms.  There are MIPS, PowerPC, Motorola 68000 (eek!), Alpha and other compilers, assemblers. linkers and emulators in the Plan 9 tool chain (even the AVR has a somewhat less official C compiler, if you look for it) that are begging to be ported to the Go toolchain, if only to benefit from the cross-platform developmnet made available by the Go build tools.

Sadly, the Go runtime is quite a complex beast - it could be worse, it could be a VM - and recently complications arose because of the need to qualify the platform as OS/Arch/{list of features} - I myself got bitten by the GO386=387 issue not more than an hour ago - so we're not yet in the perfect world of Go, but we're at least out of the woods as far as precedent Dark Ages are concerned.

Lucio (these are all my own opinions, no one is asked to entertain them).

[Paulo Pinto]

Singularity, Netduino and around .NET 2.0 there was a port for
Symbian.

On Windows Phone 8, .NET is compiled to native code:

http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and-Peter-Sollich-Inside-Compiler-in-the-Cloud-and-MDIL

But spend some time informing yourself?

[Bienlein]

I don't even think the question is naive. It's a very fair question.

Thank you, fair enough ;-).

Not that I am in favor of VM-based languages in general, but isn't one of the proclaimed benefits of using a VM + JIT is that this allows certain optimizations that are just not possible using a to-native compiler? Things like inlining virtual method calls, removing branching conditions that are never taken, and having a global view of the program at runtime.

Inlining virtual method calls is a good point. Alas, there aren't any in C or Go. So it seems the more dynamic a language the more it can profit from runtime optimization. It is quite remarkable that Dart is doing better in this sudoku test than Lua + JIT. Coming to speak of Lua: Lua exists for almost every platform (as long as some ISO C compiler exists) for it. It doesn't like like this were also the plan for Go. Go is for network programming, server administration, etc, not for embedded stuff.

Removing branching conditions that are never taken is a good point as well. But my knowledge about compiler construction is too limited to estimate whether C or Go would benefit here from runtime optimzations.

By the way a runtime and a vm is not the same thing. For instance Objective-C has a runtime, which does the dynamic message dispatch and includes the GC. It is not a vm, though, as it does not mimic the machine.

A VM with REPL for development time, with compilation to native code when deploying the application.

I never really understood the point of those REPLs. What you can do with them is so limited ... Incremental compilation in the eclipse Scala plugin is so slow (even slower than compiling the whole application with the IDEA Scala plugin) that I sometimes use the REPL. If compilation is quick as in Go I see no real reason for it.

-- Bienlein

[Paulo Pinto]

On 22 Mai, 10:38, Bienlein <jeti...@web.de> wrote:
>
> A VM with REPL for development time, with compilation to native code when
>
> > deploying the application.
>
> I never really understood the point of those REPLs. What you can do with
> them is so limited ... Incremental compilation in the eclipse Scala plugin
> is so slow (even slower than compiling the whole application with the IDEA
> Scala plugin) that I sometimes use the REPL. If compilation is quick as in
> Go I see no real reason for it.
>
> -- Bienlein

Do you have experience with Smalltalk or the original Lisp
environments?

Don't judge a REPL by what Scala offers.

[Thomas Bushnell, BSG]

The JVM was not created because it was an awesome way to implement a language.

it was chosen specifically because Java was intended to be used as a web language, in which browsers would run untrusted JVM bytecodes. So compiling to bare metal was not feasible. This is why the JVM has all the silly restrictions it does; they are an attempt to make it safer to run untrusted programs.

In that context, the JVM is a decent decision to have made. It's absurd that it still gets used for cases where it completely doesn't apply.

--

[Michael Jones]

I have Smalltalk experience in its recent Croquet instantiation as Squeak. This clever system hijacks the method dispatch core of Smalltalk to create a multi-machine distributed, time-synchronized computation environment. It allows arbitrary numbers of users to share a collaborative world where computations scale with the number of participants. Genius.

http://en.wikipedia.org/wiki/Croquet_Project

David Smith, Alan Kay, and David Reed are buddies...

[Bienlein]

Do you have experience with Smalltalk or the original Lisp environments?

Yep, and asking for a REPL in Smalltalk makes no sense as a so-called Smalltalk image is something like a binary dump of the current state of some large REPL. It gets restored when you start your Smalltalk system and you continue development where you left it when you shut down your Smalltalk system. This allows for interactive development which cannot be done with a REPL. AFAIK only Smalltalk though the concept of an image allows for interactive development.

-- Bienlein

[Job van der Zwan]

On Wednesday, 22 May 2013 15:57:12 UTC+2, Thomas Bushnell, BSG wrote:

The JVM was not created because it was an awesome way to implement a language.

it was chosen specifically because Java was intended to be used as a web language, in which browsers would run untrusted JVM bytecodes. So compiling to bare metal was not feasible. This is why the JVM has all the silly restrictions it does; they are an attempt to make it safer to run untrusted programs.

In that context, the JVM is a decent decision to have made. It's absurd that it still gets used for cases where it completely doesn't apply.

Since I still get popups asking if I want to run untrusted Java code whenever I start an applet, did it really solve that problem?

Also, I was wondering if there's an analogy to be made between the Go runtime and the Java VM, if you ignore the bytecode part for a second: both have a bit "meta-OS"-like roles, right?

[Niklas Schnelle]

Actually Go's interface calls can't be inlined by ahed of time compilation and would indeed be inlineable by a JIT.
Also note that as far as I know there is no technical reason Go can't be implemented on a VM for example for .NET the language specification doesn't enforce
ahead of time compilation or even static compilation. In fact the Go implementation for LLVM that is in active development will most likely be able to run with JIT compilation.
The primary reason that AOT still beats JIT in most cases is that the JIT can only spend so much time on optimization that it's amortized over a single run time, while
AOT can amortize over all runtimes of the produced binary. However there is nothing stopping you from doing a lot mor optimizations when you know your runtime is very long,
for example in a server environment. In fact Mono the open .NET implementation can use the full LLVM optimizations during JIT when using that as VM backend.
So the important thing to take away here is that it's not Go that doesn't use a VM but the reference implementation of Go.

[Paulo Pinto]

Yeah, there quite a few Java native compilers available from third
parties.

Once I read in some Java forum that the reason why Sun, now Oracle,
still don't offer
a native compiler as part of the standard JDK is pure political, given
that they even
have them for embedded targets.

--
Paulo

[Paulo Pinto]

Cool, thanks for sharing.

On 22 Mai, 16:19, Michael Jones <m...@google.com> wrote:
> I have Smalltalk experience in its recent Croquet instantiation as Squeak.
> This clever system hijacks the method dispatch core of Smalltalk to create
> a multi-machine distributed, time-synchronized computation environment. It
> allows arbitrary numbers of users to share a collaborative world where
> computations scale with the number of participants. Genius.
>
> http://en.wikipedia.org/wiki/Croquet_Project
>
> David Smith, Alan Kay, and David Reed are buddies...
>

> On Wed, May 22, 2013 at 11:57 PM, Thomas Bushnell, BSG <tbushn...@google.com

>
>
>
>
>
>
>
>
>
> > wrote:
> > The JVM was not created because it was an awesome way to implement a
> > language.
>
> > it was chosen specifically because Java was intended to be used as a web
> > language, in which browsers would run untrusted JVM bytecodes. So compiling
> > to bare metal was not feasible. This is why the JVM has all the silly
> > restrictions it does; they are an attempt to make it safer to run untrusted
> > programs.
>
> > In that context, the JVM is a decent decision to have made. It's absurd
> > that it still gets used for cases where it completely doesn't apply.
>

> >> For more options, visithttps://groups.google.com/groups/opt_out.

>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to golang-nuts...@googlegroups.com.

> > For more options, visithttps://groups.google.com/groups/opt_out.

[Paulo Pinto]

The original Lisp environments were also image based.

You can have the same workflow without images, just have the repl
integrated
into an editor, eg. Emacs, which allows you to evaluate whatever piece
of code you
have.

Or for that matter the LightTable editor. which also provides a nice
experience, although
not as good as Smalltalk and Lisp Machines.

--
Paulo

[Paulo Pinto]

All languages have runtimes, which you can consider to be a meta-OS.

Even Assembly has one in the processors that use micro-code to execute
the opcodes.

As for C, which some people think it does not have one, it is called
UNIX, and latter on got libc
as the language got standardized.

--
Paulo

[Michael Jones]

cough, _crt0.o, cough

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[John Nagle]

On 5/22/2013 8:47 AM, Paulo Pinto wrote:
> Even Assembly has one in the processors that use micro-code to execute
> the opcodes.

Not on any CPU that goes fast. Microcoded CPUs are rare today,
although some of the really obscure instructions may be microcoded.
Many machines in the 1970s and 1980s were microcoded. The whole
DEC line until the Alpha was microcoded. The Motorola 68xxx machines
were microcoded. But x86 machines were not, which is why the original
x86 instruction set was so small - they didn't have enough transistors
for more CPU functionality than that. The whole RISC thing was about
getting rid of microcode inside the CPU. That led to simple, one
instruction per clock CPUs like MIPS. Then came superscalar,
with more than one instruction per clock and incredible complexity
within the CPU. (Design team of midrange MIPS CPU: 13 people.
Design team of Intel Pentium Pro at peak: 3000 people.)

What's really going on inside a modern superscalar CPU looks more
like a JIT compiler in hardware. But this is the wrong group for
architecture discussions.

John Nagle

[Paulo Pinto]

Yeah, forgot that one. :)

> > For more options, visithttps://groups.google.com/groups/opt_out.

[Paulo Pinto]

Thanks for the explanation.

[Florian Weimer]

* Michael Jones:

> Because programming a real computer instead of a software pretend
> computer is more efficient and allows more optimization by targeting
> (by hand or compiler) the actual features of the machine.

That's only true if you recompile for each machine. The best tricks
depend on the microarchitecture. Once code is compiled, it is pretty
much wedded to a specific garbage collector implementation, too.

[Sod Almighty]

On Tuesday, 21 May 2013 22:55:15 UTC+1, André Moraes wrote:

since vb.net ends with .net and .net is a valid domain suffix, the
google groups server probably tried to make sense of that and pointed
to the host at "vb.net"

I wasn't asking in the hope that someone would explain the blindingly obvious, but rather in the hope that someone would realise how goddamn stupid it is.

[Sod Almighty]

On Wednesday, 22 May 2013 00:40:00 UTC+1, Matt Silverlock wrote:

> Sheesh, what a dumb question! Coding for a VM requires that the VM be installed on the machine. Simple as that. VM-advocates prate on about "portability" and such, but they're talking crap. How is something "portable" if it needs runtimes? Portability is the ability to put the .exe on a goddamn flash drive, whack it in and hit "run". Anything else is just bullshit.

A naive question maybe, but not an outright "dumb" one (and you wondered why people see you as abrasive).

No, you misunderstand me. Now I'm trying to be abrasive.

[Sod Almighty]

On Wednesday, 22 May 2013 08:00:05 UTC+1, Paulo Pinto wrote:

Singularity,

- is an operating system written in managed code, by Microsoft themselves. My point was that "it runs on a bunch of M$ operating systems" does not equate to platform-independence or portability.
 

Netduino

- doesn't run the full .NET framework, not even the cut-down "client framework". Besides, the existence of a single overpriced hobbyist microcontroller system that accepts .NET code hardly makes it portable.

You know full-well I'm talking about Linux, Apple Macs, Android, iOS and the like. .NET is limited to M$ operating systems (and the occasional pi-clone if you consider the "micro framework" to be good enough), therefore it isn't portable. When I can compile the current release of .NET on my Debian box, then it'll be portable.

and around .NET 2.0 there was a port for
Symbian.

Yeah, .NET2.0 can screw off, as I made abundantly clear when I mentioned Mono. Besides, what kind of moron uses Symbian these days? Last I saw Symbian, it was in the Nokia N-Gage ten years ago. And it sucked even back then.

On Windows Phone 8, .NET is compiled to native code:

Ahem. WINDOWS PHONE. The clue's in the goddamn name. "Will run on all versions of Windows" is not platform independence.

Besides, catch me using Windows 8? Not likely. It's possibly the most useless piece of software M$ have ever come out with.
 

But spend some time informing yourself?

I just did. And I'm still right.

[Dan Kortschak]

On Wed, 2013-05-22 at 16:18 -0700, Sod Almighty wrote:
> I wasn't asking in the hope that someone would explain the blindingly
> obvious, but rather in the hope that someone would realise how goddamn
> stupid it is.
>

Try using a text-only mail client.

[Kiki Sugiaman]

Use a mail client. There, no explanation.

[Brad Fitzpatrick]

Please keep it friendly.

I don't think we've ever had to ban anybody from this list, but I'm quite willing to do so if we people can't maintain a civil tone.

 

[Kiki Sugiaman]

Please do consider it. The internet does not filter people who can't maintain a civil tone, a human being has to do it.

This is a great and helpful list otherwise.

[Sod Almighty]

I'm using the Google webpage. It's not something stupid that my client is doing, it's something stupid that Google is doing.

[Sod Almighty]

I see. So people calling me a troll and generally insulting me; and my using language like "goddamned" is perfectly acceptable; but admitting to being abrasive, well, that's crossing the line? Do you have a rule book somewhere I could look at? Coz I've never seen one so completely arse-backward before.

[Sod Almighty]

On Thursday, 23 May 2013 00:40:47 UTC+1, ksug wrote:

Please do consider it. The internet does not filter people who can't maintain a civil tone, a human being has to do it.

This is a great and helpful list otherwise.

Yeah. I almost came from the overwhelmingly welcoming attitude I received right from the get-go. I was so warm and fuzzy, I could barely type.

You people crack me up, you really do. I'm getting on great on the Red programming forum, and on the Rust IRC channel; but you guys and the people over at Dlang are just so fucking friendly I can hardly contain myself.

[Brad Fitzpatrick]

We don't care about swear words.

We don't care about level of programming experience.

We don't care whether everybody likes the Go language.

We don't care whether people criticize the language.

We do care that people are friendly to others and criticism is constructive.

We don't even care if there are occasional violations of the above.

But you can't just be a dick _all_ the time.

[Dan Kortschak]

On Wed, 2013-05-22 at 17:20 -0700, Sod Almighty wrote:
> I'm using the Google webpage. It's not something stupid that my client
> is doing, it's something stupid that Google is doing.

So stop using the web page and use a mail client.

[Ian Lance Taylor]

This is not a productive line of discussion. To the extent that Mr.
Almighty and/or Mr. th3.w3as3l talks about Go, by all means reply if
you think it will be useful, especially if he or she has any useful
points to make beyond what we already know. But I do think it's time
to drop any side discussions. Thanks.

Ian

[Gerard]

The x86 vs RISC discussion has a long beard. Approx 15 years ago we used to have these $10k blue/purple DEC Alpha workstations, model "pizza box" and "bread toaster" with 64 bit Windows NT. The 64 bit Alpha processor was especially in the 3D CAD world an advantage, compared to the Pentium of that day. But that was because it was all 64 bit.

But should the end user, or a non-assembler writing programmer, care about what processor type is inside a computer? Does it matter whether the processor is Itanium, x86 or RISC ?

Op woensdag 22 mei 2013 18:50:27 UTC+2 schreef John Nagle het volgende:

[Paul]

<What's the point in compiling to the metal?>

Compiling-to-the-metal is a silly new age buzzword for something you obviously do when you want to use your hardware to its maximum potential. But thats not new.

Of course the Hardware matters, not that I am a fan of Intel machine code, which looks ugly. I think somebody from Microsoft once called it "brain damaged", ok that was 80286 but still ...   there is pettier stuff. 

I really appreciate Thomas Bushnells comment  where he gave some context as to why Java(JVM) was originally done:

"The JVM was not created because it was an awesome way to implement a language.

it was chosen specifically because Java was intended to be used as a web language, in which browsers would run untrusted JVM bytecodes." 

Context helps a lot for a deeper understanding. Java(JVM) was created during the dotcom bubble and there is a  larger story around that. 

[Aram Hăvărneanu]

> it was chosen specifically because Java was intended to be used as
> a web language, in which browsers would run untrusted JVM bytecodes.

> So compiling to bare metal was not feasible. This is why the JVM
> has all the silly restrictions it does; they are an attempt to make
> it safer to run untrusted programs.

This is highly unlikely. Java development started in 1991, there
was no web back then.

A more likely explanation was that Sun wanted to ensure a common
target platform on the very heterogenous workstation market that
existed back then. Ironically, this helped the Unix commoditization
process that let to Sun's demise.

Somewhat unrelated, but I want to point out that it is possible to
make running native untrusted programs safe:
http://pdos.csail.mit.edu/~baford/vm/

--
Aram Hăvărneanu

[Rob Pike]

My bet is that the JVM arose because they had an interpreter and
wanted to create a dense encoding of a "compiled" Java program, so
they defined an interpreter format they could write to disk. All the
sequelae, including the peculiarities of the JVM as an actual machine,
are direct consequences of that opportunistic action.

-rob

[Paulo Pinto]

Just because it has Windows on the name it doesn't mean it is the same
architecture.

On 23 Mai, 01:31, Sod Almighty <sod.almig...@gmail.com> wrote:
> On Wednesday, 22 May 2013 08:00:05 UTC+1, Paulo Pinto wrote:
>
> > Singularity,
>

> - is an operating system written *in* managed code, by *Microsoft themselves
> *. My point was that "it runs on a bunch of M$ operating systems" does not

> equate to platform-independence or portability.
>
> > Netduino
>
> - doesn't run the full .NET framework, not even the cut-down "client
> framework". Besides, the existence of a single overpriced hobbyist
> microcontroller system that accepts .NET code hardly makes it portable.
>
> You know full-well I'm talking about Linux, Apple Macs, Android, iOS and
> the like. .NET is limited to M$ operating systems (and the occasional
> pi-clone if you consider the "micro framework" to be good enough),

> therefore it isn't portable. When I can compile the *current release* of

> .NET on my Debian box, then it'll be portable.
>
> and around .NET 2.0 there was a port for
>
> > Symbian.
>
> Yeah, .NET2.0 can screw off, as I made abundantly clear when I mentioned
> Mono. Besides, what kind of moron uses Symbian these days? Last I saw
> Symbian, it was in the Nokia N-Gage ten years ago. And it sucked even back
> then.
>
> On Windows Phone 8, .NET is compiled to native code:
>
>
>

> Ahem. *WINDOWS PHONE*. The clue's in the goddamn name. "Will run on all

[Paulo Pinto]

James Gosling also stated somewhere that the bytecode choice was based
on his experience
with virtual machines.

I really wish they had gone with AOT compilation instead.

[Paulo Pinto]

I was a C++ guy back then (still am to certain extent), but also a
Turbo Pascal/Delphi/Oberon refugee.

So Java looked interesting as a way of doing distributed computing and
as
a better C++, in the sense I didn't had to make my code full of
#ifdefs to make
it portable across multiple compiler versions and OS.

In those days templates, exceptions and the stl were still very
experimental features
that very few compilers offered. The C world, was no better with many
compilers still
not being full ANSI C89 compliant.

Additionally it had a "comes with batteries" feeling when compared
with the poor
offerings of C and C++ at the time, and a modern toolchain.

--
Paulo

[Aram Hăvărneanu]

> in the sense I didn't had to make my code full of #ifdefs to make
> it portable across multiple compiler versions and OS.

Plan 9 has been ported to at least dozens of very different machines
with no #ifdefs. The Plan 9 C dialect doesn't even use a preprocessor.

Of course, when you want to program for other systems, you need to
play by their rules, and #ifdefs are the norm, but it's still
possible to avoid most of them.

--
Aram Hăvărneanu

[⚛]

On Wednesday, May 22, 2013 5:09:01 PM UTC+2, Niklas Schnelle wrote:

Actually Go's interface calls can't be inlined by ahed of time compilation and would indeed be inlineable by a JIT.

This distinction holds true only for a small percentage of virtual method calls. In majority of cases there is no difference between AOT and JIT when trying to optimize virtual method calls.

 

Also note that as far as I know there is no technical reason Go can't be implemented on a VM for example for .NET the language specification doesn't enforce
ahead of time compilation or even static compilation. In fact the Go implementation for LLVM that is in active development will most likely be able to run with JIT compilation.
The primary reason that AOT still beats JIT in most cases is that the JIT can only spend so much time on optimization that it's amortized over a single run time, while
AOT can amortize over all runtimes of the produced binary. However there is nothing stopping you from doing a lot mor optimizations when you know your runtime is very long,
for example in a server environment. In fact Mono the open .NET implementation can use the full LLVM optimizations during JIT when using that as VM backend.
So the important thing to take away here is that it's not Go that doesn't use a VM but the reference implementation of Go.

On Wednesday, May 22, 2013 10:38:01 AM UTC+2, Bienlein wrote:

I don't even think the question is naive. It's a very fair question.

Thank you, fair enough ;-).

Not that I am in favor of VM-based languages in general, but isn't one of the proclaimed benefits of using a VM + JIT is that this allows certain optimizations that are just not possible using a to-native compiler? Things like inlining virtual method calls, removing branching conditions that are never taken, and having a global view of the program at runtime.

Inlining virtual method calls is a good point. Alas, there aren't any in C or Go. So it seems the more dynamic a language the more it can profit from runtime optimization. It is quite remarkable that Dart is doing better in this sudoku test than Lua + JIT. Coming to speak of Lua: Lua exists for almost every platform (as long as some ISO C compiler exists) for it. It doesn't like like this were also the plan for Go. Go is for network programming, server administration, etc, not for embedded stuff.

Removing branching conditions that are never taken is a good point as well. But my knowledge about compiler construction is too limited to estimate whether C or Go would benefit here from runtime optimzations.

By the way a runtime and a vm is not the same thing. For instance Objective-C has a runtime, which does the dynamic message dispatch and includes the GC. It is not a vm, though, as it does not mimic the machine.

A VM with REPL for development time, with compilation to native code when deploying the application.

I never really understood the point of those REPLs. What you can do with them is so limited ... Incremental compilation in the eclipse Scala plugin is so slow (even slower than compiling the whole application with the IDEA Scala plugin) that I sometimes use the REPL. If compilation is quick as in Go I see no real reason for it.

-- Bienlein

[Rob Pike]

The Plan 9 C compiler does have a preprocessor, it's just incorporated
directly into the compiler's lexical phase and does not implement ANSI
C; it's K&R only, so no #if for example. But it's needed for #include
and simple #define.

-rob

[Paulo Pinto]

I learned by trial and error to avoid them on my own code.

Nowadays on the few cases I still do C or C++, I rather take the
approach the Go team uses and
have specific implementation files for each compiler/os combination.

It avoids #ifdef spaghetti code and makes the code much nicer to read.

But I also have to admit that the language tooling has improved a lot
in the last decade, specially
with the likes of llvm and gcc being available.

My worst C compiler experience so far was the aC compiler in HP-UX
10.x back in 2000.

[peterGo]

Aram,

"THE Java™ programming language was originally called Oak, and was designed for use in embedded consumer-electronic applications by James Gosling. After several years of experience with the language, and significant contributions by Ed Frank, Patrick Naughton, Jonathan Payne, and Chris Warth it was retargeted to the Internet, renamed, and substantially revised to be the language specified here."

The Java™ Language Specification, Third Edition.
http://docs.oracle.com/javase/specs/jls/se5.0/jls3.pdf

Peter

[Tobia]

IMHO compiling a language directly to machine code is a good thing, because it means getting rid of as much "bloat"—meaning both wasted cycles and wasted bytes—as the state of the art allows you to do, without having to code in assembly yourself.

An implementation that does not compile to machine code will have to waste either bytes (boxing / tagging every value in ram) and/or cycles (type-checking everything or performing JIT compilation) compared to another implementation that did its homework.

In other words, non-JIT VM aka. interpreters have a quick startup time* but execute slowly. JIT VMs execute almost as fast as compiled code (that's the claim at least) but have horrendous startup times.

Considering that computers have a limited number of cycles per second and programmers have a limited number of hours per week, using a language and toolchain that does as much work for you as possible, beforehand, makes a lot of sense.

–Tobia

* Bash executes a Hello world script almost as fast as the equivalent C program. See this work I did some time ago: https://lists.gnu.org/archive/html/chicken-users/2011-03/msg00070.html

I'll do it again with Go and post the results shortly.

[Andrew Wilkins]

On Friday, 24 May 2013 01:19:02 UTC+8, Paulo Pinto wrote:

My worst C compiler experience so far was the aC compiler in HP-UX
10.x back in 2000.

Just a few years ago we were stuck with a version of aCC whose documentation described it as a Cfront compiler. Yup. aCC is actually not so bad now - at least it has a relatively conformant standard library, which is more than can be said of SUNWspro's default. Can't compile against Boost, various std::containers leak like a sieve, and, even better, corrupt memory. Fun times.