Lies, Damn Lies and Benchmarks.

Lies, Damn Lies and Benchmarks.

란 클리셰가 나오게 된 원인은

사람들이 트레이드오프랑 전제조건을 같이 인용하지 않기 때문이다.

 

Advertisements

Kotlin언어 성공사례: Corda 블록체인(by R3)

Kotlin언어? 뭔 듣보잡? 성공사례가 있니?

찾아보니 있다.

corda_kotlin.png

CTO는 전 구글 시니어 엔지니어였다고 한다. CTO분이 얘기하신 Kotlin 선택 원인:

  1. 정적 타이핑 (그러고 보니 밀레니얼 세대 언어는 다 그런 것 같다)
  2. Java가 비즈니스 월드에서 중요해서. (하긴)
  3. 섹시해서 (구닥다리 Java랑 비교하니 그렇지)
  4. 배우기 쉬워서 그래서 구인이 쉬워서 (보통 Java구인을 하고 1~3일 트레이닝 시키면 코틀린 언어 코딩을 할 수 있다고 한다)
  5. IDE지원 잘되서
  6. 컴파일 속도가 빨라서 (Scala 저격하며)
  7. 문서화가 잘돼있어서
  8. 내가 할줄 알아서. 내가 좀 해봤는데 재밌어서

그러면서 하는 말이 Kotlin이 없었다면 Scala 썼을 것이라 한다.

마지막에 내린 결론이: 잘한 것 같다.


 

개인적으로 Kotlin이 정말 반갑다. JVM팬으로서 항상 언어가 아쉬웠는데, Java는 구닥다리고, Scala는 너무 복잡하고* Groovy는 언어가 아쉽고, (Scala 와 Groovy공통점이 모두 창립자가 포기했다는 점..) Clojure는 대중성을 전혀 염두에 두지 않은 것 같고. 그런 점에서 Kotlin은 JVM에게 복음과도 같았다.

특히 실행 가능한 환경이  JVM / Javascript VM / Native 로 다양해서 플랫폼에 발목 잡히는 일이 없도록 했다는 점도 칭찬하고 싶다. (마이크로소프트가 최근에야 터득한 점)

JVM, V8엔진, 네이티브 세가지 모두 점점 중요해지는 플랫폼인 것 같다. 아 WASM(Web Assembly)까지 지원하면 더욱 좋겠지만. 이게 미래가 될 수도 있으니. 걱정할 필요가 없는게 컴파일러 플랫폼이 LLVM이어서 WASM이 GC만 지원하면 WASM으로 컴파일 하는 것도 식은 죽 먹기일 거라는 점.

최근 홍민희님의 PyConKr 2017 발표 <파이썬과 다이아스포라>를 보고, 최근에 읽은 <사피엔스>와 결부해서 느낀 점이: 성공한 언어들은 모두 대중성을 키 피처로 치밀하게 기획된 것 같다는 점이다. 민족의 용광로처럼 말이다. (적어도 대량 전파됨을 성공의 척도로 본다면 그렇다)

심지어 Rust도 너무 결백증스러운 면이 있어서 대중성이 의심스럽다.

다행히 Kotlin은 대중성을 키 피처로 설계된 듯하다. 그것의 일환으로 Java월드 레거시에 대한 포용성도 잘 설계된 것 같다.

미래가 지켜볼만하지 않은가!

* 참고로 R3 Corda의 경쟁상대인 IBM hyperledger fabric 은 Go언어로 만들었다.

부록

* TIOBE 프로그래밍 언어 유행도 인덱스에 따르면 Scala는 D언어나 COBOL언어보다 인기가 적다: https://www.tiobe.com/tiobe-index/

 

블록체인은 성능이 개판인가?

개판이 아니다. 이건 미래 얘기가 아니라 현재 얘기다.

성능문제를 앓고 있는 것은 비트코인 네트워크이지 현역 블록체인 기술이 아니다.

다들 아시다싶이

비트코인 네트워크는 7 TPS 성능상한에 시달리고 있고, 이더리움 네트워크도 25 TPS 의 성능상한과 그리 멀지 않았다.

