</p>
<p>
-The runtime library for <code>gccgo</code> is mostly the same as the
+The run-time library for <code>gccgo</code> is mostly the same as the
library in <a href="http://code.google.com/p/go">the main Go
repository</a>. The library code in the Go repository is periodically
copied into the <code>gofrontend</code> and the <code>gcc</code>
<p>
To run the resulting file, you will need to tell the program where to
-find the Go runtime library. This can be done either by setting
+find the compiled Go packages. This can be done either by setting
<code>LD_LIBRARY_PATH</code> in your environment:
<pre>
<p>
Under the gc compilers you must set <code>GOMAXPROCS</code> to allow the
-runtime to utilise more than one OS thread. Under <code>gccgo</code> an OS
+run-time support to utilise more than one OS thread. Under <code>gccgo</code> an OS
thread will be created for each goroutine, and <code>GOMAXPROCS</code> is
effectively equal to the number of running goroutines.
</p>
<p>
Programs that perform concurrent computation should benefit from an increase in
<code>GOMAXPROCS</code>. (See the <a
-href="http://golang.org/pkg/runtime/#GOMAXPROCS">runtime package
+href="http://golang.org/pkg/runtime/#GOMAXPROCS"><code>runtime</code> package's
documentation</a>.)
</p>
</p>
<p>
-The Go runtime's scheduler is not as good as it needs to be. In future, it
-should recognise such cases and optimize its use of OS threads. For now,
+Go's goroutine scheduler is not as good as it needs to be. In future, it
+should recognize such cases and optimize its use of OS threads. For now,
<code>GOMAXPROCS</code> should be set on a per-application basis.
</p>
We also considered using LLVM for <code>6g</code> but we felt it was too large and
slow to meet our performance goals.
-<h3 id="How_is_the_runtime_implemented">
-How is the runtime implemented?</h3>
+<h3 id="How_is_the_run_time_support_implemented">
+How is the run-time support implemented?</h3>
<p>
-Again due to bootstrapping issues, the runtime is mostly in C (with a
+Again due to bootstrapping issues, the run-time code is mostly in C (with a
tiny bit of assembler) although Go is capable of implementing most of
-it now. <code>Gccgo</code>'s runtime uses <code>glibc</code>.
+it now. <code>Gccgo</code>'s run-time support uses <code>glibc</code>.
<code>Gc</code> uses a custom library, to keep the footprint under
control; it is
compiled with a version of the Plan 9 C compiler that supports
<p>
A trivial C "hello, world" program compiled and linked statically using gcc
on Linux is around 750 kB. An equivalent Go program is around 1.8 MB, but
-that includes a more powerful runtime. We believe that with some effort
+that includes more powerful run-time support. We believe that with some effort
the size of Go binaries can be reduced.
<h2 id="Performance">Performance</h2>
A variable which has an interface type may be converted to have a
different interface type using a special construct called a type assertion.
This is implemented dynamically
-at runtime, like C++ <code>dynamic_cast</code>. Unlike
+at run time, like C++ <code>dynamic_cast</code>. Unlike
<code>dynamic_cast</code>, there does
not need to be any declared relationship between the two interfaces.
values of the contained type. As the typing is dynamic rather
than static, there is no equivalent of the way that a C++ template may
inline the relevant operations. The operations are fully type-checked
-at runtime, but all operations will involve a function call.
+at run time, but all operations will involve a function call.
<pre>
type iterator interface {
defer func() {
log.Println("done") // Println executes normally even in there is a panic
if x := recover(); x != nil {
- log.Printf("runtime panic: %v", x)
+ log.Printf("run time panic: %v", x)
}
}
log.Println("start")
</dl>
<p>
-Except for things like low-level operating system interface code, the runtime
+Except for things like low-level operating system interface code, the run-time
support is the same in all ports and includes a mark-and-sweep garbage collector
(a fancier one is in the works), efficient array and string slicing,
support for segmented stacks, and a strong goroutine implementation.
<code>$GOARM</code> (arm, default=6)
</dt>
<dd>
- The ARM architecture version the runtime libraries should target.
+ The ARM architecture version the run-time libraries should target.
ARMv6 cores have more efficient synchronization primitives. Setting
- <code>$GOARM</code> to 5 will compile the runtime libraries using
+ <code>$GOARM</code> to 5 will compile the run-time libraries using
just SWP instructions that work on older architectures as well.
Running v6 code on an older core will cause an illegal instruction trap.
</dd>