Actions
Forum Thread Details
  • Replies 26 replies
  • Subscribers 59 subscribers
  • Views 3004 views
  • Users 0 members are here
Related

Google Go on ARM

morgaine

Ealier today, selsinork wrote in another thread (new one here owing to my change of topic):

selsinork wrote:

 

Interestingly,  it's not so long ago that x86 systems were far less capable in terms of  memory, storage and likely CPU than today's ARM systems, yet were  perfectly capable of compiling everything required natively. How quickly  we forget, and how quickly we bloat the software with unnecessary junk  to the point this is no longer true.

That is so very true!!!

 

Software technology needs occasional revolutions too, just like society, to remove layers of accreted crud.  This happens so rarely in computing alas that we're up to our eyeballs in it and barely keeping our heads clear.  It is so rare that I'd like to highlight one relatively recent instance of it, although it is admittedly a revolution with a small 'r'  as it hasn't captured much mindshare in the computing industry.  It's the programming language Google Go.

 

It's not the Go language syntax nor semantics that are revolutionary,  although it is nice enough in both respects and has lots of very effective features especially for concurrent programming.  What is revolutionary about it is its implementation meme, which renouces the idea that building software is divorced from language definition and is performed by third party tools ("make" and its many equivalents in the commandline and IDE worlds) with limited knowledge of the language beyond syntax.  That almost universally prevalent idea has slowed down system building to a crawl right across the world of computing, and it's almost single-handedly reponsible for the problem you described.  (I'm referring to build time only here.)

 

Instead, Go provides integrated build tools and a software construction meme in which to compile a module requires looking only at its immediate dependencies, no further.  In other words, if module A is dependent on B, and B is dependent on C, then to compile A does not require looking at C.  (No explosion of header file lookups.)  Extrapolate this to complex systems with many layers of dependency in breadth and in which each dependency is itself dependent on multiple layers of dependency in depth, and as you can imagine, Go application building can be literally orders of magnitude faster than in most of the languages in common use today.  Many compiles are pretty much instantaneous despite having lots of dependencies.

 

That's "revolutionary" of the kind that removes decades of accumulated crud which has slowed down our systems to a crawl.  It's worth spreading the word about it.  Oh, and it works on ARM, not as efficiently as on x86 yet but it's improving all the time.  I think we should be using Go very widely for as much as possible outside the kernel.

 

Just today on one of my BBB's with Debian installed:

debian@bbb:#  apt-get install golang

...

Need to get 21.9 MB of archives.
After this operation, 81.4 MB of additional disk space will be used.

...

debian@bbb:$  go version

go version go1.0.2

debian@bbb:$  vi hello.go

debian@bbb:$  cat hello.go

package main

 

import "fmt"

 

func main() {
        fmt.Println("Hello, World!")
}

debian@bbb:$  go build hello.go

debian@bbb:$  ./hello

Hello, World!

debian@bbb:$

Viva la revolucion!  image

 

More seriously, it still has a long way to go in a few areas (integration/interoperation is one), but I see very good things ahead for Go.  I recommend that engineers add it to their toolbox and gradually expand their use over time.  Expect huge reductions in crud / time gains on large projects.

 

 

Morgaine.

Parents

  • That almost universally prevalent idea has slowed down system building to a crawl right across the world of computing, and it's almost single-handedly reponsible for the problem you described.  (I'm referring to build time only here.)

    Actually, C has the nice feature that compilations can be done in parallel,

    using -j or --jobs, so having a multi-core machine can speed up compilation nicely.

    I think in order to have Go's transitive compilation independence, your data structures

    need to (implicitly) use a lot more indirection, so you pay a run-time performance penalty,

    although I have not looked at Go closely.

  • in reply to Former Member

    That's not a C feature, it's a feature of make:

    make  -j [jobs]  --jobs[=jobs]

    Make knows almost nothing at all about C, so if you've added the -j option to its compilation flags it'll merrily kick off concurrent builds for anything that the Makefile hasn't specifically ordered through sequential dependencies.  The most common candidate is to build concurrently all the .o files listed on the RHS of a target, but it does so without understanding why, ie. merely because its Makefile has been configured that way.

     

    And what's worse, those many instances of the C compiler that have been kicked off by make will all process the same C header files repeatedly and independently, only slightly held back from total insanity by the magic #ifdef-#include-#endif incantations in the .h headers which are added manually by programmers, not a feature of the language system.

     

    It's very different in Go.  The "go" build utility doesn't obey a configuration file at all, and instead it digs out the dependency information directly from the module being compiled.

  • in reply to morgaine

    That's not a C feature, it's a feature of make:

    What I meant is that it's a feature of C that compilations can be done in any order or in parallel,

    so you can use make's -j feature. 

  • in reply to Former Member

    coder27 wrote:

     

    What I meant is that it's a feature of C that compilations can be done in any order or in parallel,

    But that's not really a feature of C, it's a feature of the reentrancy of language compilers in all Unix-like systems and indeed in all sane operating systems everywhere.  I can't think off-hand of any current-day language compiler that can't compile two different sourcefiles concurrently on a multitasking system even in the same directory, and the only reason why they won't usually compile the same sourcefile concurrently twice over is because this would normally result in concurrent writing of the same output file which is likely to result in corruption.

     

    Make -j makes good use of this general reentrancy of compilers (and it never attempts to compile one and the same file concurrently), but it's not a feature of the languages themselves.  Make just obeys its makefiles, and does exactly the same whatever the language.

Reply
  • in reply to Former Member

    coder27 wrote:

     

    What I meant is that it's a feature of C that compilations can be done in any order or in parallel,

    But that's not really a feature of C, it's a feature of the reentrancy of language compilers in all Unix-like systems and indeed in all sane operating systems everywhere.  I can't think off-hand of any current-day language compiler that can't compile two different sourcefiles concurrently on a multitasking system even in the same directory, and the only reason why they won't usually compile the same sourcefile concurrently twice over is because this would normally result in concurrent writing of the same output file which is likely to result in corruption.

     

    Make -j makes good use of this general reentrancy of compilers (and it never attempts to compile one and the same file concurrently), but it's not a feature of the languages themselves.  Make just obeys its makefiles, and does exactly the same whatever the language.

Children
No Data