http://www.hanbit.co.kr/realtime/books/book_view.html?p_code=E7889843127

 

 

저작자 표시
신고
by 흥배 2016.08.31 07:00
http://www.hanbit.co.kr/realtime/books/book_view.html?p_code=E3308781402

 

 

저작자 표시
신고
by 흥배 2016.08.30 07:00

http://www.hanbit.co.kr/realtime/books/book_view.html?p_code=E5116607822

 

 

저작자 표시
신고
by 흥배 2016.08.29 07:00

unity의 메모리 최적화 관련 글을 보면 foreach를 사용하지 마라는 것을 자주 볼 수 있다.

이유는 foreach에서 메모리 할당을 발생시켜서 GC를 유발하기 때문이다.

 

이것은 C# 언어 자체의 문제가 아니고 mono쪽의 구현 문제이다.

C# 스펙 문서에도 foreach 최적화에 대해 언급이 있는데 mono에서 제대로 구현하지 않았다.

MS의 닷넷프레임워크에서는 이런 문제가 없다. 그리고 근래의 mono에도 없다.

 

unity는 오래된 버전의 mono를 사용해서 foreach가 문제가 된다.

 

다행히 얼마 전에 unity mono를 업그레이드 하겠다는 계획을 발표했다. 현재 개발자들이 테스트할 수 있는 버전이 나왔고 지금은 컴파일러 부분만 개선되었다(즉 라이브러리 업그레이드는 아직이다).

 

http://forum.unity3d.com/forums/experimental-scripting-previews.107/

이것을 설치해서 foreach를 사용해보면 문제가 해결된 것을 볼 수 있다.

 

장래에 unity를 공부할 때 오래된 글만 보면 실수 할 수 있으니 unity가 새 버전이 나올 때마다 잘 살펴보기 바란다.

 

 

출처: http://neue.cc/2016/08/05_537.html

번역 http://sitetrans.naver.net/?rel=http://neue.cc/2016/08/05_537.html&srcLang=ja&tarLang=ko

 

 

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

Google Maps API

 

Lunar Unity Mobile Console

Unity 모바일 버전의 로그 툴.

Unity에서 만든 Mobile 용으로 최적화된 툴.

http://japan.unity3d.com/

 

Touch Script

Unity 멀티 터지 지원 FrameWork.

https://www.assetstore.unity3d.com/jp/#!/content/7394

http://touchscript.github.io/

 

Zenject

Unity의 의존 관계 등을 자동으로 해결 해주는 프레임워크.

https://github.com/modesttree/Zenject#theory

 

LeanTween

UnityTween 애니메이션을 만들기 위한 엔진.

https://www.assetstore.unity3d.com/jp/#!/content/3595

https://github.com/dentedpixel/LeanTween

 

Newtonsoft JSON

주로 C#에서 JSON을 다룰 때 사용하는 라이브러리.

 

 

 

출처: http://qiita.com/NoriakiOshita/items/29c56fe39e21b12d1527

 

 

저작자 표시
신고
by 흥배 2016.08.22 08:00
C++

https://www.infoq.com/news/2016/07/cpp17-feature-list-complete

핀란드 Oulu 미팅에서 ISO C++ 위원회는 C++17의 기능 목록 정의를 완료했다.

미팅에서는 다수의 새로운 언어 기능과 라이브러리 기능이 승인됐다.

여기에는 constexpr iftemplate<auto>, 구조화 제한 등이 포함 되었다.

 

위원회 멤버 Jens Weller씨에 의하면 이로써 기능 리스트는 종료 되었고, 리뷰 기간이 시작된다고 한다.

"다음 2회 미팅에서는 주로 각국 기관에 의해서 이루어진 검토, 피드백, 과제에 대하여 다룹니다.표준에 새로운 것을 추가하는 것은 없지만 마이너 혹은 중요한 변경이 더해질 가능성이 있습니다."

 

 

 

 

본인은 2009년부터 지금의 C++11을 공부했는데 2011년에 C++11이 나온 후 벌써 5년이나 흘렀고 이제 1년 정도 더 있으면 새로운 표준인 C++17이 나온다.

 

