Go 2.0 without garbage collector?

[akwillis]

Most rigs built for gaming have ample memory and more than enough
computational power. I'd rather waste a bit of memory/computation by using
a gc than actually managing that memory myself. I'd hate to see the golang
community waste resources trying to shoehorn manual memory management and
gc together into one language. Right now it is an issue of a naive gc
implementation. Golang has a great community and is progressing rapidly,
I'm confident you won't be waiting long for what you
desire(performance+garbage collection)

Does the Go team has thinked into a next version without the garbage
collector?
Go is very cool to use but I need the best possible performance since I've
not deep pockets like Google. When you are small, you need try to minimize
the cost of the servers.
And Rust does a great balance between a language of high level without a
significant loss of performance.
I've been translating some Go projects from Go to Rust but the task is very
large, especially since every time there are more interesting projects
for me.
So, the fastest way for me will be to build a transpiler from Go to Rust.
At least there is some intention to have an optional garbage collection.
However, Go is easier to prototype.

[Andrew Gerrand]

I'd hate to see the golang community waste resources trying to shoehorn
manual memory management and gc together into one language

Don't worry. It's never going to happen. Go has been a garbage collected
language from day one. If you want a language with optional GC then use one
that was designed that way.

Andrew

[Andrew Gerrand]

Only to have your project Calimstore built in Rust, it would be worth the
effort.

Why would you care? Camlistore works great in Go. Optional GC wouldn't
help. It's a largely I/O bound system.

[a***@public.gmane.org]

Post by Andrew Gerrand

Only to have your project Calimstore built in Rust, it would be worth the
effort.

Why would you care? Camlistore works great in Go. Optional GC wouldn't
help. It's a largely I/O bound system.

There is a recent trend where people care what language something is
written in, even when it doesn't affect the end user.
My favourite examples are when people call things like a spreadsheet
program Gospreadsheet.or Jspreadsheet. end users shouldn't care what
language X is written in if its a useful tool, so don't name your project
like that.
In reality it only matters if its a software library, or is meant to be
extensible.

I admit when I read that RabbitMQ was in erlang I had a fear of the unknown
even though it doesn't make any difference whatsoever.

[a***@public.gmane.org]

Post by a***@public.gmane.org

Post by Andrew Gerrand

Only to have your project Calimstore built in Rust, it would be worth the
effort.

Why would you care? Camlistore works great in Go. Optional GC wouldn't
help. It's a largely I/O bound system.

There is a recent trend where people care what language something is
written in, even when it doesn't affect the end user.
My favourite examples are when people call things like a spreadsheet
program Gospreadsheet.or Jspreadsheet. end users shouldn't care what
language X is written in if its a useful tool, so don't name your project
like that.
In reality it only matters if its a software library, or is meant to be
extensible.
I admit when I read that RabbitMQ was in erlang I had a fear of the
unknown even though it doesn't make any difference whatsoever.

Also, I'm announcing my new Search and Advertising business Rustogle, we
are a lot faster than Google for various technical reasons..

[Hasan Yasin Öztürk]

Rustogle is really blazing fast. No garbage collection, no frame drops.
Good job there.

I have seen people starting to use Linkedin after the big hype started with
Linkedin moving to Nodejs in the backend. After this, I can really
understand programmers being curious about the language that their favorite
tools were written in.

[a***@public.gmane.org]

Go's garbage collector is a defining feature. It's critical to how go
routines work and share memory. Concurrent and more incremental GC's will
help Go more than removing the collector.

I think there are misconceptions about garbage collection - many have been
stated by Dmitry and others regarding performance vs manual memory
allocation.

One extra thing I'd like to point out is reference counting can have
unpredictable delays too. One reference decrement can cause a whole chain
of frees to occur, with no predictability at all. So shifting Go to
reference counting wouldn't be a solution.

[Bakul Shah]

Post by a***@public.gmane.org
One extra thing I'd like to point out is reference counting can have
unpredictable delays too. One reference decrement can cause a whole chain
of frees to occur, with no predictability at all.

Not necessarily. When a object's refcount goes to zero,
rather than freeing it right away you can enqueue it for lazy
refcount decrementing of objects it points to.

[a***@public.gmane.org]

Post by Bakul Shah

Post by a***@public.gmane.org
One extra thing I'd like to point out is reference counting can have
unpredictable delays too. One reference decrement can cause a whole

chain

Post by a***@public.gmane.org
of frees to occur, with no predictability at all.

Not necessarily. When a object's refcount goes to zero,
rather than freeing it right away you can enqueue it for lazy
refcount decrementing of objects it points to.

Interesting point, but to me that sounds like reinventing a mark and sweep
garbage collector in a round about way. If you process the lazy list
incrementally, well then its an incremental GC again.

I know your comment wasn't actually suggesting we add reference counting to
Go, but I'd like to refute that for people who may read it that way.

[Nicolas Grilly]

The more you optimize, the more garbage collection and reference counting
are behaving similarly.

For example: http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

Post by a***@public.gmane.org
Interesting point, but to me that sounds like reinventing a mark and sweep
garbage collector in a round about way. If you process the lazy list
incrementally, well then its an incremental GC again.
I know your comment wasn't actually suggesting we add reference counting
to Go, but I'd like to refute that for people who may read it that way.

[Bakul Shah]

Post by a***@public.gmane.org

Post by Bakul Shah

Post by a***@public.gmane.org
One extra thing I'd like to point out is reference counting can have
unpredictable delays too. One reference decrement can cause a whole

chain

Post by a***@public.gmane.org
of frees to occur, with no predictability at all.

Not necessarily. When a object's refcount goes to zero,
rather than freeing it right away you can enqueue it for lazy
refcount decrementing of objects it points to.

Interesting point, but to me that sounds like reinventing a mark and sweep
garbage collector in a round about way. If you process the lazy list
incrementally, well then its an incremental GC again.

Delayed scanning of dead nodes is much simpler since none of
the embedded ptrs are going to change. But during concurrent
scanning of live nodes, embedded ptrs *can* change & you run
into all sort of issues. In RC no pauses are required but you
need atomic updates if done concurrently. Even in "pauseless"
concurrent generational incremental continuous[1] GC you will
have pauses (but presumably tolerable) and synchronization
points and need to scan the stack and write barriers or read
barriers &/or you will need help from special hardware or
kernel (if you are playing virtual memory games). So much more
complexity. Still, RC doesn't solve the problem of garbage
containing reference loops so you still need GC and it is
probably less performant in concurrent programs than GC.

Post by a***@public.gmane.org
I know your comment wasn't actually suggesting we add reference counting to
Go

Correct. I was just commenting on your "reference counting can
have unpredictable delays".

[1] not sure if I missed any GC related buzzwords here.

[Archos]

Post by a***@public.gmane.org

Post by Andrew Gerrand

Only to have your project Calimstore built in Rust, it would be worth the
effort.

Why would you care? Camlistore works great in Go. Optional GC wouldn't
help. It's a largely I/O bound system.

There is a recent trend where people care what language something is
written in, even when it doesn't affect the end user.
My favourite examples are when people call things like a spreadsheet
program Gospreadsheet.or Jspreadsheet. end users shouldn't care what
language X is written in if its a useful tool, so don't name your project
like that.
In reality it only matters if its a software library, or is meant to be
extensible.

I'm sure that the choose of a language does not affect to the end user but
to your pockets.

IronWorker was from 30 servers (using Ruby) to only 2 servers (with Go):

http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html

[Archos]

I didn't say by the optional GC; Rust is lower-level (than Go) so programs
that are I/O bound system (file systems, databases) should have a better
performance.

But until that a filesystem or database is not built in Rust, I could not
do an an objective comparison.

Post by Andrew Gerrand

Only to have your project Calimstore built in Rust, it would be worth the
effort.

Why would you care? Camlistore works great in Go. Optional GC wouldn't
help. It's a largely I/O bound system.

[Gerard]

Post by Archos
I didn't say by the optional GC; Rust is lower-level (than Go) so programs
that are I/O bound system (file systems, databases) should have a better
performance.

I am not really sure that is true. Rust uses different approaches, yes. Go
is taking more the Wirth (Pascal/Modula/Oberon) approach of better data
abstraction combined with GC.