하지만 현역 Bitshares 블록체인DPoS 기술로 테스트 네트워크에서 3000 TPS 성능을 내기도 했다(그리고 출처). 비평자들은 이것이 어느정도 중앙화의 타협으로 이뤄낸 치팅이라고 하지만, 여기에서도 종교전쟁이 등장하는데, DPoS 파의 주장에 따르면 블록 생산노드수의 시점에서 DPoS 만큼 탈중앙화된 시스템도 없다고 한다.

3000 TPS 라면 Reddit 의 쓰기성능 요구를 커버하고도 남는다 [1]. 읽기는 어차피 캐싱과 CDN 으로 해결할거니까.

오프체인 연동도 현역기술이다

오프체인에 데이터를 두고 온체인에는 메타데이터만을 두는 것으로도 어마어마한 성능향상을 가져온다. 흔히들 알고있다싶이 블록체인은 공간사용에 있어서 비효율적이다. 하지만 오프체인 데이터를 통해 Sia coin 이나 Storj 같은 클라우드 (fog) 스토리지 블록체인도 현역이다.

여기까지는 현역 얘기고 지금부터는 미래 얘기다.

이더리움은 최초의 튜링 컴플릿 블록체인이다. 따라서 이더리움의 성능 확장 문제만 해결 하면 사실상 이더리움의 도미네이션이 예상된다. 따라서 이더리움의 성능 확장 로드맵을 살펴보기로 하겠다.

2017년 6, 7월쯤에 Raiden 네트워크 출시가 예정되어 있다

Raiden 네트워크는 비트코인쪽의 SegWit 과 라이트닝 네트워크 기술을 베꼈다 모티브로 한다. 이 기술은 외계기술인데, 요즘 블록체인 기술을 좀 안다 하는 사람들은 모두 이 기술을 이해할 것이다. 이 기술때문이 아니었다면 크립토커런시 시장이 시총 현재 10% 일때 자금유입이 멈췄을 것이라 생각된다.

이 기술이 왜 대단하냐면 이 기술이 (일부 까다롭지 않은 전제조건하에서) 성능을 거의 무한으로 끌어올릴 수 있기 때문이다. Too good to be true? Do your research.

Continue reading

“정부혁신과 블록체인” 국회토론회 박창기 강연 장정숙의원 2016년 11월 30일, 외1편

생각했던 것보다 한국에서 훨씬 활발하게 블록체인이 토론되고있음을 발견했다.


“정부혁신과 블록체인” 국회토론회 박창기 강연 장정숙의원 2016년 11월 30일

박창기 강연 “블록체인과  4차산업혁명” LG인화원 160818

Amazon S3 보다 10배 싼 클라우드 스토리지?!

SiaCoin  의 가격이 하루사이에 80% 가 치솟지 않았다면, 친구가 근래에 자주 언급했음에도 불구하고 나는 SiaCoin 을 “그냥 또하나의 알트코인” (Just Another altcoin) 으로만 간주했을 것이다.

공홈: http://sia.tech/

에서도 알 수 있지만, 그들의 슬로건은 아래와 같다:

sia_slogan

홍보하는 몇가지 키 포인트:

Amazon S3 보다 10배 싸다고 한다.

Far more affordable

Sia’s decentralized cloud is on average 10x less expensive than current cloud storage providers. Storing 1TB on Sia costs about $2 per month, compared with $23 on Amazon S3. Calculate your savings below!

다른 클라우드 저장 솔루션과의 가격비교도 홍보하고 있더라.

sia_storage_price_chart

홍보영상도 있다. 잘 만든 것 같다. 한번 볼까나.

참고로 필자는 여기까지 읽고 바로 투자를 결정했다.

오늘 가격이 이정도로 치솟은 것도 많은 사람들이 필자처럼 “무릎 치기 결정”을 해서인게 아닌가 생각해본다. 그야말로 “눈먼 투자”다.

Continue reading

DB 정규화를 하지 않는 이유

DB 정규화를 하지 않는 이유는 한마디로 성능이다.

그렇다면 DB 정규화는 왜 성능을 해치는가?

