Oracle이 고려 중인 Java 9의 Unsafe API 제거 계획
Posted: July 15, 2015 Filed under: Code | Tags: java, Java9, Unsafe API Leave a comment성능이 중요한 꽤 많은 자바 프로젝트 (하둡 등 데이터 처리 프로젝트들 역시)이 Java Unsafe API에 의존하고 있다. Unsafe API는 JVM에서 공식적으로 제공하는 API가 아닌 Oracle JDK에서 내부적인 사용을 목적으로 제공하는 API이다. JNI와 다른 기술이며 콜 오버헤드 없이 직접 native 코드로 실행된기 때문에 빠르고, C 와 같이 메모리를 동적할당할 수 있으며 bounding check 없는 배열 접근 등 다소 위험하지만 성능 좋은 API를 100여가지 제공한다.
붙인 링크는 Oracle에서 JVM9 에서 Java Unsafe API 정말 제거하려는 계획과 지워질 경우 일어날 재앙에 대해서 언급한다. 아직까지는 계획일 뿐이고 계획을 직접 훑어보니 어느 정도의 대체 API도 고려하는 것 같기는 하다. 그럼에도 불구하고 그런일이 실제로 일어난다면 많은 자바 프로젝트들은 큰 변화를 겪어야 할 수 도 있다. 어쩌면 자바로 작성한 것이 의미가 없어질 정도로.. 어떤 프로젝트들은 헤비한 JNI 사용을 해야 할 것 이며 어떤 프로젝트들은 C++이나 기타 시스템 프로그래밍 언어로 이동을 해야 할지도 모르겠다.
해쉬 함수 구현 (hash function implementation) 링크 정리
Posted: May 25, 2015 Filed under: Code, Research | Tags: hash, hash function 1 Comment이것도 한 3-4년전에 정리했다가 가끔 업데이트 한 것 같은데… 나름 괜찮은 링크가 몇 개 있어 공유한다. 이것도 앞으로는 이 페이지에서 업데이트를 하겠다. 오래 지나다보니 인터넷에 있는 정보라도 링크가 깨진 것들이 많아 지웠는데 아쉽다. 다행히 이 페이지는 web archive에서 찾을 수 있어 다행이다 싶다.
General
- Which hashing algorithm is best for uniqueness and speed?
- Can one construct a “good” hash function using CRC32C as a base?
- CRC32가 hash table등을 위한 목적으로 좋은가? (키가 uniform distribution으로 나오는가?)
- State of the hash functions, 2012
- Hash Function
- 해쉬 함수 총정리 (강력 추천)
SW-based Implementations
- http://www.cse.yorku.ca/~oz/hash.html
- 단순한 해쉬 함수들 구현 소개 (바로 쓸 수 있는 코드들)
- Implementing SSE 4.2’s CRC32C in software
- SW 기반 HW 기반 코드 소개
- Benchmarking CRC32 and PopCnt instructions
- The Hash – 각종 hash 함수 소개 및 성능 평가
- MurmurHash – 최근 가장 빠른 성능의 해쉬함수 중 하나로 평가되고 있는 Murmur의 원구현 소스 (코드 읽기 쉬워 포팅 쉬움)
- xxHash – 현재 가장 빠르다고 주장되고 있는 해쉬 함수 구현
HW-based Implementations
- _mm_crc32_u64 poorly defined
- SSE4.2 제공 crc32 hashing 용례
- SSE4.2 and the new CRC32 instruction
- http://home.ustc.edu.cn/~shengjie/REFERENCE/sse4_instruction_set.pdf
- SSE4 instruction set reference
- Fast, Parallelized CRC Computation Using the Nehalem CRC32 Instruction
- Intel® SHA Extensions
float과 long 타입의 implicit casting
Posted: April 27, 2014 Filed under: Code, Tajo | Tags: Tajo Leave a comment4 byte 짜리 float이 8 byte 짜리 long보다 widen 더 넓은 범위를 표현하는 type 이었다. 지금까지 Tajo에서 float 과 long의 산술 연산에서 둘다 double로 casting 하고 처리했었는데 사실은 long을 float으로 casting 한 후 해야 IEEE 754에 기반한 결과가 나오는 것이었음.
- http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.2
- http://stackoverflow.com/questions/1293819/why-does-java-implicitly-without-cast-convert-a-long-to-a-float
- http://stackoverflow.com/questions/5563000/implicit-type-conversion-rules-in-c-operators
(4월 28일 Updated ) precision은 당연히 64bit인 long이 더 높다. 하지만 수의 표현 범위만 봤을 때는 float이 더 넓다. 따라서 float과 long의 산술 연산은 long이 float으로 implicit conversion 되어진 후 계산된다.
- float.MaxValue ~= 3.402823+e38
- long.MaxValue ~= 9.223372+e18
(4월 28일 Update 2) 정밀도(precision)의 차이가 낮기 때문에 int, long에서 float 또는 long에서 double로 변환될 때 값이 손실 될 수 가 있다. 그러나 항상은 아님.
A widening conversion of an
intor alongvalue tofloat, or of alongvalue todouble, may result in loss of precision – that is, the result may lose some of the least significant bits of the value. In this case, the resulting floating-point value will be a correctly rounded version of the integer value, using IEEE 754 round-to-nearest mode (§4.2.4).
Dive Into A Data Deluge 