http://sitetrans.naver.net/tune.dic?siteUrl=https%3A%2F%2Fwww.infoq.com%2Fnews/2016/08/go-17-released

중에서

 

Go 1.7은 컴파일 시간과 런타임 성능을 크게 개선하고 있다.

또 계층적 테스트와 벤치 마크, Linux on IBM z Systems(s390x)상의 Linux 공식 지원도 추가한다.

 

Go 1.7의 컴파일러 개선은 주로 SSA(정적 단일 대입) 형식에 의거 amd64 플랫폼용 Go의 새로운 컴파일러 백엔드에 관계하고 있다. 새로운 백엔드는 다수의 선진적인 최적화 덕분에 더 작고 고속의 코드를 생성한다.

최적화는 경계 표시 삭제와 공통 식의 삭제가 포함된다.

Google의 벤치 마크에 의하면 런타임은 5– 35% 고속으로 되고, 컴파일 시간과 바이너리 사이즈는 최대 20– 30% 감소된다.

때로는 벤치 마크는 크게 바뀔지도 모르지만 몇몇 Hacker News 사용자는 빌드 속도가 2배 향상하고 있다고 말하고 있다.

 

SSA 백엔드는 amd64 플랫폼만 사용할 수 있다. 하지만 Google의 엔지니어 Brad Fitzpatrick씨에 의하면 지원하는 전 아키텍처로 이식은 Go 1.8의 주요 목표의 하나라고 한다. 그리고 오래 된 백엔드를 삭제하는 것으로 프론트 엔드는 더 간단하게 될 것이라고 한다. 익서은 또 다른 성능 개선을 가져올 것.

2017 2월 릴리스 예정의 Go 1.8에 관한 자세한 것은 GoLang Dev 포럼에서 찾을 수 있다.

 

Go 1.7에서 또 주목해야 하는 변경으로 서브 테스트와 하부 벤치 마크가 있다. 이는 계층적인 테스트나 테이블에 의한 벤치 마크 정의를 가능하게 한다.

-run –bench 플래그의 인수에 슬래시 단락의 정규 표현 리스트를 지정하면 된다.

 

마지막으로 Go 1.7은 표준 라이브러리의 일부로서 context 패키지를 채용했다. 이것은 네트워킹 시의 취소, 타임 아웃, 리퀘스트 범위에 한정한 데이터의 교환을 간단하게 한다. vendor 디렉토리 사용도 표준이 됐다.

이로써 GOPATH이나 표준 라이브러리에서 자동적으로 끌고 오는 대신 개발자는 외부 의존물의 로컬 복사본을 사용하게 된다.

 

Go 1.7의 기능 추가, 개선, 버그 수정에 대한 자세한 설명은 릴리스 노트를 보자.

 

 

저작자 표시
신고
by 흥배 2016.09.27 08:00

Go 1.6

2 17(미국 시간)에 프로그래밍 언어 "Go"의 버전 1.6 이 나왔음.

 

이전 버전 1.5의 발매부터 약 반년 후의 업데이트.

 

주된 기능으로는 우선 net/http 패키지에서 HTTP/2 대응. HTTPS 채용 서버와 클라이언트 쌍방에서 HTTP/2(Hypertext Transfer Protocol Version 2)이 기본적으로 유효하게 되었다.

HTTP/2 2015년 공식 RFC 7540로서 표준화된 통신 프로토콜이다. RFC에 따르면 네트워크 자원의 보다 효율적 이용과 레이턴시 감소.

 

template 패키지가 개선되어 버전 1.5에서 시험적으로 도입된 vendor 디렉토리가 기본적으로 유효하게 되었다. 이 밖에 cgo에서는 Go C의 코드들 사이에서 포인터 교환 규칙이 변경되었다.

변경 내용은 문서에서 확인할 수 있다.

 

 

 

저작자 표시
신고
by 흥배 2016.02.24 08:00

Go 1.6에서는 1.5 버전에 비해서 GC 시간이 대폭 줄어들어서 메모리가 윤택한 환경에서는 GOGC을 default 100 보다 크게 해서 많은 메모리를 사용하도록 해야 많은 코어 수에 맞게 스케일 한다고 한다.


