Translation Changes brought by Go tip (2013-08-23)

This is a creation in Article, where the information may have evolved or changed.

Dominik Honnef (previously mistaken for Russ Cox) introduced some changes to the go language in "What's happening in Go Tip" (2013-08-23). These changes include syntax, performance, potential risk, and toolchain. And, these new things may be released with the Go 1.2 release. In order to facilitate the Chinese reader, translation here.

———— Translation Divider Line ————

Changes brought by Go tip (2013-08-23)

Last week I released the first article in a series on the changes to Go tip. Get a lot of affirmation, so this is the second article. Thank you for your support and hope you like this article as much as you like the first article.

What's the change?

This time, the following topics will be explored:

• New syntax for slices
• Performance improvements
• Fast, constant-time P-256 elliptic curve
• Where's Godoc?

New syntax for slices

Related CL:CL 10743046,cl 12931044

First, let's look at some of the most controversial changes that are attached to Go 1.2: The new slice syntax that allows you to set the capacity of slice. But before discussing why it is controversial, let's look at what it is.

Everyone should be familiar with the slicing operation Myslice[i:j], create a new slice from the range I to J. Myslice and the new slice will share the underlying array, and one of the slice operations will affect the other. This is the expected well-known behavior.

But some people may not realize that these two slice also share capacity. A slice has length and capacity; The number of elements currently visible and the number of elements that can be accessed. When using append () ¹, capacity has an important role: when attaching to a slice, first checks whether the underlying array has enough space (capacity). If so, create a new slice with a larger length that points to the same underlying array, the same memory space.

¹: If the capacity permits, you can also manually rebuild the slice and pass the length. That's what append () is doing initially.

Consider the following code snippet:

Orig: = Make ([]int, Ten,] subslice: = orig[5:10]fmt. Printf ("len (orig) =%d, cap (orig) =%d, Len (subslice) =%d, cap (subslice) =%d\n", Len (orig), Cap (orig), Len (subslice), Cap (Subslice)) Output: Len (orig) = ten, Cap (orig) = 5, Len (subslice) = 1, Cap (subslice) = 15orig = Append (orig,) fmt. PRINTLN (orig)//output: [0 0 0 0 0 0 0 0 0 0 1]subslice = append (Subslice, 2) fmt. PRINTLN (orig)//output: [0 0 0 0 0 0 0 0 0 0 2]

This proves that subslice, even if the slice is a window of orig, still accesses the same memory, since the slices cannot be shrunk, so at least in the first 5 elements. It is also shown that the use of append can result in "weird" results, which causes the elements in the original slice to be overwritten.

So why is this a problem in real code? Imagine that when you write your own memory allocator based on []byte]-This is common when there is a lot of small memory allocations that might reduce GC performance. When the user requests n bytes of memory, you return a slice that is sliced from somewhere on []byte, with a length of N. Then the user did something silly: he append it. As we have seen before, this append will "leak" the memory over the length of slice, and also beyond what the memory allocator expects. You've rewritten the rest of the memory!

A safe option is to allow a custom memory allocator to be implemented, but to prevent the memory from being eroded by limiting the capacity of the returned slice so that append does not modify the memory where it should be. And this safe choice is the new slice syntax: The two elements in front of myslice[i:j:k]--are sliced from I to J as before. The third element represents the capacity, where the capacity is the result of k–i.

Simply put, k–i as a capacity means that k–1 can be accessed by the new slice to the absolute sequence number of the underlying array, which is the same length as the ordinal j–1. Having k equals J creates a slice that cannot be accessed backwards beyond its length. You can now write a memory that returns N bytes and does not allow the allocator to be accessed backwards.

In the introduction, I said that this supplement is controversial. You may have guessed the reason: if you continue to think "Why do I need this", you will guess. This feature is rarely used. There are only a few examples to use in a standard library. But this does not mean that this feature should not exist, although it solves an effective problem, but is also questioned that the slice syntax should not be extended. Functions like Setcap () are recommended as a way to avoid adding new syntax to go, but eventually the go team decides to adopt the new slice syntax. If you are interested, there is a discussion about it. Of course, this will be included in Go 1.2.

There are also design documents that describe the original motives and ideas.

Performance improvements and garbage collection

