2016년 6월 4일 토요일

AMD RX480 발표와 관련한 잡생각..


폴라리스 마카오 이벤트 직전에 던져진 떡밥으로 쉐이더 고유 펑션이라는 기능이 GPUOpen.com에 소개 됐었는데.. GCN 기반 아키텍쳐 제품에서 콘솔과 같이 하드웨어에 직접 접근하는 빌트인 쉐이더 펑션을 사용하는 기능이다. 생각해보니 EA의 프로그래머중 한명이 GCN 하드웨어를 OpenGL을 이용해서 해킹해 사용할려고 했던게 기억이..

결과적으론 빌트인 펑션이라는게 스펙 자체는 2014년 부터 거론이 되서 이번에 도입 되었는데.. Computex 발표회 때 Id 소프트의 엔지니어 인터뷰에서 Vulkan 버전의 둠이 AMD의 True 비동기 컴퓨트와 빌트인 펑션을 이용해서 개발중이며 200+ 이상의 프레임 레이트를 보여줄 것이라는 이야기가.. 마지막에 둠을 환상적인 프레임으로 즐기기위해 $700 그래픽 카드를 살필요 없다는 이야기는 1080 발표회때 초대한 엔비디아의 뒤통수를 강하게 치는 듯한 한마디였다; 관련 영상은 여기에서..

그리고 비동기 컴퓨트에 True를 붙인건 아마도 엔비디아의 비동기 컴퓨트와 구분할려고 붙인 것 같다.. 알고있는 바로는 AMD가 이야기 하는 비동기 컴퓨트에선 작업 타입이 크게 3종류가 있는데 쉐이더, 컴퓨트, 복사 작업이며 이런 작업 타입에 상관없이 전체 작업에 비동기 스케줄링이 가능한 방식이다. 하지만 엔비디아가 이야기하는 방식은 각각의 타입별로는 비동기 처리를 할지는 모르겠지만 작업 타입이 바뀌는 경우 전환 비용이 발생하고 있다.

현재 들리는 바로는 10월에 코드네임 VEGA 제품과 출시할 문명6가 이런 작업 타입 전체에 대해 기존보다 좀더 적극적으로 비동기 컴퓨트를 이용할 예정이라는 루머가 있고 6월 13일 E3에서 VEGA의 런칭 타이틀인 EA의 Battlefield1의 64인 멀티플레이 라이브 스트림 이벤트가 있다. 아마도 시연은 폴라리스 혹은 VEGA로 알려진 제품으로 하지 않을까 추측된다. Total War : Warhammer의 경우도 DX12 버전 패치를 준비중이며 비동기 컴퓨트, MLAA, TressFx 3.1등이 적용된 버전이며 게임의 전반적인 성능 향상에 초첨을 두었기 때문에 그래픽 카드 벤더와 상관없이 DX11버전 대비 큰 성능 향상이 있을 것으로 예상 된다.

AMD GPU ROADMAP
사실 이번에 가장 화제가 되었던 $199 에서 시작하는 가격은 아직 정확히 성능을 가늠하기 힘든 상황에서 대략적인 윤곽만 보이며 경쟁사의 라인업을 꼬이게 하는.. 아직까지는 엄청난 효과를 발휘하는 것 같아 보인다. 더군다나 예전부터 이야기 되었던 Primitive Discard Accelerator의 효과가 어느 정도인지도 미지수인 상태인데다 본격적으로 적용된 타이틀이 EA의 Battlefield1일 가능성이 크기 때문이다.

그밖에도 경제적인 문제로 보면 양적 완화를 시행한 미국에선 최근은 나아져 가는 편이지만 은행에서 돈은 풀었지만 개인의 삶은 나아지지 않는 문제라던가 BRICs와 같은 신흥국 소비자의 구매력이나 여러가지를 고민 했던 것 같다.. 아마도 이번 세대 최대 과제가 앞으로의 청사진을 위해 가능한 점유율을 끌어올리는게 목적이라 $500 가격대 성능을 $199에 제공하기로 결심한게 아닌가 생각된다..

개인적으로 추측하고 있는 AMD의 청사진은 위 슬라이드의 코드네임 Navi의 경우 Scalability를 강조하고 있는데 해외 웹진들과 AMD 관계자와의 인터뷰에서도 간간히 언급 되었지만 빅뷰티칩은 매우 비효율적이고 리스크가 크기 때문에 사실상 빅칩 전략을 사용하는 시대는 Vega가 마지막이 되지 않을까 생각하고 있다. 그렇기 위해서는 앞서 언급한 것 처럼 점유율을 끌어올리고 멀티 GPU를 이용하는 사용자를 많이 확보할 필요가 있는데 이는 VR을 위한 Liquid VR 기능과도 연관이 된다.