https://github.com/golang/go/issues/14161

저작자 표시
신고
by 흥배 2016.02.16 08:00

https://medium.com/iron-io-blog/an-easier-way-to-create-tiny-golang-docker-images-7ba2893b160

 

2015 7월의 기사

GorillaMux를 사용한 단순한 Web서버 프로그램을 준비한다

 

순서

1. Godep 등을 사용하여 의존 모듈을 고정시킨다

2. Docker 컨테이너 내에서 바이너리를 빌드 한다

3. 가능한 한 작게 Docker 이미지(예를 들면 `scratch` )을 찾고, 이것에 바이너리를 묻는다

4. 최종적으로 이미지 파일 크기는 4MB가 된다.

 

* 샘플 코드는 여기에 있다.

https://github.com/treeder/tiny-golang-docker

 

 

출처: http://blog.craftgear.net/56273d35642e1c0100000001/title

저작자 표시
신고
by 흥배 2015.10.30 08:00

오늘 Go 프로젝트는 Go 6번째 안정된 메이저 릴리스인 Go 1.5를 발표하였다.

 

이 릴리스에는 구현에 대한 중대한 변경이 포함되어 있다. 컴파일러 툴 체인이 C에서 Go로 바뀌었고, Go 코드 베이스에서 C 코드의 마지막 흔적이 삭제되었다. 가베지컬렉션이 완전히 다시 설계되어 가베컬렉션에 의한 일시 정지 시간이 극적으로 단축되었다. 스케줄러에 관련된 개선으로 기본 GOMAXPROCS (동시에 실행되는 goroutine ) 1에서 사용 가능한 CPU 수로 변경할 수 있도록 되었다. 링커에 대한 변경으로 Go 패키지를 Go 프로그램에 링크되는 공유 라이브러리로, 혹은 C 프로그램이 링크 또는 로드 할 수 있는 아카이브 또는 공유 라이브러리로 할 수 있다.

 

이 릴리스에는 개발자 도구에 대한 개선도 포함되어 있다. "internal" 패키지 지원에 의해 패키지 간 구현의 상세를 공유할 수 있다. 외부 의존 관계 「벤더링」의 실험적인 지원은 Go 프로그램의 의존 관계 관리를 위한 표준 구조를 위한 스텝이다.  새로운 "go tool trace" 명령을 사용하면, 수행 시 새로운 추적 인프라에 의해서 생성되는 프로그램 트레이스를 표시할 수 있다. 새로운 "go doc" 명령에서는 Go 명령 라인 인터페이스에서 패키지 문서의 열람을 보다 쾌적하게 할 수 있게 되었다.

 

다양한 새로운 운영 체계 및 아키텍처로의 이식도 있다. 보다 성숙한 새로운 이식은 darwin/arm, darwin/arm64(Apple iPhone 디바이스 및 iPad 장치), linux/arm64 이다. Ppc64 ppc64le(IBM PowerPC 64비트, 빅 엔디언과 리틀 엔디언)의 실험적인 지원도 있다.

 

darwin/arm64 이식 및 외부 링크 기능은 Android 장치 및 iOS 기기 상에서 앱 개발에 Go을 어떻게 사용할 수 있는지를 시험하는 실험으로 Go mobile 프로젝트를 촉진한다.(Go mobile의 자체는 이 릴리스의 일부가 아닙니다)

 

언어의 유일한 변경 사항은 map의 리터럴 구문에 대한 제한 철폐이며, 보다 간결하게 슬라이스 리터럴과 정합성을 갖게 되었다.

 

표준 라이브러리에도 많은 추가 및 개선이 가해지고 있다. flag 패키지에서는 더 보기 쉬운 사용 상황 메시지가 표시된다. math/big 패키지에서는 임의의 밀도 부동 소수 점에서 계산하기 위한Float 형이 제공되게 된다. Linux 시스템 및 BSD 시스템의 DNS 리졸버의 개선에서는 참조를 지정하는 프로그램에 대한 cgo 요건이 삭제되었다. go/types 패키지는 golang.org/x/tools 저장소에서  표준 라이브러리로 이동 되었다.(go/constant 패키지 및 go/importer 패키지는 이 이동의 영향으로 작성되었다) reflect 패키지는기존의 SliceOf 함수와 비슷한 새 ArrayOf 함수 및 FuncOf 함수를 제공하고 있다. 물론 일반적인 세부 수정 점 및 개선점 리스트도 있다。

 