Related CL:CL 11573043,cl 9129044,cl 12894043,cl 8179043,cl 9492044,cl 9432046,cl 8819049,cl 9459044,cl 12603049,cl 12708046,c L 10079043,cl 8670044,cl 12680046,cl 12694048,cl 11874043,cl 12072045,cl 9915043,cl 12662043,cl 9462044

A lot of performance improvements will be seen in Go 1.2. These improvements consist mainly of two categories: better code and a direct performance boost from the compiler, and a reduction in the amount of garbage generated by the memory allocator and the garbage collector's work.

Brad Fitzpatrick has done a lot of work in the Net/http package and related common packages while exploring high-performance HTTP. Most of his changes fall into the category of "waste reduction". Since most of the changes are simple, I'll just list the CL numbers so you can check out the code. All of these include performance tests in the Description section: Cl 9129044 (faster JSON encoding), CL 12894043 (faster ZIP compression), CL 8179043,CL 9492044 and Cl 9432046 (several HTTP improvements).

Anyway, some CL is really interesting. A set of CL is CL 8819049,CL 9459044 and CL 12603049--front two adds buffer pool and buffer reuse for Bufio, and the last one removes the previously mentioned buffer pool and buffer reuse, replacing it with a simple Reset method. The reason for this is that these buffers can be controlled by the user, and may bypass the API to corrupt other users ' data, resulting in errors such as "Use over free," and such errors can be difficult to debug because Go explicitly avoids providing a manual way to free memory. Also, it is a foreshadowing of the additional performance overhead that is caused by unnecessary complex code.

The newly added Reset method is used to achieve similar performance improvements, forcing the user to activate the reuse buffer instead of relying on the package to complete this. Net/http is one of many users, using the Reset implementation in CL 12708046. It is important to note that the performance test is compared to the pooled Bufio, not Go 1.1.

For the original discussion, see Russ Cox submitted by issue 6086.

The last change under Brad's name is CL 10079043, which aggregates several ongoing DNS queries. Or in other words: even if the same DNS query has been executed hundreds of times and is not finished, it actually sends only a real query request to the server.

But not only did Brad do his job, but everyone else contributed a lot of improvements.

One of the things that must be mentioned is CL 8670044, which implements an integrated network pool for Windows, making the network operational performance on the platform 30%--the luxuries that the Go 1.1 has achieved on Linux.

Another must be mentioned is CL 11573043, which greatly improves sync. The speed of the Cond-and completely rejects the memory allocations during processing.

CL 12680046 and CL 12694048 add fast routing to Encoding/binary, which handles integer types of slice, making this common type of processing fast and inexpensive.

DES encryption got five times times faster (though, sadly, it's still very slow), thanks to CL 11874043 and CL 12072045.

The bzip2 is 30% (cl 9915043) faster, while the DNS clients in the net package produce less than 350 bytes of garbage (CL 12662043).

Finally, but not unimportant, Io. Copy now uses Readerfrom's writerto to prioritize, and when the type implements two functions, this can result in significant performance improvements (and in Ioutil. There is little action in the Discard).

Fast, constant-time P-256 elliptic curve

Related CL:CL 10551044

One reader pointed out to me that the P-256 implementation, which added a constant time, was a very interesting change, and the implementation was much faster than the previous one.

Of course the performance is very good, but the real point in the "Constant time": the function for all possible input to spend the same time, which avoids the timing of the attack, a password cracking through the timing information of the way to attack.

Where's Godoc?

Using Go tip always requires you to be more familiar with the development process and ready for damage, erratic behavior, and abrupt changes.

However, not everyone who uses go Tip has time to check the entire development record, especially when told to "try go tip to see if your problem can be solved". For example, a lot of people have recently compiled Go tip after the surprise and confusion, Godoc no longer work, not only no binary files, and some even prompted a bug:

Readtemplate:open/users/rsc/g/go/lib/godoc/codewalk.html:no such file or directory

In both cases, the fix is to run ' go get Code.google.com/p/go.tools/cmd/godoc '--godoc has been moved to the Go.tools child repository.

Future

Call ~ from Go 1.1 has been in the progress of the development, but the end is still very remote. Fortunately, the development of the current Go tip has slowed down and no more interesting changes have been made. And what important things change when, for example, godoc change, we speak in the article mentioned.

The intended reader may have noticed that the previous article promised the support of the shared link. Unfortunately, in order to make room for more important changes, and so that we can better understand the changes in the slice syntax, not mentioned in this article.

What are the plans for next week? More Changes!