또한 현재 DX12의 멀티 GPU 렌더링 기술역시 과거의 Alternate Frame Rendering 기법에서 머물고 있는 상태를 넘어 이론적으로는 이미 알려져 있었지만 구현하긴 힘들었던 다양한 기법을 통해 APU와 같은 내장 GPU를 활용할 수 있길 바라고 있고 아마도 이를 위한 기반 기술인 비동기 컴퓨트였을 것으로 생각하고 있다. 덧붙여 크로스파이어의 API와 샘플 코드역시 공개되어 있는 상태이다.

AMD의 고유 API들은 대부분 오픈소스로 공개되어 있거나 앞으로 계속해서 추가되어 갈 것으로 보인다. 이렇게 풍부하게 보급된 AMD의 자원은 개발자들이 좀더 자신들과 협업할 수 있는 기회를 만들어주고 GPUOpen 프로젝트를 통해 개발자들과 결과물을 공유하는(GPUOpen 프로젝트의 업데이트를 유심히 보면 협력해서 작업한 게임이 출시되면 해당 프로젝트에서 나온 결과물들이 대량 업데이트 되는 것을 볼 수 있다..) 일은 게임웍스와는 다르게 개발 자원의 투명성을 보장해 주고 있다. 최근 대안으로 거론되는 경제 모델에선 Win-Lose는 존재하지 않고 상호간에 Win-Win 아니면 Lose-Lose 밖에 존재하지 않는 다는 것을 오랜기간 암흑기를 거치면서 깨달은 것 인지도 모르겠다. 사실 다른 관점에서 생각해보면 밥줄인 핵심 기능들은 하드웨어로 구현하고 이를 최대한 활용할 수 있는 자원들은 공유하는 형태이기도 하다.

여튼 이번 기회에 정상 궤도로 복귀해서 지금까지 경험하지 못한 화려한 그래픽의 세계로 소비자들을 초대하는 모습을 보여주기 바라며 이만 줄인다..

2016년 6월 1일 수요일

Java 9의 GC

참고 : https://www.infoq.com/presentations/java9-improvements

Java 9의 핵심 기능인 모듈러 Java를 위한 Jigsaw는 워낙 여러곳에서 다루고 있다보니 이를 제외한 기능에 대해 이야기 하고 있는 eclipsecon의 발표 자료가 나왔는데 이중 GC와 관련한 항목이 눈에 띄어 간단히 정리해 보기로 하였다.

Java 8까지는 Parallel GC가 기본 GC였는데 9부터는 G1 GC가 기본 GC로 바뀐다고 하며 String 중복 제거 기능에 대한 소개가 있는데 비동기로 동작해서 런타임 오버헤드가 없고 힙공간 낭비를 10%가까이 줄일 수 있다고 하며 Java 8u20 부터 사용 가능하다고..

사용 옵션은 다음과 같다.

-XX:+UseG1GC -XX:+UseStringDeduplication

이와 별도로 Java 9에서는 String 데이터 타입의 튜닝이 꽤 적용되서 전체적인 퍼포먼스 향상이 기대되고 Java 9의 마일스톤은 2016년 5월에 스펙이 마감되었고 2017년 3월 정식버전 발표를 앞두고 있다. Jdk9의 미리보기 버전을 사용하고 싶다면 다음 링크를 참고하면 된다.

2016년 5월 30일 월요일

5월 4주차 소식들..

기타

구글과 오라클의 법정 싸움은 2주간의 재판 진행 끝에 구글의 승리로... 처음 시작은 자바만의 문제였다가 이번 재판에선 API 디자인이나 명세가 저작권을 갖는지에 대한 문제로 바뀌면서 오라클이 이겼다면 변호사가 개발자의 친구가 될거라는 이야기가 있었던... 링크

구글의 안드로이드 업데이트와 관련해서 OEM과 통신사들의 랭킹을 부여해서 업데이트를 촉진 시킬려고 하지만 정작 제조사들은 상위 제품 사용자와 보급형 제품 사용자의 차이가 적어져서 매출에 악영향을 미치는 것을 우려하고 있다는 소식.. 링크

보안

WordPress의 플러그인 중 Jetpack의 코멘트 기능에 XSS 취약점을 이용해서 의심스러운 코드를 심을 수 있는 문제가 발견되어 21개의 브랜치에 대해 패치 버전이 나왔다는 소식.. 링크

JavaScript 첨부파일을 통해 전파되는 Locky 랜섬웨어에 대한 소식.. 아직까지는 암호화된 파일을 복원할 방법이 없다고 하며 일반적으로 JavaScript 코드의 첨부파일을 주고 받을일은 거의 없으나 .js나 .jse 파일을 포함한 메일은 주의를 기울일 필요가.. 링크

