자바가 C(or C++?) 보다 8배 느리다?

C에 성능튜닝이 내가 좋아하는 갈 길이라고 살아가다가 비지니스급 코드를 보고 C로는 안되겠다고 생각하고 Java로 전향하였습니다.
Java에 성능튜닝이 내가 좋아하는 길로 알고 있습니다.

Sun이 팔팔할때는 Pure Java라는 솔루션이 많이 중요하게 언급이 되었지만 Oracle이 팔팔하니 Pure Java는 아키텍처적인 부분에서 언급이죠.
레이싱 레이서들이 달리기 선수일 필요는 없죠.

멀티쓰레드와 쓰레드풀을 달았습니다. 계산량이 적고 자원소요성이 아니다보니, 기존에 Java보다 성능이 눈꼽만하게 증가하는데 만족해야 했습니다만 그래서 저는 Java를 선호합니다.
쓰레드 클래스와 쓰레드 모니터 클래스가 2개 더 생겼습니다.

package cool;

import java.util.List;

public class Speed_K2 {
static boolean c1 = true, c2 = true;

public static void main(String[] args) {
long start = 0, end = 0;//, elapsed;
try {
Thread.sleep(5000L);
} catch (InterruptedException e) {
}

for (int k = 0; k < 5; k++) {
start = System.currentTimeMillis();
if (end == 0)
end = start;
doo((int) ((end - start) / 1000));
end = System.currentTimeMillis();
System.out.println("Elapsed time:" + ((end - start) / 1000.));
}
}

static public int doo(int in) {
int i;
int count = 5;
int n = 50000000;
int sum = 0;

CalcWorker.speedManager = new ResultCorrector(count);
n = n + in;
List solverThreads = CalcWorker.startThreads(count, n, c1);
for (i = 0; i < count; i++) {
solverThreads.get(i).doCalc(i, c2);
c2 = !c2;//이게 골치. 전역 참조여서 쓰레드 모니터 클래스로 제어가 힘든 변수.
}
CalcWorker.speedManager.waitAll();
return sum;
}
}

package cool;

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class CalcWorker extends Thread {
public static ResultCorrector speedManager;

private static List threadPool = Collections
. emptyList();

private static final int DO_NOTHING_STATUS = -2;
private static final int DO_WAIT_OR_DIE = -1;
private int workerNum = DO_NOTHING_STATUS;// -2 means first running.
private int differ;
private static int n;
private static boolean c1;
private boolean c2;

private List runningExList = new ArrayList();

private static void initThreadPool(int count) {
CalcWorker.threadPool = new ArrayList(count);
do {
CalcWorker worker = new CalcWorker();
worker.start();
CalcWorker.threadPool.add(worker);
} while (CalcWorker.threadPool.size() < count);
}

@Override
protected void finalize() throws Throwable {
this.destroyThreads();
super.finalize();
}

public synchronized void doCalc(int loverNum, boolean c2) {
this.differ = 0;
this.workerNum = loverNum;
this.c2 = c2;
this.notify();
}

@Override
public void run() {
try {
do {
if (this.workerNum != DO_NOTHING_STATUS) {
this.differ = CalcWorker.sum(this.differ, CalcWorker.n,
CalcWorker.c1, this.c2);
speedManager.summer(this.workerNum, this.differ);
}
this.workerNum = DO_WAIT_OR_DIE;// calcurate ended
synchronized (this) {
this.wait();
}
} while (this.workerNum != DO_WAIT_OR_DIE);
this.join();
} catch (InterruptedException e) {
this.runningExList.add(e);
}
}

private static int sum(int sum, int n, boolean c1, boolean c2) {
for (int j = 0; j < n; j++) {
if (c1 == true) {
if (c2 == true) {
sum++;
} else {
sum--;
}
}
}
return sum;
}

public static List startThreads(int count, int n, boolean c1) {
CalcWorker.n = n;
CalcWorker.c1 = c1;
if (CalcWorker.threadPool.isEmpty())
CalcWorker.initThreadPool(count);
return CalcWorker.threadPool;
}

private void destroyThreads() throws InterruptedException {
for (CalcWorker worker : CalcWorker.threadPool)
worker.doCalc(DO_WAIT_OR_DIE, this.c2);
if (!this.runningExList.isEmpty())
throw this.runningExList.get(0);
}
}