자세한 것은 상세한 릴리스 노트를 참조해라.

 

 

출처: http://google-opensource.blogspot.jp/2015/08/go-15-is-released.html

저작자 표시
신고
by 흥배 2015.10.12 08:00
go

Parse는 확장성을 향상시키기 위해서 API를 포함한 서비스 일부를 Ruby on Rails에서 Go로 이행했다. 이로써 신뢰성과 배포 시간이 현저하게 개선됐다.

 


Parse 2011, Ruby on Rails 프로젝트로 시작했다. 이 선택에 의해서 Parse의 첫 버전을 소수의 기술자 그룹만으로 단기간에 구현할 수 있었다고 Majors(Parse의 엔지니어)씨는 말한다. 그러나 Parse가 확장되면서 아키텍처 상의 문제가 몇 가지 나타났다.


- 코드 베이스의 확대에 따른 배포나 롤백에 시간이 증가됐다. 게다가 Parse HTTP 서버인 Unicorn의 재 실행이 제대로 되지 않았다. 그 결과 몽키 패치(monkeypatching)에 의존하는 부분이 점차 커졌다.


- Rails의 요구마다 1프로세스 라는 모델이 API 트래픽과 앱 수의 증가에 따라서 붕괴"를 시작했다. 실제로 시간을 요하는 리퀘스트를 많이 수신한 경우 Rails의 워커 풀 사이즈의 자동 확장 기능이 따라가지 못해서, 워커 풀이 쉽게 넘치는 현상이 발생했다. 게다가 이들 워커의 대다수는 단순히 외부 서비스 완료를 기다리고 있는 상태였다.

 


이런 문제로부터 Parse의 엔지니어들은 Rails "요구 당 1 프로세스모델을 벗어나서 진정한 비동기 모델로 이행할 필요성을 인식하기에 이르렀다. Ruby gems의 대부분은 비 동기성이 없고 또 스레드 안전이 아닌 것도 많아서 Ruby는 이러한 처리에 적합하지 않다고 생각한 그들은 다른 언어를 선택하기로 했다. 선택 사항으로서 그들이 검토한 것은 다음과 같다.


- JRuby. 이것은 제외됐다. JVM에는 대규모 병행 처리를 다루는 능력이 있지만 Ruby의 비동기 라이브러리 지원에 문제가 있다는 것에는 변함 없기 때문이다.


- C++. 다른 언어에 비해 생산성이 낮고 HTTP 요청의 처리나 비동기 조작을 돕는 라이브러리가 없음 등을 이유로 이것도 제외됐다.


- C#. 비동기의 Await/Async 모델은 매우 좋은 선택이라고 생각되었지만 “Linux에서의 C# 개발은 주류가 될 수 없다고 생각으로 제외됐다.


- Go. 비동기 작업을 네이티브 지원하고 있고 MongoDB의 지원이 최고 수준, 코루틴 지원 등으로 최종적으로 가장 좋은 선택지로 여겨졌다.


 

Parse 기술자들이 자신들의 EventMachine Go로 구현하고 간단한 테스트를 실시했는데, 노드 당 접속 수가 25~ 150만이라는 결과를 얻었다. 이 결과를 바탕으로 그들은 코어 API를 포함한 모든 서비스를 하나씩, 하위 호환성을 확보하면서 수정 작업에 착수하였다.


 

프로세스의 종료 시에는 노력에 상응하는 결과를 얻었다고 Majors씨는 말한다.

- Parse "신뢰성이 현저히 향상”.

- 가동하는 데이터베이스 수 감소에 따른 API의 취약화에 제동이 걸렸다.

- 테스트 스윗 전체 통합 실행에 시간이 25분에서 2분까지 단축했다.