Drupal을 이용해서 운영되는 사이트를 대상으로 SQL injection 결함을 이용해 관리자의 비밀번호를 변경시키는 랜섬웨어 봇에 대한 소식이.. 대부분의 사이트들이 자동 백업 시스템을 갖추고 있어서 이와 관련하여 비용을 지불한 케이스는 아직 없다고.. 링크

JavaScript를 이용해서 웹페이지를 복사할 때 의심스러운 터미널 코드를 포함하도록 클립보드를 탈취해서 변조하는 Pastejacking이라는 해킹 기법이 소개된.. 링크

익명 통신 네트워크 서비스를 제공하는 Tor에서 보안을 강화하기 위해 분산된 다수의 시스템의 엔트로피를 수집해 랜덤 넘버를 생성하는 기법을 발표 했다고.. 링크

"Forbidden attack"이라고 불리는 오래전에 밝혀진 해킹 기법이 Visa 사이트에서 유효하게 동작 하는 것 같다는 소식이.. TLS 프로토콜을 이용해서 통신할 때 서버에서 1회성 랜덤키를 받아오는데 보통은 한번 사용하면 다시 사용할 수 없지만 만약 규칙을 준수하지 않아 한번이라도 더 사용할 수 있게 되어 있다면 공격자가 네트웍을 모니터링 할 수 있는 상황(공개된 WiFi 같은..)이라면 중간에 코드를 삽입하여 정보를 탈취할 수 있는 문제가 있다고.. 링크

소프트웨어

리눅스의 VFS레이어에 inode 타임스템프가 signed 32bit integer를 사용해서 발생하는 2038년 버그가 커널 4.7에서 한참 수정중이라는 소식 이와 더불어 EXT4 파일시스템도 다수의 버그픽스가 커널 4.7에 올라오고 있다고.. 링크 링크

하드웨어

CCIX 컨소시엄에 대한 소식..SoC를 위한 고속 통신용 인터페이스라는데 참여 기업이 ARM, Qualcomm, AMD, Xilinx, Huawei, IBM, Mellanox라고 모바일에서 PC 수준의 연결성을 제공할 인터페이스라는데 멀티칩모듈(MCM, 노트북의 그래픽카드나 AMD의 Fiji칩같은..)과 외장 카드형태 모두를 지원 할거라고.. 링크

2016년 5월 29일 일요일

c10k 문제..

참고 : http://www.kegel.com/c10k.html , https://en.wikipedia.org/wiki/Continuation , https://en.wikipedia.org/wiki/Green_threads , https://en.wikipedia.org/wiki/State_machine_replication , https://en.wikipedia.org/wiki/VxD , http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/ , http://stackoverflow.com/questions/5635362/max-thread-per-process-in-linux , http://www.lowtek.com/sockets/select.html , https://en.wikipedia.org/wiki/Zero-copy

머신의 성능이 충분해진 시대에 10000개의 클라이언트에 어떻게 서비스를 제공할 것인가에 대한 질문에서 출발한 이야기인데.. 참고 사이트는 사실 꽤 오래전 이야기에 시스템 레벨에서의 I/O최적화에 대한 히스토리를 주로 모아뒀고 OS나 서버사이드 어플리케이션들에 오랬동안 논의 되었던 해결책들이 하나둘씩 적용되고 있으며 또한 이미 사용되고 있다.

요즘같이 스케일아웃 솔루션들이 잘 나와있는 시대에는 별 의미 없는 이야기 일 것 같아 보이기도 하지만 전체 시스템의 I/O 응답성을 높이기 위해 한번쯤 생각해 볼만한 주제인 것 같아 간단히 정리해 보기로 하였다.

I/O 전략

네트워킹 소프트웨어 디자이너를 위한 몇가지 옵션들..
  • 단일 쓰레드에서 다중 I/O 호출 발행 여부와 어떻게 발행할 것인지에 대해
    • 다중 쓰레드나 동시성을 얻을 수 있는 프로세스를 사용할 수 있는 곳에 블러킹/동기식 호출 사용하지 않기.
    • I/O 시작에 넌블러킹 호출을 사용하고 해당 채널에서 다음 I/O를 시작할 준비가 되었음을 알 수 있는 준비 알림 사용하기. 일반적으로 디스크 I/O가 아닌 네트워크 I/O에 유효함.
    • I/O 시작에 비동기 호출을 사용하고 I/O가 끝났을 때 완료 알림 사용하기. 네트워크와 디스크 I/O 모두에 유효함.
  • 개별 클라이언트에 대해 서비스를 어떻게 제어할 것인지에 대해
    • 각각의 클라이언트에 하나의 프로세스 할당(고전적인 유닉스 접근방식, fork()와 같은..)
    • 단일 OS 레벨 쓰레드가 다수의 클라이언트에 서비스를 제공하는 경우. 각 클라이언트는 다음에 의해 컨트롤 됨
      • 사용자 레벨 쓰레드(GNU 상태 쓰레드나 Green 쓰레드를 사용하는 Java) - Green 쓰레드는 커널 레벨이 아닌 VM 레벨에서 동작하며 단일 코어 CPU를 사용할때 유효한 방식이라 JVM 1.3 이후에는 사용되지 않고 있습니다.
      • 상태 머신 - 복제된 다수의 서버를 이용한 분산 시스템
      • 컨티뉴에이션 - 최근 유행하기 시작한 펑셔널프로그래밍의 비동기 프로그래밍 기법
    • 각각의 클라이언트에 하나의 OS 레벨 쓰레드 할당(네이티브 쓰레드를 사용하는 Java)
    • 각각의 활성 상태의 클라이언트에 OS 레벨 쓰레드 할당(아파치 프론트엔드와 함께 Tomcat을 사용하거나 NT의 I/O completion port나 쓰레드풀을 사용)
  • 표준 커널 서비스를 사용하거나 일부 코드를 커널에 포함시키는 방법(커스텀 드라이버, 커널 모듈 혹은 VxD - Virtual xxx Driver)