package cool;

public class ResultCorrector {

public static int sum;
private int workerNum;

public ResultCorrector(int count) {
this.workerNum = count;
}

public void waitAll() {
try {
while (this.workerNum > 0) {
synchronized (this) {
this.wait();
}
}
} catch (InterruptedException e) {
}
}

public void summer(int endedWorkerNum, int differ) {
synchronized (this) {
ResultCorrector.sum += differ;
this.workerNum--;
this.notify();
}
}
}

거의 10년 전 글이 어느 분께서 댓글 다셔서 메인으로 끌올 당했네요.
예전에 읽어 본 기억은 있지만 중간 중간 올려주신 새로운 댓글들도 많이 읽어보고..
지금은 개발로 먹고 사는 처지는 아니지만.. 돌이켜보면 많은 생각을 하게 합니다..
10년전쯤의 생각과 지금의 생각을 비교해보면 역시 언어의 우위나 일장일단을 캐내어 blame성 댓글을 유발하는 소모전에 치중하기 보다는..
전체적으로 프로젝트를 살펴 적절한 언어를 선택하는 것을 다 같이 토론해 보는 것이 더 발전적이지 않을까 하네요..
물론 위의 어느 분께서 말씀하셨듯이 언어의 선택과 퍼포먼스가 집약적으로 필요한 분야가 있기는 하지만.. 모두가 core 개발자는 아닐테니까요..
또한 그런 분야에서 일하시는 분들의 노고도 깎아내릴 생각은 전혀 없습니다.. 오히려 존경스럽지요.. 그런 분들의 노고가 발판이 되어 지금이 있을테니까요..
예전 netbsd 메일링리스트에서 P6코어의 memcpy()의 최적화를 놓고 설전을 벌이던 스레드가 문득 생각나는 하루입니다.
엔지니어로서, 개발자로서, 기획자로서.. 또는.. 더 나아가 어떤 회사의 오너로서.. 어떤 시야를 가져야 하는지 깊게 생각해봐야 할 것 같습니다..

> 자바자체가가 C언어로 만든 언어인데 C보단 빠를 수 없겠죠.
자바라는 언어는 그냥 스펙입니다. 구현물이 아닙니다. 자바언어를 구현한 java vm들중에 가장 널리쓰이는 오라클 java vm(hotspot)은 C++로 짜여져있습니다.

> 바로 함수주소 찾아서 호출하는 c보다는 이론상으로도 느릴 수 밖에 없음.
항상 꼭 그런것만은 아닙니다. 이것은 c++도 마찬가지인데, virtual과 dynamic typing등을 많이 쓰면 컴파일러들이 함수 호출주소를 컴파일타임에 쉽게 예측하지 못하기에,
branch prediction이 쉽지않아 CPU cycle이 낭비될수도 있습니다. 하지만 이것들도 인텔이나 AMD같은 하드웨어 제조사들이
지속적으로 기능을 추가해가서 개선되가고 있습니다. 가령 https://en.wikipedia.org/wiki/Branch_predictor#Prediction_of_indirect_jumps

다시말하자면, 함수주소를 동적으로 찾는것은 CPU레벨에서의 최적화에 단점
최적화를 좀 어렵게 만드는 부분이 있기에 성능저하가 나타날수 있는것이지, 마치 함수호출할때마다 정말 동적으로 맵같은 자료구조에서 함수주소를 찾고 그런것은 아닙니다.
그리고 정말 예측하기 어려운 virtual이 아닌이상, 컴파일러가 최대한 함수주소를 정적으로 바인딩합니다.
그리고 이것 마저도 하드웨어 제조사들이 점프 히스토리나 테그같은것을 cpu cache에 추가함으로서 점점 차이가 적어지고있습니다.
자바에서 성능저하가 많이 일어나는 부분중의 하나는 가비지 컬렉션입니다.

그리고 여태까지는 정적컴파일러들이 동적컴파일러들보다 더 성능이 좋은 실행파일들을 생성하고 있습니다만, 그 격차도 점점 줄어들고 있다고 봅니다.
이것은 꼭 단순히 성능비교만 할수 있는것은 아닌데, JIT는 정적컴파일링이 제공하지 못하는 부분들을 제공할수 있기때문입니다.