I wouldn't consider it higher-level, just simpler.

[Archos]

Post by Gerard

Post by Archos
I didn't say by the optional GC; Rust is lower-level (than Go) so
programs that are I/O bound system (file systems, databases) should have a
better performance.

I am not really sure that is true. Rust uses different approaches, yes. Go
is taking more the Wirth (Pascal/Modula/Oberon) approach of better data
abstraction combined with GC.
I wouldn't consider it higher-level, just simpler.
A "simpler sintaxis" seems to be a euphemism for "fewer features".

[David Symonds]

Post by Gerard
A "simpler sintaxis" seems to be a euphemism for "fewer features".

And sometimes a cigar is just a cigar.

[Sebastien Binet]

Post by David Symonds

Post by Gerard
A "simpler sintaxis" seems to be a euphemism for "fewer features".

And sometimes a cigar is just a cigar.

this, "|", is not a pipe.

-s

[Gerard]

Post by Gerard

Post by Archos
I didn't say by the optional GC; Rust is lower-level (than Go) so
programs that are I/O bound system (file systems, databases) should have a
better performance.

I am not really sure that is true. Rust uses different approaches, yes.
Go is taking more the Wirth (Pascal/Modula/Oberon) approach of better data
abstraction combined with GC.
I wouldn't consider it higher-level, just simpler.
A "simpler sintaxis" seems to be a euphemism for "fewer features".

Yes, exactly !

"Are you quite sure that all those bells and whistles, all those wonderful
facilities of your so called powerful programming languages, belong to the
solution set rather than the problem set?"

— Edsger W. Dijkstra

[j***@public.gmane.org]

Is there any chance of getting Erlang-style thread-local GC in Go, or at
least thread-local GC for young generations when Go gets a generational
collector?

Does the Go team has thinked into a next version without the garbage
collector?
Go is very cool to use but I need the best possible performance since

I've

not deep pockets like Google. When you are small, you need try to

minimize

the cost of the servers.
And Rust does a great balance between a language of high level without a
significant loss of performance.
I've been translating some Go projects from Go to Rust but the task is

very

large, especially since every time there are more interesting projects

for

me.
So, the fastest way for me will be to build a transpiler from Go to

Rust. At

least there is some intention to have an optional garbage collection.
However, Go is easier to prototype.

It seems that what you are asking for is a concurrent/pauseless GC.
Eventually Go will have it. I mean Go1.
You also seem to assume that GC is necessary slower than manual memory
management. This is not necessary true. There are several reasons why
1. To track object lifetime in a concurrent setting you need to resort
to something like atomic reference counting, which is costly. While in
a GC environment you have it for free.
2. GC batches free operations which makes them significantly more
efficient than assorted one-by-one free operations.
3. In a GC environment you can have bump-the-pointer allocator which
is way more efficient than segregated allocators that languages with
manual object lifetime tracking have to use.
4. GC can improve locality and defragment heap by moving objects.
5. In a GC environment you can combine several objects into a single
allocation, reducing cost of allocation, free and memory consumption.
Something that languages with manual object lifetime tracking cannot
do.
So I would say that Go1 just needs a better GC/allocator.

[Andy Balholm]

Is there any chance of getting Erlang-style thread-local GC in Go, or at least thread-local GC for young generations when Go gets a generational collector?

Pure goroutine-local GC is not possible, since goroutines share memory. But I can imagine an enhanced escape analysis in the compiler that could find allocations that escape the current function but don't escape the goroutine. Will someone ever do all that work? Will it actually be a big performance gain? I don't know.

[Konstantin Khomoutov]

On Fri, 18 Jul 2014 08:58:10 -0700

Post by Andy Balholm

Post by j***@public.gmane.org
Is there any chance of getting Erlang-style thread-local GC in Go,
or at least thread-local GC for young generations when Go gets a
generational collector?

Pure goroutine-local GC is not possible, since goroutines share
memory. But I can imagine an enhanced escape analysis in the compiler
that could find allocations that escape the current function but
don't escape the goroutine.

I'm afraid you can't do that: a function running within a goroutine
might call another function using its address -- that is, divert the
control flow to a path determined at runtime.

[Kevin Malachowski]

Wouldn't the compiler detect this dynamic situation and say that the data passed would have to be shared-heap allocated? I think the idea is if it can be proved that it doesn't escape then it would be local heap allocated.

For example, a value used in a closure in a function could be locally heap allocated if the compiler notices the closure itself doesn't escape, unless I'm missing something. I have no idea how hard that would be to implement, though.

[Chandru]

Why isn't #5 possible in a non-GC language? Rust's TypedArea[1] seems to be
doing exactly that.

[1] http://doc.rust-lang.org/arena/struct.TypedArena.html

--
Chandra Sekar.S


On Thu, Jul 17, 2014 at 10:27 PM, 'Dmitry Vyukov' via golang-nuts <

Does the Go team has thinked into a next version without the garbage
collector?
Go is very cool to use but I need the best possible performance since

I've

not deep pockets like Google. When you are small, you need try to

minimize

the cost of the servers.
And Rust does a great balance between a language of high level without a
significant loss of performance.
I've been translating some Go projects from Go to Rust but the task is

very

large, especially since every time there are more interesting projects

for

me.
So, the fastest way for me will be to build a transpiler from Go to

Rust. At

least there is some intention to have an optional garbage collection.
However, Go is easier to prototype.

It seems that what you are asking for is a concurrent/pauseless GC.
Eventually Go will have it. I mean Go1.
You also seem to assume that GC is necessary slower than manual memory
management. This is not necessary true. There are several reasons why
1. To track object lifetime in a concurrent setting you need to resort
to something like atomic reference counting, which is costly. While in
a GC environment you have it for free.
2. GC batches free operations which makes them significantly more
efficient than assorted one-by-one free operations.
3. In a GC environment you can have bump-the-pointer allocator which
is way more efficient than segregated allocators that languages with
manual object lifetime tracking have to use.
4. GC can improve locality and defragment heap by moving objects.
5. In a GC environment you can combine several objects into a single
allocation, reducing cost of allocation, free and memory consumption.
Something that languages with manual object lifetime tracking cannot
do.
So I would say that Go1 just needs a better GC/allocator.
--
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
For more options, visit https://groups.google.com/d/optout.

['Dmitry Vyukov' via golang-nuts]

Post by Chandru
Why isn't #5 possible in a non-GC language? Rust's TypedArea[1] seems to be
doing exactly that.
[1] http://doc.rust-lang.org/arena/struct.TypedArena.html

It's possible with user assistance, in extreme case user just manually
puts several objects into a single struct. But even that is not always
possible. First, there are abstraction boundaries. Then, subobjects
may need to be deleted at different times, and you don't know which
one will be the last. And in the end, users just do not do it most of
the time.
Go does this transparently and it can combine objects of different
types and across abstraction boundaries. For example, in the following
code:

func libAfoo(...) {
var mu sync.Mutex
libBfoo(&mu)
mu.Lock()
}

func libBfoo(mu *sync.Mutex) {
s := string(byteSlice)
...
}

mu and s buffer can end up in a single memory block.

[Damon Zhao]

The WOW use erlang for backend server

圚 2014幎7月17日星期四UTC+8䞋午8时47分26秒Archos写道