인기있어 보이는 몇가지 조합

쓰레드별로 다수의 클라이언트를 처리하며 넌블러킹 I/O와 함께 참조할 파일 디스크립터의 대기 상태를 select()나 poll()을 이용해 물어 처리(level triggered)하는 방식이 있는데 디스크 I/O가 블러킹 모드를 사용할 경우 병목이 발생할 수 있다.

파일 디스크립터의 대기 상태 변화시 알림을 받는 형태(edge triggered)로 처리하는 방법 있으며 프로그래밍 실수에 대해 관대하지 않은 방식이라 이벤트를 하나라도 놓친다면 해당 연결은 영원히 멈춘 상태가 될 수 있다.

비동기 I/O를 사용하는 경우는 큐를 이용한 신호(보통 유니크한 키값)와 값을 전달 하는 방식이며 기본적인 동작 방식은 작업이 완료된 상태 알림(edge triggered)을 받으면 큐에 담아 전달하는 형태이다.

클라이언트당 쓰레드를 할당하여 서비스를 하는 경우는 쓰레드당 사용되는 스택사이즈에 신경을 써야 하는데 메모리 비용의 문제가 발생할 수 있는 방식이다.

파일핸들러에서의 최대로 열 수 있는 파일수의 제약

최대로 열 수 있는 파일수의 제약이 있기 때문에 이런 제약에 걸린다면 OS의 설정 파일을 손봐야 할수도 있다. 리눅스의 경우 cat /proc/sys/fs/file-max를 이용해 값을 확인 할 수 있다.

쓰레드상의 제약

가상메모리를 소진시키지 않기 위해선 쓰레드당 할당된 스택의 크기에 주의할 필요가 있으다. 프로세스당 최대 쓰레드의 수가 제한되어 있으며 기본값은 시스템 메모리 크기에 따라 자동으로 계산 되며 런타임에 변경 가능하다. 리눅스의 경우 cat /proc/sys/kernel/thread-max를 이용해 값을 확인 할 수 있다. 시스템에서 쓰레드당 할당되는 메모리 묶음의 크기는 cat /proc/sys/vm/max_map_count를 이용해 확인할 수 있다. 해당 값들을 변경하게 될 경우 메모리 파편화와 오버커밋도 고려해야 하는 문제가 있다.

Java와 관련한 이슈

NIO에서 넌블러킹 I/O를 지원하고 있으니 일부 제약이 있긴 하지만 NIO를 사용할 수 있다면 사용하길 추천한다.

다른 팁들
  • Zero-copy 이용하기 - CPU의 복사 시간에 낭비되는 자원을 줄여 네트웍의 효율을 높이는 방법이다. HSA 같은경우 CPU와 GPU간에 포인터를 전달할 수도 있다.
  • 네트웍에서 부분 프레임만 지속적으로 보내는 상황 피하기.
  • 과부하 상황에 재치있게 행동하기 - 과부하 상황에서 유입되는 접속수를 낮춤으로 퍼포먼스 양상을 개선하고 전체적인 에러율을 낮추는 방법을 선택할 수도 있다. 요즘은 유연하게 스케일 아웃을 할 수 있는 방향으로 가고 있다.
  • 쓰레드별 워킹 디렉토리를 갖는 비 POSIX 쓰레드를 사용할 수 있다. FTP서버에서 이점이..
  • 프로세스가 아닌 어플리케이션 레벨의 캐싱.
원문에서는 좀더 상세한 내용을 다루고 있으니 관심있는 분들은 원문을 참고하길 바라며 일부 링크의 경우는 세월이 많이 흘러 유실된 경우가 있지만 관련 자료들은 대부분 검색을 통해 확인할 수 있으니 참고하시길 바라며..