C++ 프로그래밍을 하는데 C++11이나 차기 표준인 C++17이 꼭 필요한 것은 아니지만 이 좋은 기능을 사용하지 않는 것은 엄청난 낭비라고 생각한다(물론 사용하고 싶지만 레거시 코드 때문에 사용 못하는 경우는 어쩔 수 없지만).

 

아직 C++11도 공부하지 않은 사람들이 꽤 있는 것으로 안다.

내년에 17까지 나오면 새로운 C++을 따라가기가 더 벅차질 테니 지금부터라도 조금씩 C++11을 공부해서 내년에는 C++17도 순조롭게 이어서 공부하기 바란다.

 

근래에 나온 C++ 책을 통해서 공부할 수 있고 아니면 구글링(특히 네이버)를 통해서도 C++11에 대해서 공부할 수 있으니 공부하는데 전혀 어려움은 없을 것이다.

 

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

Linus Torvalds씨가 Linux 커널의 네트워크 스택에서 사용되는 주석 스타일에 대해서 "뇌가 손상된 바보 같은 주석"이라고 수정을 요구하고 있다(메일링 리스트에서 코멘트 Register).

 

Torvalds씨는 균형 잡힌 대칭적인 주석 스타일로 통일해야 한다고 생각하는 듯.

아래의 (a)~(c)를 좋은 주석 스타일이라고 밝혔다. Linux 커널 스타일은 아니다고 하면서 허용 가능한 주석 스타일로서 (d)를 꼽고 있다.

 

(a)

/*This is a comment*/

 

 

(b)

/*

*This is also a comment, but it can now be cleanly

*split over multiple lines

*/

 

 

 

(c)

//This can be a single line.Or many.Your choice.

 

 

(d)

/*This is an alternate multi-line format

that isn't horrible, but not kernel style*/

 

 

한편 균형 잡히지 못한 최악인 주석 스타일로 하고 있는 것은 아래의 2.

(no)

/*This is disgusting drug-induced

*crap, and should die

*/

 

(no-no-no)

/*This is also very nasty

*and visually unbalanced*/

 

 

, 주석 박스화를 선호하는 사람의 이야기를 시작할 생각은 없다면서 박스화한 주석은 LSD를 맞았다면 정말 훌륭한 것이라고 생각할 수 있지만, * 오른쪽을 갖추고 있는 것에 신경을 쓰는 것 이상으로 좋은 것은 없다고 말했다.

 

 

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

C#은 배열의 오버런을 방지하기 위해 자동으로 for 문으로 배열을 순회할 때 자동으로 경계 조사를 한다.

문제는 배열의 크기를 확실하게 알고 배열 경계를 넘지 않도록 프로그래머 주의를 해도 컴파일러가 경계 조사 코드를 만들어 버려서 성능 측면에서 손해를 볼 수 있다.

 

배열의 경계 조사를 하지 않고 싶다면 for 문에서 조건 검사를 배열의 Length 멤버를 사용한다

 

static void Test_SimpleAscend(int[] a) {

           for (int i = 0; i < a.Length; i++)

                     a[i] = i;  // We get this.

}

 



좀 더 자세한 내용은 아래 링크를 참조

https://blogs.msdn.microsoft.com/clrcodegeneration/2009/08/13/array-bounds-check-elimination-in-the-clr/

 

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

. NET 4.6에서 GC.TryStartNoGCRegion ~ GC.EndNoGCRegion 라는 것이 추가 되었다.

GC.TryStartNoGCRegion에서 GC.EndNoGCRegion까지 자동 GC를 억제할 수 있다.

 

 

처리 중 GC가 일어날 경우

아래 코드는 1MB의 바이트 배열을 생성하고 GC 회수 대상이 될 수 있는 구성이다.

using System;

using System.Runtime;

using System.Threading;

 

namespace TestSpace {

    class Program {

        static void Main( string[] args ) {

            for( int i = 0; i < 30; i++ ) {

                var n = create();

                Thread.Sleep( 100 );

                GC.KeepAlive( n );

 

                Console.WriteLine( $"GC:{GC.CollectionCount( 0 ) } {GC.GetTotalMemory( false ):#,##byte} " );

            }

            Console.ReadLine();

 

        }

 