1. DB 정규화는 테이블을 많이 나누게 하고, 테이블이 맣아지면 Join 이 많아진다. 그리고 Join 은 성능에 큰 악영향을 미친다.

1.1 Join 은 테이블 락 (Lock) 을 일으키고, 테이블 락은 병렬성의 큰 적이다.

아마 이 이유가 No-SQL 이 부상하게 된 가장 주된 원인이 아닐까 생각한다.

Python 의 GIL 이랑 같은 원리.

1.2 Join 은 여러 테이블을 가로지르는 다중 Disk-seeking 을 일으킨다. 한마디로 데이터 국지화의 적이다.

컴퓨터 하드웨어와 소프트웨어에서 많은 최적화장치들의 작동근거가 데이터 국지화이다. 이 가정이 깨질 경우 데이터 액세스가 굉장히 비싸진다.

DB 정규화는 공간을 가장 절약하는 방식이다 (i). 하지만 저장공간은 저렴하다 [1].

공간을 절약하는건 당연히 죄가 아니다. 심지어 공간을 절약해야 시간도 절약되는 경우가 많다. 그리고 이것 역시 “정규화가 성능에 좋다” 라고 주장하는 사람들의 한가지 근거이다.

하지만 알고리즘이란게 어느 선에 도달한 뒤에는 불가피하게 시간과 공간 사이의 트레이드오프에 직면하게 된다.

정규화는 공간 절약의 극한에 서있다.

이는 이론적으로도 당연하게 시간을 트레이딩 할 여지가 있음을 의미하지만, 많은 실천결과들이 역시 이 결론을 뒷받침해주고 있다.

또한 위의 1.2 와 결합시켜서 살펴보면 알게 되는데, 데이터 양을 줄인다고 무조건 시간이 절약되는게 아니라, 다수의 경우 데이터 국지화가 성능에 훨씬 큰 영향을 미친다. 이것은 실천적으로도 많이들 이중화 (Redundency) 로 정규화를 타파해 성능향상을 이룩하고 있는 산업현황과도 매칭된다.

또한 이 점은 저장 매개체의 랜덤 액세스와 순서적 액세스 사이의 수량급을 초월하는 성능 gap 의 배경속에서 더욱 확대된다. 이것은 물리적인 HDD 에서 유독 두드러지지만 SSD 에서도 상황은 비슷하다.

정규화는 쓰기에 최적화되어 있다. 하지만 읽기가 훨씬 중요하다.

Continue reading

슈퍼마리오 멀티플레이어 개발 후기

coolspeed

왓 스튜디오 팀 합류 과제로 게임제작 미션을 받았다.

나는 과제로 “슈퍼마리오 멀티플레이어 게임”을 만들었다:

EnemyCD.gif

과제 결과물을 왓 스튜디오의 허락을 받고 소스코드를 Github 에 공개하였다:

https://github.com/coolspeed/MarioMultiplayer

관심 있으신 분들은 별표 하나씩 찍어 즐찾해주시길 부탁립니다.

게임 룰: 위의 GIF 움짤  그대로. 먼저 상대방을 밟는 쪽이 이긴다.

 

과제가 1차, 2차로 나뉘는데 1차에서는 싱글 플레이어 슈퍼마리오를 만들었고 2차에서는 그것을 멀티플레이어 게임으로 발전시켰다.

최종 클라 Java (Processing) 1500 줄, 서버 C# 22줄로 짜여졌다.

클라

Processing 으로 만들었다. 왜?

  1. Processing 이 좋아서. (유쾌한 시각적 프로그래밍)
  2. Unity 쓸줄 몰라서.
  3. 다른 엔진도 쓸줄 몰라서.
  4. 엔진부분이 더 재밌어서.
  5. 웹에다 배포하고 싶어서. (P5.js 를 통하여. 하지만 망했다. 그냥 일반 Processing 애플리케이션처럼 exe 파일로 빌드했다.)

서버

단순한 릴레이 서버.

big_mirror.png

넷코드

ZeroMQ 를 네트워크 라이브러리로 사용했다.

Continue reading