Sorry, I was wrong again :(
To make it clear, please
Tell me three real-time games built with a language with GC (i.e. Java),
and of course, without bindings to a language without GC (i.e. C++).

You are seriously wrong. There are tons of "realtime" games (some are
very famous and popular) written in languages with GC.

Ok, tell me three real-time games built with a language without GC, and
of course without bindings to a language garbaged.

Tell me three real-time games built with a language WITH GC, and of
course without bindings to a language garbaged.

[akwillis]

Also, Lua is used in wow as a scripting engine in the macro system.

Post by Damon Zhao
The WOW use erlang for backend server
圚 2014幎7月17日星期四UTC+8䞋午8时47分26秒Archos写道

Sorry, I was wrong again :(
To make it clear, please
Tell me three real-time games built with a language with GC (i.e. Java),
and of course, without bindings to a language without GC (i.e. C++).

You are seriously wrong. There are tons of "realtime" games (some are
very famous and popular) written in languages with GC.

Ok, tell me three real-time games built with a language without GC,
and of course without bindings to a language garbaged.

Tell me three real-time games built with a language WITH GC, and of
course without bindings to a language garbaged.

[Tamás Gulácsi]

Thank you for your efforts!

[Jsor]

I have recently started dabbling with the Unreal Engine development kit.
You might know the Unreal Engine from almost every single AAA FPS game
currently on the market. The language you write your game logic in for it
is C++, or Epic's "dialect" of it. You know what they implemented for their
C++ framework? Garbage collection.
https://wiki.unrealengine.com/Garbage_Collection_Overview

Also every Jak and Daxter game and Crash Bandicoot game use engines written
in variants of Allegro Common LISP that compiled to Playstation 2 native
MIPS, and that uses a generational GC. To be fair, they also used inline
assembly in places, but Go can use assembly too if you want. But was the
engine very good? Well, they made a seamless streaming world
<http://scottbilas.com/files/2003/gdc_san_jose/continuous_world_slides.pdf> with
it. With multiple viewports. On a Playstation 2. So yes, I'd say so.

[Donovan Hide]

Post by Jsor
Also every Jak and Daxter game and Crash Bandicoot game use engines
written in variants of Allegro Common LISP that compiled to Playstation 2
native MIPS, and that uses a generational GC. To be fair, they also used
inline assembly in places, but Go can use assembly too if you want. But was
the engine very good? Well, they made a seamless streaming world
<http://scottbilas.com/files/2003/gdc_san_jose/continuous_world_slides.pdf> with
it. With multiple viewports. On a Playstation 2. So yes, I'd say so.

Thanks for mentioning this. Led to a very interesting read:

http://all-things-andy-gavin.com/2011/03/12/making-crash-bandicoot-gool-part-9/

[Sam Harwell]

All UnrealEngine 3 games use a garbage collected scripting language for a wide variety of critical tasks.

Sam

From: golang-nuts-/***@public.gmane.org [mailto:golang-nuts-/***@public.gmane.org] On Behalf Of Archos
Sent: Thursday, July 17, 2014 7:39 AM
To: golang-nuts-/***@public.gmane.org
Cc: raul.san-***@public.gmane.org; alexrubashkin-***@public.gmane.org
Subject: Re: [go-nuts] Go 2.0 without garbage collector?



El jueves, 17 de julio de 2014 13:37:37 UTC+1, Archos escribió:
El jueves, 17 de julio de 2014 13:31:15 UTC+1, alexru...-***@public.gmane.org<mailto:alexru...-***@public.gmane.org> escribió:
четверг, 17 Оюля 2014 г., 14:11:08 UTC+3 пПльзПватель Archos МапОсал:
You are seriously wrong. There are tons of "realtime" games (some are very famous and popular) written in languages with GC.

Ok, tell me three real-time games built with a language without GC, and of course without bindings to a language garbaged.

I mean:

Tell me three real-time games built with a language WITH GC, and of course without bindings to a language garbaged.
--
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+unsubscribe-/***@public.gmane.org<mailto:golang-nuts+unsubscribe-/***@public.gmane.org>.
For more options, visit https://groups.google.com/d/optout.

[Sam Harwell]

The best possible performance actually comes from using a Garbage Collector for memory management in all but one case. That specific case is writing an application which needs to run in as little memory as possible, regardless of the performance impact of that decision. As we all know, that situation virtually never arises in modern programming. Also note that this situation generally does not apply to large programs, because the coding complexity of manual memory management throughout a large codebase results in inefficient memory practices that negate the theoretical advantage offered by manual management.

However, the following caveats do hold:


1. For a particular application (algorithm and/or memory usage characteristics), some garbage collector will outperform the available manually-managed allocators for that application. However, there is no garbage collector which performs best for all applications. The best production garbage collectors generally fall into three categories according to the anticipated majority of applications which will run within the environment:

a. High-throughput collectors which target applications with exceptionally large memory spaces, and often allocate objects at higher rates than seen in other applications. These could be called “server” collectors (not to be confused with the -server command line option in the JVM).

b. Concurrent, low-latency collectors which balance throughput with pauses and are widely applicable to “client” applications. By overall usage, these are currently the most commonly used garbage collectors, and are the foundations of both the current .NET Framework collector and the JVM.

c. Real-time garbage collectors which provide hard guarantees regarding the duration of a pause. These collectors are used in specialized applications where a long GC pause poses a physical threat (e.g. system control software for aviation). IBM’s Metronome is a prime example of this type of collector.

2. The amount of work required to implement an efficient garbage collection environment within a new language is not only enormous, but often requires the involvement of researchers who focus on this particular area of software development (and aren’t particularly common). The “easy” to implement collectors are frequently much slower than the better algorithms, resulting in the unfortunately common situation where garbage collectors get a bad name. In particular, when a garbage collector is first introduced to a new environment, users observe poor performance compared to the manually-managed environment in which they previously worked, but they do not realize that this deficit is due to the particular garbage collector which was added and not an overall characteristic of all garbage collectors.

a. One of the best ways for young garbage-collected languages to be fairly evaluated for new language features is to write a compiler that targets the bytecode of an existing runtime system that includes a high-performance garbage collector. The most well supported options are the CLI (.NET) and the JVM (Java). For better or worse, larger projects with better funding (such as Go) tend to have an easier time avoiding this path.

Thanks,
Sam

From: golang-nuts-/***@public.gmane.org [mailto:golang-nuts-/***@public.gmane.org] On Behalf Of Archos
Sent: Thursday, July 17, 2014 3:52 AM
To: golang-nuts-/***@public.gmane.org
Subject: [go-nuts] Go 2.0 without garbage collector?

Does the Go team has thinked into a next version without the garbage collector?

Go is very cool to use but I need the best possible performance since I've not deep pockets like Google. When you are small, you need try to minimize the cost of the servers.
And Rust does a great balance between a language of high level without a significant loss of performance.

I've been translating some Go projects from Go to Rust but the task is very large, especially since every time there are more interesting projects for me.
So, the fastest way for me will be to build a transpiler from Go to Rust. At least there is some intention to have an optional garbage collection.

However, Go is easier to prototype.
--
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+unsubscribe-/***@public.gmane.org<mailto:golang-nuts+unsubscribe-/***@public.gmane.org>.
For more options, visit https://groups.google.com/d/optout.

['Philip O'Toole' via golang-nuts]

Sam -- interesting statements. In your opening paragraph, what do you mean by "performance"? You're talking about sheer througput of, say, a program moving data through RAM?

And can you give an example of what you mean by "inefficient memory practices"? I've seen plenty of inefficent memory practices in garbage-collected languagues (notably Java, running in a modern HotSpot JVM) that negate the theoretical advantage offered by automatic management. :-)

(FWIW, I don't have a strong opinion about GC, or lack thereof. I am using Go because it, so far, makes writing system software pretty nice).


Philip

 
-----------------------------------------
http://www.philipotoole.com


On Wednesday, July 23, 2014 9:12 PM, Sam Harwell <sam-8CAjhppLBTbEP2vymgFrBlaTQe2KTcn/@public.gmane.org> wrote:



The best possible performance actually comes from using a Garbage Collector for memory management in all but one case. That specific case is writing an application which needs to run in as little memory as possible, regardless of the performance impact of that decision. As we all know, that situation virtually never arises in modern programming. Also note that this situation generally does not apply to large programs, because the coding complexity of manual memory management throughout a large codebase results in inefficient memory practices that negate the theoretical advantage offered by manual management.
 
However, the following caveats do hold:
 
1.       For a particular application (algorithm and/or memory usage characteristics), some garbage collector will outperform the available manually-managed allocators for that application. However, there is no garbage collector which performs best for all applications. The best production garbage collectors generally fall into three categories according to the anticipated majority of applications which will run within the environment:
a.       High-throughput collectors which target applications with exceptionally large memory spaces, and often allocate objects at higher rates than seen in other applications. These could be called “server” collectors (not to be confused with the -server command line option in the JVM).
b.      Concurrent, low-latency collectors which balance throughput with pauses and are widely applicable to “client” applications. By overall usage, these are currently the most commonly used garbage collectors, and are the foundations of both the current .NET Framework collector and the JVM.
c.       Real-time garbage collectors which provide hard guarantees regarding the duration of a pause. These collectors are used in specialized applications where a long GC pause poses a physical threat (e.g. system control software for aviation). IBM’s Metronome is a prime example of this type of collector.
2.       The amount of work required to implement an efficient garbage collection environment within a new language is not only enormous, but often requires the involvement of researchers who focus on this particular area of software development (and aren’t particularly common). The “easy” to implement collectors are frequently much slower than the better algorithms, resulting in the unfortunately common situation where garbage collectors get a bad name. In particular, when a garbage collector is first introduced to a new environment, users observe poor performance compared to the manually-managed environment in which they previously worked, but they do not realize that this deficit is due to the particular garbage collector which was added and not an overall characteristic of all garbage collectors.
a.       One of the best ways for young garbage-collected languages to be fairly evaluated for new language features is to write a compiler that targets the bytecode of an existing runtime system that includes a high-performance garbage collector. The most well supported options are the CLI (.NET) and the JVM (Java). For better or worse, larger projects with better funding (such as Go) tend to have an easier time avoiding this path.
 
Thanks,
Sam
 
From:golang-nuts-/***@public.gmane.org [mailto:golang-nuts-/***@public.gmane.org] On Behalf Of Archos
Sent: Thursday, July 17, 2014 3:52 AM
To: golang-nuts-/***@public.gmane.org
Subject: [go-nuts] Go 2.0 without garbage collector?
 
Does the Go team has thinked into a next version without the garbage collector?

Go is very cool to use but I need the best possible performance since I've not deep pockets like Google. When you are small, you need try to minimize the cost of the servers.
And Rust does a great balance between a language of high level without a significant loss of performance.

I've been translating some Go projects from Go to Rust but the task is very large, especially since every time there are more interesting projects for me.
So, the fastest way for me will be to build a transpiler from Go to Rust. At least there is some intention to have an optional garbage collection.

However, Go is easier to prototype.
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

[Sam Harwell]

Hi Philip,

For this abstract overview, performance is measured in terms of particular applications. I base this on a general observation that for any frequently used metric of performance in an application, specialized garbage collectors have been created which outperform manual allocation/releasing in the same application. Runtime environments which are known to run many different kinds of programs typically use collectors that balance the needs of a wide variety of expected use cases, and within the past few years have done an exceptional job in practice.

“Inefficient memory practices” can manifest in many ways, both direct and indirect. One example of a direct inefficiency involves implementing GC-like features such as reference-counting pointers in C++ to addresses certain memory management concerns, often with great success in very large codebases. The downsides of this include both the use of additional memory for the reference count and the performance impact of manipulating reference counts. While “best practices”<http://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/> for these pointers (e.g. passing by const reference to avoid incrementing/decrementing the count) serve to reduce the performance impact, you will never reach the performance offered by GC-backed reference counting solutions such as Ulterior Reference Counting<http://grothoff.org/christian/teaching/2007/4705/urc-oopsla-2003.pdf>. An indirect efficiency might be that time spent resolving memory allocation issues may leave developers with less available time during the development cycle to address higher-level concerns such as algorithms and communication layers within the software. Performance frequently suffers in these areas regardless of the memory management system in use, so keeping developer resources available to focus on them can be very valuable.

Thanks,
Sam

From: Philip O'Toole [mailto:philip.otoole-/***@public.gmane.org]
Sent: Wednesday, July 23, 2014 11:45 PM
To: Sam Harwell; Archos; golang-nuts-/***@public.gmane.org
Subject: Re: [go-nuts] Go 2.0 without garbage collector?

Sam -- interesting statements. In your opening paragraph, what do you mean by "performance"? You're talking about sheer througput of, say, a program moving data through RAM?

And can you give an example of what you mean by "inefficient memory practices"? I've seen plenty of inefficent memory practices in garbage-collected languagues (notably Java, running in a modern HotSpot JVM) that negate the theoretical advantage offered by automatic management. :-)

(FWIW, I don't have a strong opinion about GC, or lack thereof. I am using Go because it, so far, makes writing system software pretty nice).

Philip

-----------------------------------------
http://www.philipotoole.com

On Wednesday, July 23, 2014 9:12 PM, Sam Harwell <sam-8CAjhppLBTbEP2vymgFrBlaTQe2KTcn/@public.gmane.org<mailto:sam-8CAjhppLBTbEP2vymgFrBlaTQe2KTcn/@public.gmane.org>> wrote:

The best possible performance actually comes from using a Garbage Collector for memory management in all but one case. That specific case is writing an application which needs to run in as little memory as possible, regardless of the performance impact of that decision. As we all know, that situation virtually never arises in modern programming. Also note that this situation generally does not apply to large programs, because the coding complexity of manual memory management throughout a large codebase results in inefficient memory practices that negate the theoretical advantage offered by manual management.

However, the following caveats do hold:

1. For a particular application (algorithm and/or memory usage characteristics), some garbage collector will outperform the available manually-managed allocators for that application. However, there is no garbage collector which performs best for all applications. The best production garbage collectors generally fall into three categories according to the anticipated majority of applications which will run within the environment:
a. High-throughput collectors which target applications with exceptionally large memory spaces, and often allocate objects at higher rates than seen in other applications. These could be called “server” collectors (not to be confused with the -server command line option in the JVM).
b. Concurrent, low-latency collectors which balance throughput with pauses and are widely applicable to “client” applications. By overall usage, these are currently the most commonly used garbage collectors, and are the foundations of both the current .NET Framework collector and the JVM.
c. Real-time garbage collectors which provide hard guarantees regarding the duration of a pause. These collectors are used in specialized applications where a long GC pause poses a physical threat (e.g. system control software for aviation). IBM’s Metronome is a prime example of this type of collector.
2. The amount of work required to implement an efficient garbage collection environment within a new language is not only enormous, but often requires the involvement of researchers who focus on this particular area of software development (and aren’t particularly common). The “easy” to implement collectors are frequently much slower than the better algorithms, resulting in the unfortunately common situation where garbage collectors get a bad name. In particular, when a garbage collector is first introduced to a new environment, users observe poor performance compared to the manually-managed environment in which they previously worked, but they do not realize that this deficit is due to the particular garbage collector which was added and not an overall characteristic of all garbage collectors.
a. One of the best ways for young garbage-collected languages to be fairly evaluated for new language features is to write a compiler that targets the bytecode of an existing runtime system that includes a high-performance garbage collector. The most well supported options are the CLI (.NET) and the JVM (Java). For better or worse, larger projects with better funding (such as Go) tend to have an easier time avoiding this path.

Thanks,
Sam

From: golang-nuts-/***@public.gmane.org<mailto:golang-nuts-/***@public.gmane.org> [mailto:golang-nuts-/***@public.gmane.org] On Behalf Of Archos
Sent: Thursday, July 17, 2014 3:52 AM
To: golang-nuts-/***@public.gmane.org<mailto:golang-nuts-/***@public.gmane.org>
Subject: [go-nuts] Go 2.0 without garbage collector?

Does the Go team has thinked into a next version without the garbage collector?

Go is very cool to use but I need the best possible performance since I've not deep pockets like Google. When you are small, you need try to minimize the cost of the servers.
And Rust does a great balance between a language of high level without a significant loss of performance.

I've been translating some Go projects from Go to Rust but the task is very large, especially since every time there are more interesting projects for me.
So, the fastest way for me will be to build a transpiler from Go to Rust. At least there is some intention to have an optional garbage collection.

However, Go is easier to prototype.
--
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+unsubscribe-/***@public.gmane.org<mailto:golang-nuts+unsubscribe-/***@public.gmane.org>.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe-/***@public.gmane.org<mailto:golang-nuts+unsubscribe-/***@public.gmane.org>.
For more options, visit https://groups.google.com/d/optout.

['Philip O'Toole' via golang-nuts]

Good stuff - thanks for the extra detail and the references. I have spent plenty of time coding with shared pointers in C++, so the whitepaper should be interesting.

Philip

Post by Sam Harwell
Hi Philip,
For this abstract overview, performance is measured in terms of particular applications. I base this on a general observation that for any frequently used metric of performance in an application, specialized garbage collectors have been created which outperform manual allocation/releasing in the same application. Runtime environments which are known to run many different kinds of programs typically use collectors that balance the needs of a wide variety of expected use cases, and within the past few years have done an exceptional job in practice.
“Inefficient memory practices” can manifest in many ways, both direct and indirect. One example of a direct inefficiency involves implementing GC-like features such as reference-counting pointers in C++ to addresses certain memory management concerns, often with great success in very large codebases. The downsides of this include both the use of additional memory for the reference count and the performance impact of manipulating reference counts. While “best practices” for these pointers (e.g. passing by const reference to avoid incrementing/decrementing the count) serve to reduce the performance impact, you will never reach the performance offered by GC-backed reference counting solutions such as Ulterior Reference Counting. An indirect efficiency might be that time spent resolving memory allocation issues may leave developers with less available time during the development cycle to address higher-level concerns such as algorithms and communication layers within the software. Performance frequently suffers in these areas regardless of the memory management system in use, so keeping developer resources available to focus on them can be very valuable.
Thanks,
Sam
Sent: Wednesday, July 23, 2014 11:45 PM
Subject: Re: [go-nuts] Go 2.0 without garbage collector?
Sam -- interesting statements. In your opening paragraph, what do you mean by "performance"? You're talking about sheer througput of, say, a program moving data through RAM?
And can you give an example of what you mean by "inefficient memory practices"? I've seen plenty of inefficent memory practices in garbage-collected languagues (notably Java, running in a modern HotSpot JVM) that negate the theoretical advantage offered by automatic management. :-)
(FWIW, I don't have a strong opinion about GC, or lack thereof. I am using Go because it, so far, makes writing system software pretty nice).
Philip
-----------------------------------------
http://www.philipotoole.com
The best possible performance actually comes from using a Garbage Collector for memory management in all but one case. That specific case is writing an application which needs to run in as little memory as possible, regardless of the performance impact of that decision. As we all know, that situation virtually never arises in modern programming. Also note that this situation generally does not apply to large programs, because the coding complexity of manual memory management throughout a large codebase results in inefficient memory practices that negate the theoretical advantage offered by manual management.
a. High-throughput collectors which target applications with exceptionally large memory spaces, and often allocate objects at higher rates than seen in other applications. These could be called “server” collectors (not to be confused with the -server command line option in the JVM).
b. Concurrent, low-latency collectors which balance throughput with pauses and are widely applicable to “client” applications. By overall usage, these are currently the most commonly used garbage collectors, and are the foundations of both the current .NET Framework collector and the JVM.
c. Real-time garbage collectors which provide hard guarantees regarding the duration of a pause. These collectors are used in specialized applications where a long GC pause poses a physical threat (e.g. system control software for aviation). IBM’s Metronome is a prime example of this type of collector.
2. The amount of work required to implement an efficient garbage collection environment within a new language is not only enormous, but often requires the involvement of researchers who focus on this particular area of software development (and aren’t particularly common). The “easy” to implement collectors are frequently much slower than the better algorithms, resulting in the unfortunately common situation where garbage collectors get a bad name. In particular, when a garbage collector is first introduced to a new environment, users observe poor performance compared to the manually-managed environment in which they previously worked, but they do not realize that this deficit is due to the particular garbage collector which was added and not an overall characteristic of all garbage collectors.
a. One of the best ways for young garbage-collected languages to be fairly evaluated for new language features is to write a compiler that targets the bytecode of an existing runtime system that includes a high-performance garbage collector. The most well supported options are the CLI (.NET) and the JVM (Java). For better or worse, larger projects with better funding (such as Go) tend to have an easier time avoiding this path.
Thanks,
Sam
Sent: Thursday, July 17, 2014 3:52 AM
Subject: [go-nuts] Go 2.0 without garbage collector?
Does the Go team has thinked into a next version without the garbage collector?
Go is very cool to use but I need the best possible performance since I've not deep pockets like Google. When you are small, you need try to minimize the cost of the servers.
And Rust does a great balance between a language of high level without a significant loss of performance.
I've been translating some Go projects from Go to Rust but the task is very large, especially since every time there are more interesting projects for me.
So, the fastest way for me will be to build a transpiler from Go to Rust. At least there is some intention to have an optional garbage collection.
However, Go is easier to prototype.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
For more options, visit https://groups.google.com/d/optout.

[Nicolas Grilly]

Hi Sam,

Your detailed comment about garbage collection versus manual management of
memory is really interesting.

I'm curious to know what you think of Rust emphasis on making garbage
collection optional (FAQ says "Rust is usable on bare metal with no extra
runtime"), and letting the programmer manage object ownership explicitly?

Their approach gives a lot of power to the programmer but also makes the
language more complex, in my opinion. Is it worth it in terms of improved
performance?

Post by Sam Harwell
For this abstract overview, performance is measured in terms of
particular applications. I base this on a general observation that for any
frequently used metric of performance in an application, specialized
garbage collectors have been created which outperform manual
allocation/releasing in the same application. Runtime environments which
are known to run many different kinds of programs typically use collectors
that balance the needs of a wide variety of expected use cases, and within
the past few years have done an exceptional job in practice.
“Inefficient memory practices” can manifest in many ways, both direct and
indirect. One example of a direct inefficiency involves implementing
GC-like features such as reference-counting pointers in C++ to addresses
certain memory management concerns, often with great success in very large
codebases. The downsides of this include both the use of additional memory
for the reference count and the performance impact of manipulating
reference counts. While “best practices”
<http://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/>
for these pointers (e.g. passing by const reference to avoid
incrementing/decrementing the count) serve to reduce the performance
impact, you will never reach the performance offered by GC-backed reference
counting solutions such as Ulterior Reference Counting
<http://grothoff.org/christian/teaching/2007/4705/urc-oopsla-2003.pdf>.
An indirect efficiency might be that time spent resolving memory allocation
issues may leave developers with less available time during the development
cycle to address higher-level concerns such as algorithms and communication
layers within the software. Performance frequently suffers in these areas
regardless of the memory management system in use, so keeping developer
resources available to focus on them can be very valuable.

[Sam Harwell]

Hi Nicolas,

Every “usable” language provides a standard runtime library of some form. Such a library could easily be considered an “extra runtime”, on the definition that an “extra runtime” provides necessary supporting features which were not directly implemented as part of the running application. The only difference between a garbage collector implementation and a standard runtime library is whether the features are implicitly or explicitly invoked.

Garbage collectors have two primary purposes:


1. Accurately reclaim memory, typically measured as a bounded approximation over liveness.

2. Meet or exceed the performance of manual memory management strategies.

In reality, the first item is very easy to implement using simple, proven strategies. Mark-sweep garbage collectors have existed since (at least) 1967, and copying collectors since at least 1978. The second item, on the other hand, is extraordinarily difficult, with substantial contributions being made even in the last 5 years. Addressing the second point frequently leads to questions about the ongoing correctness of the collector (i.e., attempting to meet item #2 can easily cause bugs where it no longer meets item #1). For young languages which do not execute within a well-known virtual machine and include garbage collection as part of the language specification, limiting the implementation to just the first point allows for developers to focus on other critical aspects of the language.

As a case-in-point, the Mono project used a relatively slow off-the-shelf garbage collector (boehm-gc) from 2002 all the way until late 2009. It wasn’t until February 2011 that the performance-enhanced collector finally shipped in Mono 2.10. For other languages which haven’t reached this point and have facilities in the language specification to support manual memory management, it could make sense to provide garbage collection as an optional feature. I don’t personally support such a decision, but I understand both the motivation that leads to it and recognize the potential for it to improve near-term benchmarks for young languages prior to the introduction of high-performance garbage collection.

Rather than resort to this strategy, I typically encourage language developers to initially compile to the bytecode of an existing virtual machine which already offers high-performance garbage collection. An obvious added benefit is these runtime environments typically have well-established support for features like reliable debugging, profiling, and extensive runtime memory analysis. Language developers must evaluate these advantages in the context of their expected audience and the types of applications they intend to support.

Thanks,
Sam

From: golang-nuts-/***@public.gmane.org [mailto:golang-nuts-/***@public.gmane.org] On Behalf Of Nicolas Grilly
Sent: Thursday, July 24, 2014 8:36 AM
To: Sam Harwell
Cc: Philip O'Toole; Archos; golang-nuts-/***@public.gmane.org
Subject: Re: [go-nuts] Go 2.0 without garbage collector?

Hi Sam,

Your detailed comment about garbage collection versus manual management of memory is really interesting.

I'm curious to know what you think of Rust emphasis on making garbage collection optional (FAQ says "Rust is usable on bare metal with no extra runtime"), and letting the programmer manage object ownership explicitly?

Their approach gives a lot of power to the programmer but also makes the language more complex, in my opinion. Is it worth it in terms of improved performance?

On Thu, Jul 24, 2014 at 7:27 AM, Sam Harwell <sam-8CAjhppLBTbEP2vymgFrBlaTQe2KTcn/@public.gmane.org<mailto:sam-8CAjhppLBTbEP2vymgFrBlaTQe2KTcn/@public.gmane.org>> wrote:
For this abstract overview, performance is measured in terms of particular applications. I base this on a general observation that for any frequently used metric of performance in an application, specialized garbage collectors have been created which outperform manual allocation/releasing in the same application. Runtime environments which are known to run many different kinds of programs typically use collectors that balance the needs of a wide variety of expected use cases, and within the past few years have done an exceptional job in practice.

“Inefficient memory practices” can manifest in many ways, both direct and indirect. One example of a direct inefficiency involves implementing GC-like features such as reference-counting pointers in C++ to addresses certain memory management concerns, often with great success in very large codebases. The downsides of this include both the use of additional memory for the reference count and the performance impact of manipulating reference counts. While “best practices”<http://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/> for these pointers (e.g. passing by const reference to avoid incrementing/decrementing the count) serve to reduce the performance impact, you will never reach the performance offered by GC-backed reference counting solutions such as Ulterior Reference Counting<http://grothoff.org/christian/teaching/2007/4705/urc-oopsla-2003.pdf>. An indirect efficiency might be that time spent resolving memory allocation issues may leave developers with less available time during the development cycle to address higher-level concerns such as algorithms and communication layers within the software. Performance frequently suffers in these areas regardless of the memory management system in use, so keeping developer resources available to focus on them can be very valuable.


--
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+unsubscribe-/***@public.gmane.org<mailto:golang-nuts+unsubscribe-/***@public.gmane.org>.
For more options, visit https://groups.google.com/d/optout.

[Nicolas Grilly]

Thank you Sam. That's a really interesting take on the subject. Do you have
any link to some papers supporting this point of view?

Post by Sam Harwell
Every “usable” language provides a standard runtime library of some
form. Such a library could easily be considered an “extra runtime”, on the
definition that an “extra runtime” provides necessary supporting features
which were not directly implemented as part of the running application. The
only difference between a garbage collector implementation and a standard
runtime library is whether the features are implicitly or explicitly
invoked.
1. Accurately reclaim memory, typically measured as a bounded
approximation over liveness.
2. Meet or exceed the performance of manual memory management strategies.
In reality, the first item is very easy to implement using simple, proven
strategies. Mark-sweep garbage collectors have existed since (at least)
1967, and copying collectors since at least 1978. The second item, on the
other hand, is extraordinarily difficult, with substantial contributions
being made even in the last 5 years. Addressing the second point frequently
leads to questions about the ongoing correctness of the collector (i.e.,
attempting to meet item #2 can easily cause bugs where it no longer meets
item #1). For young languages which do not execute within a well-known
virtual machine and include garbage collection as part of the language
specification, limiting the implementation to just the first point allows
for developers to focus on other critical aspects of the language.
As a case-in-point, the Mono project used a relatively slow off-the-shelf
garbage collector (boehm-gc) from 2002 all the way until late 2009. It
wasn’t until February 2011 that the performance-enhanced collector finally
shipped in Mono 2.10. For other languages which haven’t reached this point
and have facilities in the language specification to support manual memory
management, it could make sense to provide garbage collection as an
optional feature. I don’t personally support such a decision, but I
understand both the motivation that leads to it and recognize the potential
for it to improve near-term benchmarks for young languages prior to the
introduction of high-performance garbage collection.
Rather than resort to this strategy, I typically encourage language
developers to initially compile to the bytecode of an existing virtual
machine which already offers high-performance garbage collection. An
obvious added benefit is these runtime environments typically have
well-established support for features like reliable debugging, profiling,
and extensive runtime memory analysis. Language developers must evaluate
these advantages in the context of their expected audience and the types of
applications they intend to support.

[Sam Harwell]

One of my favorites is Daniel Frampton’s doctoral dissertation, which is very well-written and very thorough.
Garbage Collection and the Case for High-level Low-level Programming<http://cs.anu.edu.au/~Daniel.Frampton/DanielFrampton_Thesis_Jun2010.pdf>

If you really have some time to spend on the subject, here’s the reading list from a course I took on Memory Management.
http://www.cs.utexas.edu/users/mckinley/395Tmm/schedule.html

The work on Jikes RVM eventually prompted me to build a bootstrapping all-managed virtual machine based on ECMA-335 (though it was never released). Between having to get a “real job” and shifting my research emphasis to high-performance parsing for IDEs (e.g. GoWorks<https://github.com/tunnelvisionlabs/goworks>), I haven’t had the time available to complete this project. I do have a public repository containing my C# port of AsmJit<https://github.com/kobalicek/asmjit>, which I used for the x86 and x64 code generation.
https://github.com/tunnelvisionlabs/nasmjit

Sam

From: golang-nuts-/***@public.gmane.org [mailto:golang-nuts-/***@public.gmane.org] On Behalf Of Nicolas Grilly
Sent: Friday, July 25, 2014 5:21 AM
To: golang-nuts-/***@public.gmane.org
Cc: nicolas-oFx+hxT/***@public.gmane.org; philip.otoole-/***@public.gmane.org; raul.san-***@public.gmane.org
Subject: Re: [go-nuts] Go 2.0 without garbage collector?

Thank you Sam. That's a really interesting take on the subject. Do you have any link to some papers supporting this point of view?

On Friday, July 25, 2014 3:20:18 AM UTC+2, Sam Harwell wrote:
Every “usable” language provides a standard runtime library of some form. Such a library could easily be considered an “extra runtime”, on the definition that an “extra runtime” provides necessary supporting features which were not directly implemented as part of the running application. The only difference between a garbage collector implementation and a standard runtime library is whether the features are implicitly or explicitly invoked.
Garbage collectors have two primary purposes:

1. Accurately reclaim memory, typically measured as a bounded approximation over liveness.

2. Meet or exceed the performance of manual memory management strategies.
In reality, the first item is very easy to implement using simple, proven strategies. Mark-sweep garbage collectors have existed since (at least) 1967, and copying collectors since at least 1978. The second item, on the other hand, is extraordinarily difficult, with substantial contributions being made even in the last 5 years. Addressing the second point frequently leads to questions about the ongoing correctness of the collector (i.e., attempting to meet item #2 can easily cause bugs where it no longer meets item #1). For young languages which do not execute within a well-known virtual machine and include garbage collection as part of the language specification, limiting the implementation to just the first point allows for developers to focus on other critical aspects of the language.
As a case-in-point, the Mono project used a relatively slow off-the-shelf garbage collector (boehm-gc) from 2002 all the way until late 2009. It wasn’t until February 2011 that the performance-enhanced collector finally shipped in Mono 2.10. For other languages which haven’t reached this point and have facilities in the language specification to support manual memory management, it could make sense to provide garbage collection as an optional feature. I don’t personally support such a decision, but I understand both the motivation that leads to it and recognize the potential for it to improve near-term benchmarks for young languages prior to the introduction of high-performance garbage collection.
Rather than resort to this strategy, I typically encourage language developers to initially compile to the bytecode of an existing virtual machine which already offers high-performance garbage collection. An obvious added benefit is these runtime environments typically have well-established support for features like reliable debugging, profiling, and extensive runtime memory analysis. Language developers must evaluate these advantages in the context of their expected audience and the types of applications they intend to support.

--
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+unsubscribe-/***@public.gmane.org<mailto:golang-nuts+unsubscribe-/***@public.gmane.org>.
For more options, visit https://groups.google.com/d/optout.

[Nicolas Grilly]

Sam,

A big thank you for the links!

One of the papers, "Myths and Realities: The Performance Impact of Gargabe
Collection", has a paragraph that offers a good summary:

*Is garbage collection a good idea?*

The software engineering benefits of garbage collection over explicit
memory management are widely accepted, but the performance trade-off in
languages designed for garbage collection is unexplored. Section 5.3 shows
a clear mutator performance advantage for contiguous over free-list
allocation, and the architectural comparison shows that architectural
trends should make this advantage more pronounced. The traditional explicit
memory management use of malloc() and free() is tightly coupled to the use
of a free-list allocator—in fact the MMTk free-list allocator implemen-
tation is based on Lea allocator, which is the default allocator in
standard C libraries. Standard explicit memory management is thus unable to
exploit the locality advantages of contiguous allocation. It is therefore
possible that garbage collection presents a performance advantage over
explicit memory management on current or future architectures.

Post by Sam Harwell
One of my favorites is Daniel Frampton’s doctoral dissertation, which is
very well-written and very thorough.
Garbage Collection and the Case for High-level Low-level Programming
<http://cs.anu.edu.au/~Daniel.Frampton/DanielFrampton_Thesis_Jun2010.pdf>
If you *really* have some time to spend on the subject, here’s the
reading list from a course I took on Memory Management.
http://www.cs.utexas.edu/users/mckinley/395Tmm/schedule.html
The work on Jikes RVM eventually prompted me to build a bootstrapping
all-managed virtual machine based on ECMA-335 (though it was never
released). Between having to get a “real job” and shifting my research
emphasis to high-performance parsing for IDEs (e.g. GoWorks
<https://github.com/tunnelvisionlabs/goworks>), I haven’t had the time
available to complete this project. I do have a public repository
containing my C# port of AsmJit <https://github.com/kobalicek/asmjit>,
which I used for the x86 and x64 code generation.
https://github.com/tunnelvisionlabs/nasmjit

['Dmitry Vyukov' via golang-nuts]

You can also see some other reasons why GC can be faster that I outlined above:
https://groups.google.com/d/msg/Golang-nuts/rvFasvA3usk/FvwRBeFAtl0J


On Fri, Jul 25, 2014 at 5:49 PM, Nicolas Grilly

Post by Nicolas Grilly
Sam,
A big thank you for the links!
One of the papers, "Myths and Realities: The Performance Impact of Gargabe
Is garbage collection a good idea?
The software engineering benefits of garbage collection over explicit memory
management are widely accepted, but the performance trade-off in languages
designed for garbage collection is unexplored. Section 5.3 shows a clear
mutator performance advantage for contiguous over free-list allocation, and
the architectural comparison shows that architectural trends should make
this advantage more pronounced. The traditional explicit memory management
use of malloc() and free() is tightly coupled to the use of a free-list
allocator—in fact the MMTk free-list allocator implemen- tation is based on
Lea allocator, which is the default allocator in standard C libraries.
Standard explicit memory management is thus unable to exploit the locality
advantages of contiguous allocation. It is therefore possible that garbage
collection presents a performance advantage over explicit memory management
on current or future architectures.

One of my favorites is Daniel Frampton’s doctoral dissertation, which is
very well-written and very thorough.
Garbage Collection and the Case for High-level Low-level Programming
If you really have some time to spend on the subject, here’s the reading
list from a course I took on Memory Management.
http://www.cs.utexas.edu/users/mckinley/395Tmm/schedule.html
The work on Jikes RVM eventually prompted me to build a bootstrapping
all-managed virtual machine based on ECMA-335 (though it was never
released). Between having to get a “real job” and shifting my research
emphasis to high-performance parsing for IDEs (e.g. GoWorks), I haven’t had
the time available to complete this project. I do have a public repository
containing my C# port of AsmJit, which I used for the x86 and x64 code
generation.
https://github.com/tunnelvisionlabs/nasmjit

--
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
For more options, visit https://groups.google.com/d/optout.

[Nicolas Grilly]

Post by 'Dmitry Vyukov' via golang-nuts
https://groups.google.com/d/msg/Golang-nuts/rvFasvA3usk/FvwRBeFAtl0J

Hi Dmitry,

I had already read your message a few days ago, but thanks for the link :)

Some people are spreading FUD about garbage collection, using this as an
argument to promote languages like Rust, where GC is optional, and
disqualify Go. This is the reason why I try to educate myself about the
**real** advantages and shortcomings of GC.

Maybe the FAQ could be updated with an additional paragraph citing why GC
can be **faster**, and why manual memory management can be slower.

http://golang.org/doc/faq#garbage_collection

[Henrik Johansson]

Ye GC can be faster than manual memory management there is no denying that
but the Java world has been touting that as a mantra forever and now they
are moving towards "off heap" solutions and similar things anyway.

GC is definitely worth it and has not necessarily any negative impact but
still, as of today, it is almost always more performant without it.

Post by Nicolas Grilly

Post by 'Dmitry Vyukov' via golang-nuts
https://groups.google.com/d/msg/Golang-nuts/rvFasvA3usk/FvwRBeFAtl0J

Hi Dmitry,
I had already read your message a few days ago, but thanks for the link :)
Some people are spreading FUD about garbage collection, using this as an
argument to promote languages like Rust, where GC is optional, and
disqualify Go. This is the reason why I try to educate myself about the
**real** advantages and shortcomings of GC.
Maybe the FAQ could be updated with an additional paragraph citing why GC
can be **faster**, and why manual memory management can be slower.
http://golang.org/doc/faq#garbage_collection
--
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
For more options, visit https://groups.google.com/d/optout.

[Archos]

Post by Nicolas Grilly
Some people are spreading FUD about garbage collection, using this as an
argument to promote languages like Rust, where GC is optional, and
disqualify Go. This is the reason why I try to educate myself about the
**real** advantages and shortcomings of GC.

Some people are fan-boys/girls of a language and they think that a language
can be used for whatever task.

If Rust was designed to build a browser engine is because its original
author wanted a easier and safer low level language than C/C++. If you,
using Go, can build an engile browser like Firefox, or a kernel, it's good
for you, but I would never use those programs in my systems. That you can
use a language to build something, it does not mean that it can be usable
or that the performance can be acceptable for everybody; as an example, you
have the desktop programs built in Java.

Whether Rust has attracted to professional developers from gaming industry
has been due to very good reasons. It is not a coincidence that there are
so many projects related to games being built in Rust and any other related
to kernels.

By the another side, also Rust have their fan-boys which want to use Rust
to build web services. But the reality is that Go is the language that lets
you build a service faster out of the box.
Now well, if any part of the infrastructure of my system needs a better
performance (after of profiling) then I do not hesitate in to use Rust to
get a better performance simply because I'm not a fan-boy of a language
neither of a company, instead I'll use the best tool to get the task done.

[andrey mirtchovski]

Post by Archos
Now well, if any part of the infrastructure of my system needs a better
performance (after of profiling) then I do not hesitate in to use Rust to
get a better performance simply because I'm not a fan-boy of a language
neither of a company, instead I'll use the best tool to get the task done.

then why did you ask the original question in the first place?

[Archos]

Post by andrey mirtchovski

Post by Archos
Now well, if any part of the infrastructure of my system needs a better
performance (after of profiling) then I do not hesitate in to use Rust

to

Post by Archos
get a better performance simply because I'm not a fan-boy of a language
neither of a company, instead I'll use the best tool to get the task

done.
then why did you ask the original question in the first place?

You have just the answer in the original question.

[Gerard]

On Friday, July 25, 2014 6:51:30 PM UTC+2, Archos wrote:

<snip>

If you, using Go, can build an engile browser like Firefox, or a kernel,

it's good for you, but I would never use those programs in my systems.

The browsers of today are written in C or C++ AFAIK. In what sense is that
any "better" than Go?

[a***@public.gmane.org]

Post by Archos
Whether Rust has attracted to professional developers from gaming industry
has been due to very good reasons. It is not a coincidence that there are
so many projects related to games being built in Rust and any other
related to kernels.

Speaking of games, I think that those currently attracted to Rust aren't
professionals from the "game industry" (not even indies), but mostly
hobbyists writing their "engines" for fun.

[b***@public.gmane.org]

I love Rust but it is unstable. I am sick and tired of changing my Rust
programs in order to compile after each version.
So I am waiting 1.0 .
Go is much simpler than Rust and therefore easier to program, so I am
experimenting now with Go and am quite
satisfied. However performance is not strong point of Go, and it is not
just because of GC.

Does the Go team has thinked into a next version without the garbage
collector?
Go is very cool to use but I need the best possible performance since I've
not deep pockets like Google. When you are small, you need try to minimize
the cost of the servers.
And Rust does a great balance between a language of high level without a
significant loss of performance.
I've been translating some Go projects from Go to Rust but the task is very
large, especially since every time there are more interesting projects
for me.
So, the fastest way for me will be to build a transpiler from Go to Rust.
At least there is some intention to have an optional garbage collection.
However, Go is easier to prototype.

[Dave Cheney]

Post by b***@public.gmane.org
I love Rust but it is unstable. I am sick and tired of changing my Rust
programs in order to compile after each version.
So I am waiting 1.0 .
Go is much simpler than Rust and therefore easier to program, so I am
experimenting now with Go and am quite
satisfied. However performance is not strong point of Go, and it is not
just because of GC.

Them's fighting words, Citation Needed, please.

Post by b***@public.gmane.org

Does the Go team has thinked into a next version without the garbage
collector?
Go is very cool to use but I need the best possible performance since
I've not deep pockets like Google. When you are small, you need try to
minimize the cost of the servers.
And Rust does a great balance between a language of high level without a
significant loss of performance.
I've been translating some Go projects from Go to Rust but the task is very
large, especially since every time there are more interesting projects
for me.
So, the fastest way for me will be to build a transpiler from Go to Rust.
At least there is some intention to have an optional garbage collection.
However, Go is easier to prototype.

[b***@public.gmane.org]

Post by Dave Cheney

Post by b***@public.gmane.org
I love Rust but it is unstable. I am sick and tired of changing my Rust
programs in order to compile after each version.
So I am waiting 1.0 .
Go is much simpler than Rust and therefore easier to program, so I am
experimenting now with Go and am quite
satisfied. However performance is not strong point of Go, and it is not
just because of GC.

Them's fighting words, Citation Needed, please.

That's my opinion based on my experience.

[Jonathan Barnard]

I think most of the performance problems people post on this board seem to
come from overusing hashmaps. If you treat Go as C with channels and
slices, it generally performs quite well.

Post by b***@public.gmane.org

Post by Dave Cheney

Post by b***@public.gmane.org
I love Rust but it is unstable. I am sick and tired of changing my Rust
programs in order to compile after each version.
So I am waiting 1.0 .
Go is much simpler than Rust and therefore easier to program, so I am
experimenting now with Go and am quite
satisfied. However performance is not strong point of Go, and it is not
just because of GC.

Them's fighting words, Citation Needed, please.

That's my opinion based on my experience.
--
You received this message because you are subscribed to a topic in the
Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/golang-nuts/rvFasvA3usk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[b***@public.gmane.org]

Post by Jonathan Barnard
I think most of the performance problems people post on this board seem to
come from overusing hashmaps. If you treat Go as C with channels and
slices, it generally performs quite well.

I don't have performance problems with Go, I just notice that it is slower
than C/C++. There is no auto vectorization and sometimes generated code is
subpar
when compared to C/C++. But there are gccgo and 6/8g. Sometimes gccgo
performs better, sometimes 6/8g . gccgo seems better at function calls
through interfaces and abstract code, but 6/8g seems better with arrays.
All in all performance is not bad but is subpar in comparison to C++.
Let's compare three simple programs:

package main
import (
"fmt"
"time"
)

const N = 500000000
func init_cumul(a []int64) {
for k := 0; k<len(a);k++ {
a[k] = int64(k/3+k)
}
}

func cumul(a []int64) {
var sum int64
for i := range a {
a[i] += sum
sum = a[i]
}
}


func main() {
var array [] int64 = make([]int64,N)
for i := 0;i<10;i++ {
start := time.Now()
init_cumul(array)
end := time.Since(start)
fmt.Printf("%f\n",float64(N*1000)/float64(end.Nanoseconds()))
start = time.Now()
cumul(array)
end = time.Since(start)
fmt.Printf("%f\n",float64(N*1000)/float64(end.Nanoseconds()))
}
fmt.Printf("%d\n",array[N-1])
}

gccgo:
273.403325
1202.290122
880.824452
1198.635473
896.225992
1201.429220
886.751227
1189.385920
895.564627
1200.140176
897.002576
1197.966332
892.188002
1206.825807
895.226295
1196.813603
892.334490
1199.296732
895.304842
1197.125940
166666666166666667

6g:
263.543236
501.597159
804.681819
512.730177
803.912885
517.131290
798.258510
515.190764
801.201592
515.878526
803.515553
514.060331
797.765770
517.076759
797.631910
518.080521
801.722531
518.507745
796.869586
518.152138
166666666166666667

java:
public class Cumul {

public static void sum(long[] data) {
if(data.length == 0) return;
for( int i = 1; i != data.length; ++i)
data[i] += data[i-1];
}



public static long[] givemeanarray(int N) {
long[] bigarray = new long[N];
for(int k = 0; k<N; ++k)
bigarray[k] = k+k/3;
return bigarray;
}

public static void test(int N) {
for (int i=0;i<10;++i)
{
long bef = System.currentTimeMillis();
long[] data = givemeanarray(N);
long aft = System.currentTimeMillis();
System.out.println(N/(1000.0 * (aft-bef)));
bef = System.currentTimeMillis();
sum(data);
aft = System.currentTimeMillis();
System.out.println(N/(1000.0 * (aft-bef)));
System.out.println(data[N-1]);
}
}

public static void main(String[] args) {
test( 500 * 1000 * 1000 );
}


}

268.3843263553409
1312.3359580052493
166666666166666667
247.52475247524754
1312.3359580052493
166666666166666667
259.0673575129534
1315.7894736842106
166666666166666667
262.7430373095113
1308.9005235602094
166666666166666667
259.0673575129534
1302.0833333333333
166666666166666667
261.3695765812859
1315.7894736842106
166666666166666667
263.43519494204423
1305.4830287206266
166666666166666667
265.3927813163482
1322.7513227513227
166666666166666667
263.5740643120717
1319.2612137203166
166666666166666667
263.99155227032736
1322.7513227513227
166666666166666667

C++:
#include <stdio.h>

const int N=500000000;
long array[N];
unsigned long elapsed=0;

void init_cumul()
{
for(int k=0;k<N;k++)
array[k]=k/3+k;
}

void cumul()
{
long sum = array[0];
for(int k=1;k<N;++k)
{
array[k]+=sum;
sum=array[k];
}
}

void timer_init()
{
unsigned edx,eax;
asm volatile(
"rdtsc \n":"=d"(edx),"=a"(eax)
);
elapsed = ((unsigned long)edx<<32) | eax;
}
void timer()
{
unsigned edx,eax;
asm volatile(
"rdtsc \n":"=d"(edx),"=a"(eax)
);
elapsed = (((unsigned long)edx<<32) | eax) - elapsed ;
printf("%f\n",double(N)/(elapsed/3800.0));
}

int main()
{
for(int i=0;i<10;++i)
{
timer_init();
init_cumul();
timer();
timer_init();
cumul();
timer();
}
printf("%ld\n",array[N-1]);
}

350.401962
1477.418397
1515.326802
1468.208677
1515.674478
1462.651715
1495.352347
1469.423731
1519.040236
1477.555610
1507.452754
1462.954432
1521.180948
1480.971117
1517.591325
1470.561027
1491.424521
1468.494121
1513.532281
1488.670784
166666666166666667

As you can see in this example Go is subpar to C++, but better than Java on
average.