        public static WeakReference<byte[]> create() {

            var weak = new WeakReference<byte[]>( new byte[1048576] );

            return weak;

        }

 

    }

}

 

동작 환경에 따라서 차이가 있겠지만 몇 번 GC가 발생하는지 확인할 수 있다.

 

 

GC.TryStartNoGCRegion ~ GC.EndNoGCRegion 로 둘러싸 본다

속도가 중시되는 경우 GC 발생이 병목이 될 수 가능성이 있다.

 

GC.TryStartNoGCRegion에 메모리 사이즈(바이트 단위)를 지정한다.

이곳에서 지정한 사이즈가 소비될 때까지 GC가 억제되게 된다.

 

예를 들어 GC.TryStartNoGCRegion(15728640)라고 지정하면 15MB 소비할 때까지 GC를 억제하게 된다.

또한 지정 가능한 최대 크기는 실행 환경에 의해서 결정된다.

상세는 Fundamentals of Garbage Collection을 참조.

https://msdn.microsoft.com/en-us/library/ee787088(v=vs.110).aspx

 

일반적인 클라이언트 PC 32비트 환경에서는 16MB, 64비트 환경에서는 256MB 이다.

아래의 예는 32비트 환경을 예상한 것이다.

using System;

using System.Runtime;

using System.Threading;

 

namespace TestSpace {

    class Program {

        static void Main( string[] args ) {

 

            if( GC.TryStartNoGCRegion( 15728640 ) ) {

                for( int i = 0; i < 30; i++ ) {

                    var n = create();

                    Thread.Sleep( 100 );

                    GC.KeepAlive( n );

 

                    Console.WriteLine( $"GC:{GC.CollectionCount( 0 ) } {GC.GetTotalMemory( false ):#,##byte} " );

                }

 

                if( GCSettings.LatencyMode == GCLatencyMode.NoGCRegion )

                    GC.EndNoGCRegion();

            }

            Console.ReadLine();

 

        }

 

        public static WeakReference<byte[]> create() {

            var weak = new WeakReference<byte[]>( new byte[1048576] );

            return weak;

        }

 

    }

 

}

 

GC.TryStartNoGCRegion 에서 지정한 15MB까지 GC가 이뤄지지 않는 것을 확인할 수 있다.

그러나 15MB를 초과 한 시점에서 자동적으로 GC가 발동 하는 것도 확인할 수 있다.

 

 

주의 사항

GC.TryStartNoGCRegion을 호출해서 새롭게 할당된 메모리가 지정 크기까지 도달할 때까지 GC를 억제하는 것이다.

이미 할당된 메모리 사이즈는 무의미하다.

 

GC.TryStartNoGCRegion을 다중으로 호출 할 수는 없다.

GC.TryStartNoGCRegion에 성공하면 GCSettings.LatencyMode값이 GCLatencyMode.NoGCRegion로 변경된다.

거꾸로 말하면, GCSettings.LatencyMode == GCLatencyMode.NoGCRegion 이라면 GC 억제 중이라고 판단할 수 있다.

 

GC.EndNoGCRegion() GCSettings.LatencyMode GCLatencyMode.NoGCRegion인 경우에만 실행 가능하다.

GC.EndNoGCRegion()를 호출하지 않아도 자동으로 해제되는 경우가 있다.

GC.TryStartNoGCRegion에서 지정한 사이즈에 달했다

GC.Collect등이 호출 되어 수동에 의한 GC가 발생했다

GC.GetTotalMemory(true)가 실행되었다

 

이런 경우 그 시점에서 GC의 억제 상태가 해제된다.

 

 

MSDN: GC.TryStartNoGCRegion

https://msdn.microsoft.com/en-us/library/system.gc.trystartnogcregion(v=vs.110).aspx

 

동시에 복수의 GC.TryStartNoGCRegion을 호출한 경우 InvalidOperationException이 발생하므로, 멀티 쓰레드에서 GC.TryStartNoGCRegion~GC.EndNoGCRegion을 할 때는 반드시 동기화 해야 한다.

 

출처: http://qiita.com/Temarin_PITA/items/749ad661fd13d7402794

 

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

티스토리 툴바