- API 서버 전체 배포 시간이 30분에서 3분으로 단축됐다.

- API 서버의 정상적인 재기동이 최종적으로 이루어졌다.

 

 

출처: http://www.infoq.com/news/2015/06/parse-moved-ruby-go  

저작자 표시
신고
by 흥배 2015.08.17 08:00

Go 1.5(2015 6)에서는 GC 지연 감소를 목표로.

구체적으로는 50밀리 초마다 GC 지연을 10밀리 세컨드 이하로 억제.

도달 가능한 값의 최대 2배의 힙을 사용한다.

 

구현 방침은 stop the world(STW)Concurrent GC의 하이브리드. STW에 의한 정지 시간을 50밀리 초마다 10밀리 세컨드 이하로 낮추고, 그 시간 내에 GC가 완료되지 않으면 Concurrent GC로 전환.

이로써 50밀리 세컨드 이내의 응답 시간이 필요한 프로그램이 40밀리 초의 실행 시간을 얻도록 한다. 이 수치는 1000달러 Linux PC 정도를 상정. 이른바 non-generational, non-moving, concurrent, tri-color, mark and sweep 컬렉터를 구현한다.

 

Go 1.6(2016 1) 1.5에서의 피드백을 바탕으로 목표를 결정하게 되지만 아마 bump pointer allocation nursery spaces generational copy를 도입하여 산출량을 향상시킨다.

 

Go 1.5에서 도입되는 새로운 알고리즘에서는 지연은는 크게 짧아지지만 스루풋이 저하된다. 그것을 상쇄하는 별개의 최적화를 하고, 버전을 올림으로써 성능이 악화되지 않도록 한다.

 

 

출처: https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLovrHvvLhK_h0KN8woTO4/edit

저작자 표시
신고
by 흥배 2015.07.30 08:00

Go 1.5 릴리스는 2015 8 1일 예정.

- 5월 시점에서 작업이 끝나 있고, feature freeze에 들어가 있음

- 여기까지 The State of Go에서의 정보

- 끝이 정확한 경우 곧 Release Candidate가 나올 것 같음

 

 

Go 1.5부터 년 2회 릴리스 계획

- 2 1, 8 1일 반년마다 메이저 (1.x) 출시

- 3개월은 개발, 3개월은 testing (feature freeze) 기간을 가진다

- http://golang.org/s/releasesched

 

 

 

Go 1.5에서 주목해야 할 새로운 기능과 변경 부분

출시되지 않았지만 저장소의 릴리스 노트에서 발췌

기대의 새로운 기능

- Shared Library

- Execution Tracing (go trace 명령)

- Concurrent Garbage Collection

- "vendoring"external package

 

신경 쓰이는 변경 부분

- 툴 체인에서 C언어를 배제(Go 1.5의 빌드에 Go 1.4 이상이 필요)

 https://talks.golang.org/2015/gogo.slide#1

 https://golang.org/s/go13compiler

 

 

Go 1.5의 차이

GOMAXPROCS 환경 변수가 기본적으로 CPU 코어 수로 된다

internal package 언어 사용자에게 도입

http://golang.org/s/go14internal

전술 한 바와 같이 출시 계획 변경하여 반년마다 년 2회 릴리즈

언어의 작은 변화

등등

 

 

Shared Library

buildmode라는 명령 줄 옵션이 새롭게 추가되어 shared object 생성이 가능.

$ go build -buildmode = shared ~ ~ 생략 생략 ~ ~

buildmode (go help buildmode의 일부를 짤라서 설명)

- archive : main 패키지 이외 .a 파일로 빌드

- c-archive : main과 필요한 패키지를 C언어용 아카이브로 빌드한다. Go 소스 중에서 "//export funcname" 마크가 필요

- c-shared : c-archive shared library 작성 버전

- shared : main 패키지 이외를 shared library 화 하고, -linkshared 옵션으로 링크 할 수 있도록 한다

 

 

Execution Tracing

fine-grained로 성능 모니터링을 할 수 있게 되었다

감시 할 수 있는 stats : 각각의 시작 시간과 소요 시간

- Heap (GC)

- Goroutine

- 스레드

- Go Processor 마다의 프로필

 시스템 호출 스택 추적



제안 문서에서는 network IO도 대상 이었지만, 패치를 보면 IO 모니터는 확인할 수 없었다

 Go Execution Tracer : http://golang.org/s/go15trace

  Groups 스레드에서는 AMD Code Analyst Intel VTune을 의식한 발언도

 

 

"vendoring"external package

Go언어에서 import (go get) 버전 문제에 대한 실험적 노력

Go 사용자는 아시다시피 Go는 의존하는 외부 라이브러리의 버전을 지정하는 기능을 제공 하지 않는다

- 이를 해결하기 위해 Godep 명령과 같은 hack이 있다

- Go 공식 vendoring (의존 저장소를 자신의 저장소에 포함) 법이 실험적으로 지원된다

https://golang.org/s/go15vendor

 

 

Concurrent GC

GC Stop the world Concurrent GC의 하이브리드를 전부터 채택했다. 1.5에서는 stop the world에서 concurrent collector로 된 GC에 의한 정지 기간을 개선

- GC 지연 시간을 10ms 이하를 목표로 하고있다

GC에 의한 정지 기간을 짧게 하는 대신 CPU 및 메모리 소비가 약간 증가

대부분의 경우 goroutine의 병렬 때 CPU 사용율이 오르는 것 같다

디자인 문서

https://golang.org/s/go14gc

  https://golang.org/s/go15gcpacing

 

 

 

trace 명령어 소개(Execution Tracing)

$go test -‑‒trace=/tmp/trace -‑‒run=BenchName-‑‒bench=BenchName cpu=4

$PATH=trace-‑‒viewer/tracing:$PATH trace -‑‒http=localhost:9876 path/to/ testbinary.test /tmp/trace


 

설명: http://golang.org/s/go15trace

 

 

출처: http://www.slideshare.net/pfi/go15-50328018

저작자 표시
신고
by 흥배 2015.07.27 08:00
go

GoogleGo 1.5를 부트 스트랩화 하는 계획에 대해 공개했다.

Go 문서의 저자이며, 코어 개발자인 Russ Cox씨에 의하면 Google은 근래 1년 동안 “Go의 소스 트리에서 모든 C 프로그램을 배제하는 방법에 대해 검토했다고 한다.

 

부트 스트랩은 컴파일의 대상이 되는 프로그래밍 언어 자체로 컴파일러(또는 어셈블러)를 개발하는 프로세스이다

일반적으로 부트 스트랩에는 다음과 같은 장점이 있다고 한다.


1. 부트 스트랩 하는 언어 테스트 때문에.

2. 보다 고도의 추상성을 갖춘 보통 고 레벨 언어로 컴파일러를 기술할 수 있다.

3. 언어 자체의 개량 결과를 참조함으로써 컴파일러가 이런 혜택을 받을 수 있다.


 

Google 1년 이상 전부터 5단계로 구성된 변환 계획을 정의하고, Go의 소스 트리 중에서 C 프로그램을 제거하는 작업을 시작하고 있다.




C를 대신하여 Go를 사용하여 빌드 하는 것으로 큰 개선을 기대할 부분은?

Ken Thompson씨가 이전에 프로그램을 쓰면서 Go C보다 훨씬 간단하다고 느껴지는 언어라고 말한 적이 있다. 그 이유의 하나로 무효한 포인터 값의 사용 및 메모리 릭, 버퍼 오버 플로우, 깊은 재귀의 스택 오버 플로, void* 오용, 기대와 다른 수치 비교 같은 C에서 일반적으로 버그가 생기기 쉬운 부분을  Go에서 모두 삭제한 것이다.

 

표준 Go 툴 체인은 모듈성과 유닛 테스트, 프로파일 등의 지원 면에서 표준적인 C 툴 체인보다 훨씬 뛰어나다. 그렇지만 내가 가장 감동한 것은 내부적인 API 변경이나 리팩터링을 실시할 때 (gofix 같은)프로그램의 자동적인 변환을 기대할 수 있다는 것이다.




더 자세한 글은 아래의 글을 보기 바란다.

http://www.infoq.com/news/2015/01/golang-15-bootstrapped 

저작자 표시
신고
by 흥배 2015.02.10 08:00
go

2011년 6월 17일에는 Go와 node.js를 성능 비교했을 때는 Go가 node.js에 비해 45% 정도 느렸지만 2015년 1월 13일 현재는 3배 정도 빠르게 나옴

현재는 버전은 Go는 1.4, node.js는 0.10.35


2011년 6월 17일

For go: 

Concurrency Level:      100 

Time taken for tests:   152.330 seconds 

Complete requests:      1000000 

Failed requests:        0 

Write errors:           0 

Total transferred:      110000000 bytes 

HTML transferred:       14000000 bytes 

Requests per second:    6564.69 [#/sec] (mean) 

Time per request:       15.233 [ms] (mean) 

Time per request:       0.152 [ms] (mean, across all concurrent 

requests) 

Transfer rate:          705.19 [Kbytes/sec] received 



For node.js: 

Concurrency Level:      100 

Time taken for tests:   104.538 seconds 

Complete requests:      1000000 

Failed requests:        0 

Write errors:           0 

Total transferred:      78000000 bytes 

HTML transferred:       14000000 bytes 

Requests per second:    9565.93 [#/sec] (mean) 

Time per request:       10.454 [ms] (mean) 

Time per request:       0.105 [ms] (mean, across all concurrent 

requests) 

Transfer rate:          728.66 [Kbytes/sec] received 



Here are the codes for go and node.js 


go code: 


package main 

import ("http";"io";"runtime") 

func HelloServer(w http.ResponseWriter, req *http.Request) { 

        io.WriteString(w, "hello, world!\n") 

func main() { 

  runtime.GOMAXPROCS(1) 

        http.HandleFunc("/", HelloServer) 

        http.ListenAndServe(":8080", nil) 


node.js code: 


var http = require('http'); 

http.createServer(function (req, res) { 

  res.writeHead(200, {'Content-Type': 'text/plain'}); 

  res.end('hello, world!\n'); 

}).listen(8080, "127.0.0.1"); 

console.log('Server running at http://127.0.0.1:8080/');




2014년 1월 13일

go 1.4:

                                                      

package main

import ("net/http";"io";"runtime")

func HelloServer(w http.ResponseWriter, req *http.Request) {

        io.WriteString(w, "hello, world!\n")

}

func main() {

  runtime.GOMAXPROCS(1)

  http.HandleFunc("/", HelloServer)

  http.ListenAndServe(":8080", nil)

}


ab -c 1000 -n 50000 -i http://127.0.0.1:8080/


ncurrency Level:          1000

Time taken for tests:    2.284 seconds

Complete requests:      50000

Failed requests:           0

Write errors:                0

Total transferred:         5858775 bytes

HTML transferred:       0 bytes

Requests per second:    21888.45 [#/sec] (mean)

Time per request:          45.686 [ms] (mean)

Time per request:          0.046 [ms] (mean, across all concurrent requests)

Transfer rate:                2504.68 [Kbytes/sec] received




node.js v0.10.35:


var http = require('http');

http.createServer(function (req, res) {

  res.writeHead(200, {'Content-Type': 'text/plain'});

  res.end('hello, world!\n');

}).listen(8081, "127.0.0.1");


ab -c 1000 -n 50000 -i http://127.0.0.1:8081/


oncurrency Level:      1000

Time taken for tests:   7.600 seconds

Complete requests:      50000

Failed requests:        0

Write errors:           0

Total transferred:      5050000 bytes

HTML transferred:       0 bytes

Requests per second:    6578.88 [#/sec] (mean)

Time per request:       152.002 [ms] (mean)

Time per request:       0.152 [ms] (mean, across all concurrent requests)

Transfer rate:          648.89 [Kbytes/sec] received



출처: https://groups.google.com/forum/m/#!topic/golang-nuts/zeLMYnjO_JA%5B101-125-false%5D



저작자 표시
신고
by 흥배 2015.01.15 08:00
| 1 |