세상 돌아가는 일에 눈막고 귀막은 사람이 누군지 모르겠소.
개발 도중에 속도 문제 때문에 C++로 바꿨다는 얘기는 들어봤소.
재작년에 개발자에게 직접 들은 얘기요.
그래봤자 별볼일 없을 거라고 지레짐작할까봐 덧붙이는데 그 제품 성공적으로 완료돼서 이번달에 출시되오.
그래도 그 개발자가 숏도 모르는 인간이기 때문이라고 우긴다면 편리한 사고방식이라고 할 수밖에 없구료.
두가지 성능이 모두 요구 되는 프로젝트였고 연산 성능때문에 처음에 C++로 개발하다가 기능 성능 문제로 자바(정확히는 하이브리드 구조로)로 돌아섰고
성공적으로 제품화 되어 몇만대 이상 팔려 나갔습니다.
내부평가에 의하면 연산 성능도 C++로 만들어진 모듈과 비교해서 5%정도 뒤쳐지긴 하지만 요구사항에는 충족되는 수준이였고요.
기능 성능쪽은 (주로 멀티 쓰래드 때문입니다만) C++로 구현했다면 유사한 기능성을 구현하는데 10개월 이상의 개발기간이 더 필요했을 거라는 결론 이였습니다.
물론 하부 인터넷 공유 기능이라던가 하는 부분은 C로 구현된 코드를 사용하는 하이브리드 구조였습니다.
-- 기능 성능쪽은 (주로 멀티 쓰래드 때문입니다만)
-- C++ 로 구현했다면 유사한 기능성을 구현하는데
-- 10개월 이상의 개발기간이 더 필요했을 거라는 결론 이였습니다
아니 멀티쓰레드 때문이라면 C++ 멸티쓰레드 라이브러리에는 무엇이 있는지 검색도 안해보셨나요.
그래놓고 "10개월 이상의 개발기간이 더 필요했을 것" 이라는 주장은 어떻게 할 수 있는지 참 용감하네요.
이럴 때 느끼는게 참 썬이 마케팅을 잘했다는 생각이 듭니다.
참 개발자를 게으르게 만드는 거 같습니다.
초창기에 "자바에는 포인터가 없다" 라는 태연한 거짓말로 시작을 했던 게 엊그제 같네요.
HW의 재부팅 및 소프트웨어의 중단없이
네크워크상에서 플러그인형태로 HW에 부착된 하드웨어의 제어 드라이버을 다운로드 받아서 설치하는 것과
별도의 서비스 서버에 실시간으로 상태 변화에 대한 보고 및 서비스 서버로 부터 명령을 받아 HW의 제어 및 서비스 기능의 제어,
동시에 TV와 PC를 위한 웹 서비스, 핸드폰을 위한 WAP 서비스, PDA를 위한 SOAP Service를 동시에 제공하면서
UPnP 기기 동작하여 PC에서 직접적인 접근이 가능하고,
5가지의 서로 다른 프로토콜로 동작하는 하부기기 컨트롤 네트워크를 모두 통합하며, 컨트롤 네크워크가 추가 되어도 재부팅 없이 자동으로 시스템이 확장될수 있어야 하는등..
통합해야 하는 쓰래드가 대단히 많았고 그것을 C++로 구현, 통합 하였을경우(저희 팀의 7년차 C/C++ 개발자의 분석이였습니다. )에 대한 분석이였습니다.
생산성으로 따지자면 C++보다 자바가, 자바보다는 파이썬루비등의 언어가 높다는 것은 이제 부인할수 없는 사실이라고 봅니다만..
자바는 중간적인 위치에 있고(C++보다는 생산성이 많이 높지만 파이썬루비보다는 많이 떨어지고, c/c++보다 조금 느리지만 파이썬루비보다는 많이 빠른)
이게 오히려 10년후를 보았을때 단점으로 작용할수도 있다라는(아주 강력한 로우레벨 언어와, 매우 유연한 하이레벨언어로 나누어질수 있다고 보니까요)것은 아직 예측일 뿐이고요. 그리고 그렇게 되더라도 자바언어는 죽을가능성이 있지만 자바플랫폼은 꽤나 오랫동안 살아 남을 가능성이 높고요. 아무튼 개인적인 예측일뿐입니다.
그리고 자바 언어에는 객체 레퍼런스만 있고 포인터가 없는 것은 거짓말이 아니라 사실입니다만..
자바에서 자바 언어와 플랫폼을 구분하지 못하고 계신 듯 싶습니다.
보통 네트워크에서 QoS 를 보장해야 하는 경우가 많습니다. BMT를 통과하려면 요구되는 성능을 맞춰 주는 한도에서 가장 가격이 싼 하드워어를 요구하는 경우가 대부분이니까요. (으. BMT 생각만해도 끔찍하군요. K*, SK* 두 회사 모두 정말 기가차서 말도 않나오게 가경을 깍으니까요. 그가격을 맞추는 하드웨어에서 QoS까지 하라고 요구하니.. 끔찍합니다. )
이런 경우에는 프로그램의 "속도"가 요구사항의 최우선 사항이므로 당연히 속도가 빠르게 나오는 언어를 선택해야겠죠.
자바가 덮어 놓고 C/C++보다 훨씬 느려서 실무에 무조건 못쓴다면 자바보다도 훨씬 느린 자바스크립트나 php 등은 아예 실무에 쓸 생각도 하지 말아야 하는 것 아닌가 하는 이야기입니다.
'실무'라는 게 어떤 분야인지, 또 성능 차이라는 게 구체적으로 어떤 사양에서 어떤 작업을 할 때 얼마나 차이가 난다는 건지, 또 그 차이가 해당 프로젝트에서 최소한의 요구조건을 충족시키는 지 등등을 따져 봐야만 의미가 있다는 걸 이해 못하는 사람들이 '실무' 운운하는 것 같아 예를 든 것 뿐입니다.
누가 자바스크립트나 PHP가 자바보다 느리다던가요? ㅋㅋ 덮어놓고 훨씬 느리다 하시네요..
다른 사람들이 덮어놓고 자바는 C보다 느리다고 생각하는것과 같은 건가요?
그런데 C에서 유저레벨에서 메모리 관리하는 상태로 자바랑 비교된 예가 있나요? 그냥 간단하게 APR(Apache portable runtime)에 있는 해쉬테이블 놓고 자바의 그것과 성능 비교 하면 8배까지는 아닐지라도 꽤 차이가 날 듯 한데요? APR은 메모리 풀을 유저레벨에서 관리하고 라이브러리에서 해쉬테이블을 지원해 주니까요. 비교해보면 적절할 것 같은데.. 펜4 1.7기가 싱글 시퓨에서 400만건 넣어놓고 싱글 프로세스로 초당 30만 쿼리 이상 처리했었습니다.. 나중에 멀티 시퓨에서 쓰레드에서 돌릴때는 70만 넘게 나왔습니다.. 시스템 로드도 널널~
물론 자바로도 성능 좋은걸 만들어 낼 수 있다는걸 압니다. 요글에 썼는지 기억은 안나지만 가장 빠른 웹서버로 랭크된 놈이 자바로 만들어졌다고 알고 있습니다. 만든 사람이 "자바로 만들긴 했지만 언어의 이점은 없다. 웹서버에서 가장 중요한건 IO전략이다." 라고 했죠..
누가 뭘 만들었냐가 관건이지 언어가 무슨 소용입니까? C도 레고같아요. 필요한 기능 붙이고 비즈니스로직만 만들어주면 됩니다. 누가 C가 유지보수나 개발이 어렵다고 하나요?? 언제적 얘기 하는지 모르겠습니다 -.-
그리고 왜 자바가 자바스크립트나 PHP보다 훨씬 빠르다고 생각하시죠??
PHP와의 속도 얘기로는 오래전부터 논란의 대상이었지만 자바스크립트는 얘기가 다릅니다;;
인터프리터를 선택할 수 있기 때문인데요.. 어떤놈을 선택하느냐에 따라 성능이 천차만별인걸요? ECMA Script 인터프리터들은 널렸으니까요. 자바버전의 자바스크립트 인터프리터도 있는데 이게 느리다면요? 자바가 느린건가요 ECMA Script라는 언어의 표준에 느리라고 뭐가 되어 있는건가요? -_-;;
"a pointer is a programming language datatype whose value refers directly to (“points to”) another value stored elsewhere in the computer memory using its address." -- 위키페디아(http://en.wikipedia.org/wiki/Pointer)
포인터는 어떤 데이터의 메모리에 직접 접근할수 있다는 매우 강력한 기능이지만, 메모리에 직접 접근하기 때문에 발생하는 오작동의 문제역시 매우 커질수 있는 양날의 검입니다.
레퍼런스는 객체를 가르키는 데이타 타입이고 C++에서는 이 역시 메모리 주소를 기반으로 합니다.
"references are datatypes which refer to an object elsewhere in memory, and are used to construct a wide variety of data structures such as linked lists. Most programming languages support some form of reference." -- 위키페디아(http://en.wikipedia.org/wiki/Reference)
하지만 자바의 객체 레퍼런스는 어디까지나 참조의 역활을 할뿐 메모리 주소와는 상관이 없습니다. 핸들러라고도 볼수 있겠습니다만, 자바프로그래밍에서 레퍼런스를 사용하면 참조하고 있는 객체에 바로 접근하게 되기 때문에 레퍼런스의 실제 값을 볼수 있는 방법은 없습니다. 그래서 그냥 "객체를 건드린다"라는 감각으로 레퍼런스를 사용하면 그만입니다.
자바의 객체 레퍼런스는 메모리에 직접 접근하는 방법이 아니기 때문에 추가 비용이 필요합니다만(최근의 JVM은 이런 부분을 최적화 했기 때문에 사실상 비용이 거의 들지 않습니다) 메모리를 좀더 안전하게 쓸수 있다라는 점은 분명히 장점이 되었고, 많은 환영을 받은 방식입니다.
이와같이 자바 언어는 객체 레퍼런스만을 지원하고 있고, 자바 프로그래머는 자바 언어를 사용하기 때문에 포인터에 의한 메모리 누수 같은 걱정을 않하고 프로그래밍을 할수 있습니다.
그리고 자바 플랫폼(JVM)은 자바 프로그래머가 만든 클래스(.class)파일을 실행 시키며 내부적으로 최적화를 위해 메모리를 직접 건드리겠죠. 만약 자바 플랫폼이 C/C++로 만들어 졌다면, 내부적으로 포인터를 사용했을 가능성이 높겠죠. 하지만 다른 언어로 만들어진 자바 플랫폼이라면 포인터가 아니라 다른 무언가를 사용하였겠죠.
여태까지 설명 드린것 처럼, 자바 언어와, 플랫폼을 구분하지 않고 자바 레퍼런스는 포인터다라고 말하는 것은 잘못된 것입니다.
요약하자면,(대부분의 토론 대상이 되는) 자바 언어에서 객체 레퍼런스는 메모리와 관련있는 개념이 아니고, 자바 언어상 레퍼런스의 실제 값을 알아 낼수 있는 방법도 존재 하지 않는 객체에 대한 참조일뿐입니다.
과연 이게 얼마나 중요한 논제인가요?
Java를 하시는 분은 C++보다 Java가 빨라서 쓰시는 분들도 아닐테고
해당 분야에서 필요로 해서 쓰는 것 아닌가요?
제가 Java를 안해서 뭐라 드릴 말씀은 없지만, 어느 개발 site를 가더라도
잊을만 하면 올라오는게 "Java는 C++보다 몇배까지는 느리지 않다, 혹은 더 빠르다."
개발 3년차에 들어선 지금 2002년, 2003년 대학다닐때 쯤 보던 논쟁거리를 몇년 지나 다시 보는 지금
비생상적이라는 생각밖에 안드네요.
가끔은 자신이 쓰는 언어가 절대적이다라는 논리에 사로 잡혀 남이 다른 언어를 쓰거나 해당 언어가 좋다. 성능이
괜찮다. 라는 말만 들으면 눈이 뒤집히시는 분들도 계시는데, 정신건강에 그다지 좋지 않습니다.
한가지 덧붙여 Java를 쓰던 대학동기가 인공지능 강의시간에 추론엔진 라이브러리(어디서 개발했는지 기억은 안남)를 소개하는데,
왜 그 라이브러리는 Java를 지원하지 않느냐 따지던 생각이 나는군요.
따지고 보면 그 당시엔 전혀 중요하지 않은 일인데 말이죠.
쉽게 하드웨어쪽에서 C/C++ 주로 사용된는 것과 같은 얘기겠죠.
ActiveX 같은 경우 개발의 편의성 덕에 델파이가 개발 언어로 자주 사용 됬습니다.
어셈블러, 코볼등의 언어들도 현재까지 사용되는 것은 물론이고
포트란 역시 지금까지 과학 수치연산에 많이 사용되죠.
자바는 웹어플리케이션이라는 영역을 차지하고 있는 것과 마찬가지로
-- 하지만 자바의 객체 레퍼런스는 어디까지나 참조의 역활을 할뿐 메모리 주소와는 상관이 없습니다.
-- 핸들러라고도 볼수 있겠습니다만,...
아 '핸들러'라고 하니까 자바가 추구하는 것에 아주 가깝게 들립니다.
명쾌한 지적이셨읍니다.
-- "자바는 전반적으로 많이 느리다" ->
-- "자바는 상당히 빨라졌다" ->
-- "자바는 대부분의 실무에 쓰기에 문제 없을 정도로 빨라졌다" ->
-- "자바는 이제 일부 영역에서 C/C++보다 빨라졌다.나머지 영역에서도 C/C++의 성능에 상당히 접근했다."
-- 라는 식으로 "현재 상황 비교"가 변천되어 왔죠.
-- 그리고 저 마지막 결론이 나온것은 JDK 1.3에서 1.4로 넘어가는 시절입니다. ...
그게 마지막 결론이었다구요. 누구의 결론이었나요.
그럼 JVM 기술이 그만큼 발달했다면, C/C++ 쪽에서는 프로그램적으로
어디까지 최적화할 수 있는 지 생각해 보셨읍니까.
-- 하지만, 현실을 아예 무시하고 자기 주장만 하는 사람들이 정말 많지요.
그런 생각을 아예 하지도 않고 "자바는 이제 일부 영역에서 C/C++보다 빨라졌다" 고 여전히 주장하실래요
전형적인 아전인수격인 사람들이 정말 많네요.
"자바는 이제 일부 영역에서, (시간관계로 최적화를 고려하지 않은) C/C++ 보다 빨라졌다" 면 그것은 말이 됩니다.
-- 현실이 이런데 왜 이런 결과가 나왔냐? 어떻게 하면 그 노하우를 배울수 있을 것인가?
-- 이런 논쟁이 좀 일어 났으면 좋겠습니다.
JVM 의 최적화 뿐만 아니라 C/C++ 쪽의 최적화도 눈을 돌릴 수 있는 논쟁이 좀 일어 났으면 좋겠읍니다.
-- 자바와 같이 동적 최적화를 할 수 있는 언어가 일부 상황에서
-- 빠르다는 것을 아직도 부정하시는 분이 계신다는게 신기합니다.
C/C++ 의 최적화가 정확히 들어가면, 동적 최적화를 하는 언어라 할지라도
일부에서조차 속도를 따라 잡기란 극히 어려운 일이라는 것을
아무도 믿으려 하지 않는 것도 참 신기합니다.
저는 자바에 대해 일종을 공포를 가지고 있읍니다.
제 컴에 이클립스를 깔아서 사용할려고 했는데 시스템이 버벅거려 도저히 쓸 수가 없었어요.
RAM 이 256 이었읍니다. 요즘 세상에 256 RAM 을 누가 쓰냐고 그러겠지만 좀 가난해서
어쩔 수 없었어요. 그 때 고사양(?)을 요구하는 자바란 것이 두렵게 느껴지더군요.
그래서 자바로 하면 지원되는 방대한 라이브러리로 하루 이틀이면 끝날 것을
1 주일 넘게 C/C++ 로 맨땅에 헤딩하면서 작업을 해왔읍니다.
그러고 보면 C/C++ 은 힘없고 가난한 사람들이나 쓰는 도구 같습니다.
결국 C/C++ 은 빈민층용, JAVA 는 부유층용 정도로 생각하면 될 것 같습니다.
부유층용이라는 것은 JAVA 를 충분히 가동시킬 만한 상황을 의미하는 것이지
그 이상의 의미는 없습니다.
그 놈의 C++ 은 또 왜 이렇게 어려운지 지금도 문법 책 펴놓고 낑낑대고 있네요.
한편으론 자바하는 분들은, 어쩔 수 없이 C/C++ 로 처리해야 하는 저 같은 사람도 있다는 것으로
충분히 행복해 해도 좋을 것 같습니다.
정말 C/C++ 은 가급적 하지 마시기 바랍니다.
납기일은 내일인데 메모리 누수때문에 개피본다는게 어떤 건지 안당해보면 몰라요.
>> 뭐 온갖 종류의 최적화를 일일히 다 해주신다면야 당연히 C/C++이 무조건 더 빠르겠죠.
이게 제가 쓴 글입니다. 애시당초 인정하고 들어 가고 있습니다만.. 부디 남의 글을 제대로 읽어 주세요.
>> 그게 마지막 결론이었다구요. 누구의 결론이었나요.
각 시기별로 여러 플레임들의 결과였지요. 저는 이런 플레임을 십몇년째 보아오고 있습니다.
>> 그럼 JVM 기술이 그만큼 발달했다면, C/C++ 쪽에서는 프로그램적으로
>> 어디까지 최적화할 수 있는 지 생각해 보셨읍니까.
이미 충분히 알고 있습니다. 실제로 저는 CPU 캐시 사이즈에 한번에 들어갈수 있는 코드 사이즈라는 영역까지 최적화를 수행하는 C 프로젝트를 수행해 보았습니다.
그리고, 현제 최고로 성능이 좋은 JVM 역시 C/C++로 제작되었다는 사실도 잘 압니다.
>> C/C++ 의 최적화가 정확히 들어가면, 동적 최적화를 하는 언어라 할지라도
>> 일부에서조차 속도를 따라 잡기란 극히 어려운 일이라는 것을
>> 아무도 믿으려 하지 않는 것도 참 신기합니다.
예, 현재까지는 기술적으로 맞는 말입니다. 위에서 적었듯이 저는 믿습니다.
반면에 C/C++이 최적화가 아무리 들어가도 (인라인 어셈을 대규모로 집어넣기전까지는) 대규모 과학연산에서 포트란을 따라잡지 못한다는 것도 잘압니다.
프로그래밍 레벨의 최적화 정말 할수 있다면 좋겠지요.
하지만, 회사가 정말 돈이 많고, 경영진이 완전히 최적화된 SW가 아니면 출시할수 없다라는 경영지원을 해주는 프로젝트라면 가능하겠지만, 그런 회사는 거의 없고, 그렇게 때문에 최적화를 정확히, 완전하게 수행하는 프로젝트는 사실상 없다라는 사실도 잘압니다.
그래서 좋은 컴파일러 쓰려고 하는거 아니겠습니까?. 조금이라도 더 자동으로 최적화 해주는, 더 빠른 실행코드를 만들어 내는 컴파일러 말입니다.
>> 정말 C/C++ 은 가급적 하지 마시기 바랍니다.
>> 납기일은 내일인데 메모리 누수때문에 개피본다는게 어떤 건지 안당해보면 몰라요.
저도 납기일 당일 데모하는데 메모리 누수때문에 뻑 죽는 프로그램을 만들어 봐서 압니다. 아주 미칠 노릇이죠. 왜 회사에서는 잘 되다가, 데모만 하면 죽는지... -_-
저같은 경우는 임베디드와 엔터프라이즈 중간에 딱 끼어 있는 사람입니다. 임베디드 시스템을 만들면서, 이 시스템이 엔터프라이즈 시스템과 통합시키는 관리 서버까지 모두 만들어 봤죠.
그래서 내린 결론은 간단합니다. 생산성이 좋은 언어를 사용하자. 메모리관리를 자동으로 해주는 언어를 사용하자.
조엘온소프트웨어에서 나온 글에 저도 찬성합니다. SW 개발의 생산성 향상은 메모리 관리의 자동화에서 주로 발생합니다.
>> 1 주일 넘게 C/C++ 로 맨땅에 헤딩하면서 작업을 해왔읍니다.
>> 그러고 보면 C/C++ 은 힘없고 가난한 사람들이나 쓰는 도구 같습니다.
하시는 것이 속도가 그렇게 중요한 일이 아니면 한번 파이썬을 시도해보시는 건 어떻겠습니까?
개인적으로 상당히 추천할 만한 언어입니다. 높은 시스템을 요구하는 것도 아니고요.
하지만, 여전히 수동으로 프로그래머가 코딩을 해줘야 하고, 스마트포인터를 사용하지 않는 라이브러리와 연결해야 한다던지, 서로 다른 팀에서 만들어지는 모듈들의 서로 다른 메모리관리 방식이라던지(성능을 중요시 하는 프로그래머는 스마트포인터 잘 않쓰더군요), 작은 데이터를 위해서는 쓰기 어렵다던지, 여전히 포인터 연산을 잘못하면 Illegal Memory access가 뜬다던지.....
개인수준에서 만들수 없는, 팀단위의 프로그래밍에서는 여전히 심각한 문제가 됩니다.
그래서 내린 결론은 선택사항인 메모리 관리는 팀 전체가 받아들일수 있다면 좋지만, 그렇지 못할때는 강제적인 자동메모리 관리가 훨씬 좋다. 입니다.
그럼 될 수 있으면 C/C++ 보다는 자바로 가야하는 것 아닐까요.
교육을 해서라도 자바로 가야지 자바를 못한다고 C/C++ 을 고수한다면
프로젝트 막판에 등장하는 무시무시한 잘못된 메모리 참조는 막을 길이 뚜렷하게 안보입니다.
요즘은 3D 나 게임도(그리고 대부분의 분야에서) 자바로 웬만큼 속도가 나온다는데
더 이상 C/C++ 을 쓴다는 것은 어리석지 않을까요.
저도 이제부터 C 를 때려치고 java 를 해야 될 것 같습니다.
저처럼 C/C++ 은 조금 아는 사람이 볼만한 자바 입문서로는 무엇이 있을까요.
그럼간단히 스트링내의 원하는 문자 제거하는 함짜보세여 예를들면 스페이스라던가..
아니그냥 간단히 "skdkglsldslfldsf dskfkfsls ** dflsdf" d 제거하여 "skkglslslflsf skfkfsls ** flsf" 요렇게 되는거 만들어보셔요. 말만하지마시고. 얼마나 쉽게 되나 함바여..
"세세한 부분의 동작 원리"는 밑으로 내려가자면 끝도 없습니다. 어떤 분들은 단순히 계산 속도를 빨리하기 위해서 비디오 카드에 있는 메모리에 접근하는 기법을 쓰시더군요. 살면서 그런 식으로 해야할 일이 얼마나 있는지는 의문입니다. 물론 그런 일을 해야할 사람은 C를 배워야 하겠습니다만.
자바는 문서에 메쏘드 이름만 있으면 문법 무시하고 아무 위치에나 쓰면 되는 모양이네요 -_-;
함수 원형을 보고 짜야지 프로그램이 돌아가는게 당연한거 아닙니까
아 글케 자신 있으면 진짜 실무에 쓰인 코드로 성능 테스트 해보던가요 -_-;;
자바로 실무 한것중에 성능에 의존적인거 어떤거 있나요? 코드 보여줘보세요. 제가 C로 짤테니 여기저기서 돌려보죠?
특별한거 없으시면 간단한 구조체 같은걸 해쉬테이블로 메모리에 랜덤하게 500만개 쯤 넣어놓고 랜덤하게 1000만번 찾아서 업데이트 하는거 구현해 보실까요? 자바에도 해쉬테이블 있으니까요. 아님 서버간 통신? 어떤거라도 아 성능 의존적인 실무에서 쓸만하구나 싶은걸로 단위 기능 정도로 고르시죠 바쁘니까..
예를 들어
사용자로부터 입력받은 5바이트의 문자열이 있을때,
C 프로그램을 이를 힙메모리에서 6바이트(Null문자포함)를 할당하게 됩니다.
그런데 메모리 재할당 없이 님의 함수를 통해 그중에 3바이트만(3글자를 버렸을때) 남기게 되면,
프로그램 내부적으로는 재할당이나 release가 없었기 때문에 여전히 6바이트만큼의 메모리가 사용되게 있다고 프로그램이 판단하게 됩니다. 따라서 힙메모리에서 (님의 함수에 의해 버려진) 3바이트에 해당하는 메모리를 더이상 쓰지 않게 되며, 메모리 누수가 발생하게 됩니다.
네 전 다 압니다. 어쩌라구효?
자바의 메모리 관리요.. 좋은지 알고 있습니다. C만큼은 아니지만 자바로도 실무 프로젝트 하고 그랬거든요? C에서는 메모리 관리 못 접해보셨나봐요? APR써보세요
프로세스가 실제로 얼마의 메모리를 차지하는지 RSS를 한번 보세요 어떤놈이 같은 작업에 메모리를 더 쓰는지
자바진영이 그런
자바진영이 그런 별것도 아닌것혹은 설사 자체적으론 개선효과가 있다하나 다른언어에비해 효과는 떨어지는것을
대단한양 크게 떠벌리는 경향이 있습니다.
상술적이라 보이는그런..
자바진영이 그런
자바진영이 그런 별것도 아닌것혹은 설사 자체적으론 개선효과가 있다하나 다른언어에비해 효과는 떨어지는것을
대단한양 크게 떠벌리는 경향이 있습니다.
상술적이라 보이는그런..
자바진영이 그런
자바진영이 그런 별것도 아닌것혹은 설사 자체적으론 개선효과가 있다하나 다른언어에비해 효과는 떨어지는것을
대단한양 크게 떠벌리는 경향이 있습니다.
상술적이라 보이는그런..
아직도 속도
아직도 속도 타령이라니 --;
반대로 물어봅시다.
자바로 프로젝트를 수행했는데 속도때문에 망했다는 이야기 들어본적 있소?
한 5년전에는 가끔 그런소리가 있긴 했지만 (것도 사실 자바 숏도 모르는것들이 대충 C처럼 짜가지고 그런거지만)
지금은 그런소리하면 숏도 모르는 인간 취급 당하기 일수요. (인제 자바는 리얼타임 환경에도 등장하고 있소)
멀 할지에 따라 물론 자바가 좋을수도, C가 좋을수도 있긴 하지만
자바로 하다가 망쳣다면
그건 정말 자바를 숏도 모르기 때문이란걸 명심하시오.
자바가 수년간 이룩한 거대한 플렛폼은
미안한 말씀이지만 'C로 최적화를 하면 자바보다 빠르니 머니' 이런 소리하곤 전혀 차원이 다른것이란말이오
인제 좀 세상돌아가는것에 눈좀 뜨시길...
세상 돌아가는 일에
세상 돌아가는 일에 눈막고 귀막은 사람이 누군지 모르겠소.
개발 도중에 속도 문제 때문에 C++로 바꿨다는 얘기는 들어봤소.
재작년에 개발자에게 직접 들은 얘기요.
그래봤자 별볼일 없을 거라고 지레짐작할까봐 덧붙이는데 그 제품 성공적으로 완료돼서 이번달에 출시되오.
그래도 그 개발자가 숏도 모르는 인간이기 때문이라고 우긴다면 편리한 사고방식이라고 할 수밖에 없구료.
속도 및 비용 문제 때문에 자바로 바꾼 케이스도 있습니다.
물론 제가 말하는 것도 상용화되어 이미 몇만대 팔려나간 시스템입니다.
연산 성능(일반적인 퍼포먼스)과 기능 성능(여러 기능이 동시에 동작해야 하는 성능)
두가지 성능이 모두 요구 되는 프로젝트였고 연산 성능때문에 처음에 C++로 개발하다가 기능 성능 문제로 자바(정확히는 하이브리드 구조로)로 돌아섰고
성공적으로 제품화 되어 몇만대 이상 팔려 나갔습니다.
내부평가에 의하면 연산 성능도 C++로 만들어진 모듈과 비교해서 5%정도 뒤쳐지긴 하지만 요구사항에는 충족되는 수준이였고요.
기능 성능쪽은 (주로 멀티 쓰래드 때문입니다만) C++로 구현했다면 유사한 기능성을 구현하는데 10개월 이상의 개발기간이 더 필요했을 거라는 결론 이였습니다.
물론 하부 인터넷 공유 기능이라던가 하는 부분은 C로 구현된 코드를 사용하는 하이브리드 구조였습니다.
-- 기능 성능쪽은
-- 기능 성능쪽은 (주로 멀티 쓰래드 때문입니다만)
-- C++ 로 구현했다면 유사한 기능성을 구현하는데
-- 10개월 이상의 개발기간이 더 필요했을 거라는 결론 이였습니다
아니 멀티쓰레드 때문이라면 C++ 멸티쓰레드 라이브러리에는 무엇이 있는지 검색도 안해보셨나요.
그래놓고 "10개월 이상의 개발기간이 더 필요했을 것" 이라는 주장은 어떻게 할 수 있는지 참 용감하네요.
이럴 때 느끼는게 참 썬이 마케팅을 잘했다는 생각이 듭니다.
참 개발자를 게으르게 만드는 거 같습니다.
초창기에 "자바에는 포인터가 없다" 라는 태연한 거짓말로 시작을 했던 게 엊그제 같네요.
멀티 쓰래드 자체보다는..
HW의 재부팅 및 소프트웨어의 중단없이
네크워크상에서 플러그인형태로 HW에 부착된 하드웨어의 제어 드라이버을 다운로드 받아서 설치하는 것과
별도의 서비스 서버에 실시간으로 상태 변화에 대한 보고 및 서비스 서버로 부터 명령을 받아 HW의 제어 및 서비스 기능의 제어,
동시에 TV와 PC를 위한 웹 서비스, 핸드폰을 위한 WAP 서비스, PDA를 위한 SOAP Service를 동시에 제공하면서
UPnP 기기 동작하여 PC에서 직접적인 접근이 가능하고,
5가지의 서로 다른 프로토콜로 동작하는 하부기기 컨트롤 네트워크를 모두 통합하며, 컨트롤 네크워크가 추가 되어도 재부팅 없이 자동으로 시스템이 확장될수 있어야 하는등..
통합해야 하는 쓰래드가 대단히 많았고 그것을 C++로 구현, 통합 하였을경우(저희 팀의 7년차 C/C++ 개발자의 분석이였습니다. )에 대한 분석이였습니다.
멀티 쓰래드 라이브러리야 많이 알고 있었습니다만, 이정도의 서로 다른 쓰래드의 통합은 메모리 관리와 더불어, 경쟁조건의 관리가 너무나 큰 문제가 되었습니다.
저희쪽에서 최종적으로 채택한 것은 CSP(Communicating Sequential Processes)의 자바 버전인 JCSP(http://www.cs.kent.ac.uk/projects/ofa/jcsp/)를 사용했습니다.
(CSP에 대한 간단한 소개는 http://xper.org/wiki/seminar/CommunicatingSequentialProcesses)
생산성으로 따지자면 C++보다 자바가, 자바보다는 파이썬루비등의 언어가 높다는 것은 이제 부인할수 없는 사실이라고 봅니다만..
자바는 중간적인 위치에 있고(C++보다는 생산성이 많이 높지만 파이썬루비보다는 많이 떨어지고, c/c++보다 조금 느리지만 파이썬루비보다는 많이 빠른)
이게 오히려 10년후를 보았을때 단점으로 작용할수도 있다라는(아주 강력한 로우레벨 언어와, 매우 유연한 하이레벨언어로 나누어질수 있다고 보니까요)것은 아직 예측일 뿐이고요. 그리고 그렇게 되더라도 자바언어는 죽을가능성이 있지만 자바플랫폼은 꽤나 오랫동안 살아 남을 가능성이 높고요. 아무튼 개인적인 예측일뿐입니다.
그리고 자바 언어에는 객체 레퍼런스만 있고 포인터가 없는 것은 거짓말이 아니라 사실입니다만..
자바에서 자바 언어와 플랫폼을 구분하지 못하고 계신 듯 싶습니다.
ㅋㅋㅋㅋㅋㅋ
멀 만드셧길래. '속도'때매 씨뿔라뿔라로 바꾸셧을까...
궁금하네 ㅋㅋㅋㅋ
속도 문제때문에 C/C++로 하는 경우는..
보통 네트워크에서 QoS 를 보장해야 하는 경우가 많습니다. BMT를 통과하려면 요구되는 성능을 맞춰 주는 한도에서 가장 가격이 싼 하드워어를 요구하는 경우가 대부분이니까요. (으. BMT 생각만해도 끔찍하군요. K*, SK* 두 회사 모두 정말 기가차서 말도 않나오게 가경을 깍으니까요. 그가격을 맞추는 하드웨어에서 QoS까지 하라고 요구하니.. 끔찍합니다. )
이런 경우에는 프로그램의 "속도"가 요구사항의 최우선 사항이므로 당연히 속도가 빠르게 나오는 언어를 선택해야겠죠.
개그야 보다 이
개그야 보다 이 쓰레드 읽는게 더 재밌네요..
몇몇 익명분들 글은 폭소를 자아내기도 하고..ㅋ
아주 시간가는줄 모르겠습니다..
젠투 사운드 설정해야 되는데.. ㅠ
고기맛을 알아버린 스님 !!!
자바는 느려서
자바는 느려서 실무에 못쓴다는 분들은 php로 된 사이트나 웹 브라우저에 뜨는 자바 스크립트는 어떻게 참고 쓰는 지 모르겠군요.
어떻게 참긴요. 그냥
어떻게 참긴요. 그냥 참는 거죠.
전 보통때는 시간 자바 먹는 자바 스크립트, 애플릿은 꺼놓고 씁니다.
역시 AJAX는 실무에
역시 AJAX는 실무에 못쓸 물건이었군요.
자바는 느려지
자바는 느려지 않아서 실무에 써도 전혀 이상 없다는 분들은
자바로 OS 한 번 만들어 보시지요. Windows Java OS 2008 쯤 ^^
'실무'는 OS만
'실무'는 OS만 만드나보죠?;
OS 는 못만드는
OS 는 못만드는 자바처럼
OS 는 못만드는 파이선이나 러비, 펄,PHP 로
실무 프로그램을 만들어도 C/C++ 보다 느리지 않겠네요.
참 좋은 세상에 사시는가 부죠.
커널 프로그래밍은
커널 프로그래밍은 '실무'가 아닌가부죠
일부분이죠.
"실무에 못쓴다"
라는 주장은
"(모든) 실무에 못쓴다"
라는 주장입니다.
거기에 대해서
"(많은수의, 혹은 대다수의) 실무에 쓸수 있다"
라는 주장이 대립되고 있는 거죠.
만약 처음 주장이
"(아무리 그래도 일부) 실무에는 못쓴다"
라는 주장이였다면
누구라도
"당연하다. (업무에 맞는 언어가 아니라면 당연히 못쓴다)"
라는 반응이였겠지요.
하지만 제가 보기에 저 글은 쓰신 분은 첫번째 의도로 쓰셨다고 보입니다.
그리고 자바로 커널 프로그래밍 됩니다.
자꾸 자바를 언어쪽으로만 생각하시는 분들이 많으신데,
최근 몇년간 자바의 핵심적인 발전은 모두 자바 플랫폼입니다.
자바 플랫폼에서 이루어진 발전으로 인해
모토롤라나 노키아같은 회사의 핸드폰 플랫폼이나
MHEG등의 IPTV 표준등이 자바 기반이 될수 있었던 것입니다.
특히 모토롤라, 노키아 같은 경우에는 자바 플랫폼이 바로 커널이 되는 형태입니다.
J2ME를 단순히 핸드폰용 게임 만드는 거로만 생각하시는 분들이 많으신데 아닙니다^^
님은 플랫폼과
님은 플랫폼과 프로그래밍을 구분도 못하세요?
이미 플랫폼을 벗어나서 돌아가거나 플랫폼자체는 자바프그래밍이 아니란걸 모르셈?
그럼저는 M$윈도우도 만든다우..
커널의 기능을 자바 기반으로 확장할수 있게 되어 있지요.
아마 이해 하기 어려우실 텐데,
모토롤라나 노키아의 경우 플랫폼이 매우 유연한 구조로 되어 있어서, 플랫폼 자체를 확장시킬수 있게 되어 있습니다.
물론 이때 C로 된 코드나 자바로 된 코드나 모두 이용하여 플랫폼을 확장시킬수 있게 되어 있지요.
뭐, 윈도우에서 드라이버 같은 유사하다고 생각하시면 됩니다. (윈도우 비스타에서는 드라이버가 드디어 유저 레벨로 나왔지만, XP 까지는 커널레벨에서 드라이버가 동작되었지요)
그렇게 구성된 플랫폼에서 다른 프로그래머들이 어플리케이션을 제작할수 있게 되어 있고요.
그러면서 플랫폼 레벨에서 SOA 가 가능하도록 되어 있지요. 각 어플리케이션 간에 서비스(웹서비스가 아닌 자바객체서비스)에 기반한 SOA 프로그래밍이 가능하게 되어 있습니다.
자세한 것은 모토롤라, 노키아가 공히 기반 플랫폼으로 사용하는 OSGi(http://www.osgi.org ) 를 참고하시기 바랍니다.
모토롤라와 노키아가 하고 있습니다.
모토롤라와 노키아가 하고 있습니다. 모토롤라와 노키아 공히 자바기반의 플랫폼이 모토롤라와 노키아의 차세대(이미 제품이 출시 되고 있습니다) 핸드폰의 기본 플랫폼입니다.
자바스크립트와
자바스크립트와 자바는 완전히 다른놈입니다.. 이름이 비슷하다고 같은 맥락으로 보시면 곤란합니다
음... 의도를 이해
음... 의도를 이해 못하신 듯...
자바가 덮어 놓고 C/C++보다 훨씬 느려서 실무에 무조건 못쓴다면 자바보다도 훨씬 느린 자바스크립트나 php 등은 아예 실무에 쓸 생각도 하지 말아야 하는 것 아닌가 하는 이야기입니다.
'실무'라는 게 어떤 분야인지, 또 성능 차이라는 게 구체적으로 어떤 사양에서 어떤 작업을 할 때 얼마나 차이가 난다는 건지, 또 그 차이가 해당 프로젝트에서 최소한의 요구조건을 충족시키는 지 등등을 따져 봐야만 의미가 있다는 걸 이해 못하는 사람들이 '실무' 운운하는 것 같아 예를 든 것 뿐입니다.
누가 자바스크립트나
누가 자바스크립트나 PHP가 자바보다 느리다던가요? ㅋㅋ 덮어놓고 훨씬 느리다 하시네요..
다른 사람들이 덮어놓고 자바는 C보다 느리다고 생각하는것과 같은 건가요?
그런데 C에서 유저레벨에서 메모리 관리하는 상태로 자바랑 비교된 예가 있나요? 그냥 간단하게 APR(Apache portable runtime)에 있는 해쉬테이블 놓고 자바의 그것과 성능 비교 하면 8배까지는 아닐지라도 꽤 차이가 날 듯 한데요? APR은 메모리 풀을 유저레벨에서 관리하고 라이브러리에서 해쉬테이블을 지원해 주니까요. 비교해보면 적절할 것 같은데.. 펜4 1.7기가 싱글 시퓨에서 400만건 넣어놓고 싱글 프로세스로 초당 30만 쿼리 이상 처리했었습니다.. 나중에 멀티 시퓨에서 쓰레드에서 돌릴때는 70만 넘게 나왔습니다.. 시스템 로드도 널널~
물론 자바로도 성능 좋은걸 만들어 낼 수 있다는걸 압니다. 요글에 썼는지 기억은 안나지만 가장 빠른 웹서버로 랭크된 놈이 자바로 만들어졌다고 알고 있습니다. 만든 사람이 "자바로 만들긴 했지만 언어의 이점은 없다. 웹서버에서 가장 중요한건 IO전략이다." 라고 했죠..
누가 뭘 만들었냐가 관건이지 언어가 무슨 소용입니까? C도 레고같아요. 필요한 기능 붙이고 비즈니스로직만 만들어주면 됩니다. 누가 C가 유지보수나 개발이 어렵다고 하나요?? 언제적 얘기 하는지 모르겠습니다 -.-
그리고 왜 자바가 자바스크립트나 PHP보다 훨씬 빠르다고 생각하시죠??
PHP와의 속도 얘기로는 오래전부터 논란의 대상이었지만 자바스크립트는 얘기가 다릅니다;;
인터프리터를 선택할 수 있기 때문인데요.. 어떤놈을 선택하느냐에 따라 성능이 천차만별인걸요? ECMA Script 인터프리터들은 널렸으니까요. 자바버전의 자바스크립트 인터프리터도 있는데 이게 느리다면요? 자바가 느린건가요 ECMA Script라는 언어의 표준에 느리라고 뭐가 되어 있는건가요? -_-;;
언어논쟁은 늘 말이 많군요.
전 개인적으로 azureus같은 유틸을 쓸 때 느리다는 느낌은 받지 못했습니다.
azureus는 제 기억으로 인기 있는 오픈소스 프로그램으로 뽑힐 만큼 인기도 있구요...
(즉 쓰는 사람이 많다는 얘기도 되겠지요.)
걱정할 만큼 느리다면 그렇게 인기를 끌지도 못했겠지요.
-- 그리고 자바
-- 그리고 자바 언어에는 객체 레퍼런스만 있고 포인터가 없는 것은 거짓말이 아니라 사실입니다만..
-- 자바에서 자바 언어와 플랫폼을 구분하지 못하고 계신 듯 싶습니다
객체 레퍼런스가 어쩧게 포인터가 아닐 수 있죠.
물론 단순 포인터와는 약간 더 높은 개념이긴 합니다만..
C++ 에서도 객체 레퍼런스가 실은 내부적으로 포인터인데
자바에서 말하는 레퍼런스란게 포인터가 아니라면 도대체 무엇이란 말입니까.
포인터는..
메모리의 주소를 기반으로 하는 데이터 타입입니다. 메모리에 직접 접근할수 있는 것이죠.
"a pointer is a programming language datatype whose value refers directly to (“points to”) another value stored elsewhere in the computer memory using its address." -- 위키페디아(http://en.wikipedia.org/wiki/Pointer)
포인터는 어떤 데이터의 메모리에 직접 접근할수 있다는 매우 강력한 기능이지만, 메모리에 직접 접근하기 때문에 발생하는 오작동의 문제역시 매우 커질수 있는 양날의 검입니다.
레퍼런스는 객체를 가르키는 데이타 타입이고 C++에서는 이 역시 메모리 주소를 기반으로 합니다.
"references are datatypes which refer to an object elsewhere in memory, and are used to construct a wide variety of data structures such as linked lists. Most programming languages support some form of reference." -- 위키페디아(http://en.wikipedia.org/wiki/Reference)
하지만 자바의 객체 레퍼런스는 어디까지나 참조의 역활을 할뿐 메모리 주소와는 상관이 없습니다. 핸들러라고도 볼수 있겠습니다만, 자바프로그래밍에서 레퍼런스를 사용하면 참조하고 있는 객체에 바로 접근하게 되기 때문에 레퍼런스의 실제 값을 볼수 있는 방법은 없습니다. 그래서 그냥 "객체를 건드린다"라는 감각으로 레퍼런스를 사용하면 그만입니다.
그렇기 때문에
String[] datas= {"aa","bb"}
String ref= datas[0];
ref++;
이런 코드는 자바에서는 컴파일 오류가 나는 문법오류를 가진 코드가 됩니다.
자바의 객체 레퍼런스는 메모리에 직접 접근하는 방법이 아니기 때문에 추가 비용이 필요합니다만(최근의 JVM은 이런 부분을 최적화 했기 때문에 사실상 비용이 거의 들지 않습니다) 메모리를 좀더 안전하게 쓸수 있다라는 점은 분명히 장점이 되었고, 많은 환영을 받은 방식입니다.
이와같이 자바 언어는 객체 레퍼런스만을 지원하고 있고, 자바 프로그래머는 자바 언어를 사용하기 때문에 포인터에 의한 메모리 누수 같은 걱정을 않하고 프로그래밍을 할수 있습니다.
그리고 자바 플랫폼(JVM)은 자바 프로그래머가 만든 클래스(.class)파일을 실행 시키며 내부적으로 최적화를 위해 메모리를 직접 건드리겠죠. 만약 자바 플랫폼이 C/C++로 만들어 졌다면, 내부적으로 포인터를 사용했을 가능성이 높겠죠. 하지만 다른 언어로 만들어진 자바 플랫폼이라면 포인터가 아니라 다른 무언가를 사용하였겠죠.
여태까지 설명 드린것 처럼, 자바 언어와, 플랫폼을 구분하지 않고 자바 레퍼런스는 포인터다라고 말하는 것은 잘못된 것입니다.
요약하자면,(대부분의 토론 대상이 되는) 자바 언어에서 객체 레퍼런스는 메모리와 관련있는 개념이 아니고, 자바 언어상 레퍼런스의 실제 값을 알아 낼수 있는 방법도 존재 하지 않는 객체에 대한 참조일뿐입니다.
http://kldp.org/node/70013
http://kldp.org/node/70013
Java가 C++보다 몇배 느린지 혹은 C++보다 Java가 몇배 빠른지?
과연 이게 얼마나 중요한 논제인가요?
Java를 하시는 분은 C++보다 Java가 빨라서 쓰시는 분들도 아닐테고
해당 분야에서 필요로 해서 쓰는 것 아닌가요?
제가 Java를 안해서 뭐라 드릴 말씀은 없지만, 어느 개발 site를 가더라도
잊을만 하면 올라오는게 "Java는 C++보다 몇배까지는 느리지 않다, 혹은 더 빠르다."
개발 3년차에 들어선 지금 2002년, 2003년 대학다닐때 쯤 보던 논쟁거리를 몇년 지나 다시 보는 지금
비생상적이라는 생각밖에 안드네요.
가끔은 자신이 쓰는 언어가 절대적이다라는 논리에 사로 잡혀 남이 다른 언어를 쓰거나 해당 언어가 좋다. 성능이
괜찮다. 라는 말만 들으면 눈이 뒤집히시는 분들도 계시는데, 정신건강에 그다지 좋지 않습니다.
한가지 덧붙여 Java를 쓰던 대학동기가 인공지능 강의시간에 추론엔진 라이브러리(어디서 개발했는지 기억은 안남)를 소개하는데,
왜 그 라이브러리는 Java를 지원하지 않느냐 따지던 생각이 나는군요.
따지고 보면 그 당시엔 전혀 중요하지 않은 일인데 말이죠.
이 논쟁은 자바가 처음 나왔을때 부터 나온 겁니다. ^^
썬에서 실행시간 최적화를 통해 자바를 빠르게 하겠다라는 발표를 하고 나서 부터 근 10년 이상 지속되고 있는 논쟁입니다.
그리고 이미 여러 유즈넷, /. , 수많은 개발자 사이트에서 수많은 플레임끝에 최종결론이 이미 나있는 상태고요.
MS 개발자들은 닷넷 나오기 전까지는 실행시간 최적화를 비난하다가, 닷넷 발표되고 나서 부터는 실행시간 최적화를 옹호하고 있죠 ^^
저는 이런 10여년에 걸친 수많은 플레임을 직접 겪기도 했고, 보기도 하며, 최종적인 결론이 어떻게 나는지 이미 수십차례이상 봐왔습니다.
결론은 항상 그렇습니다. (결론이 않나고 흐지부지 끝나는 경우도 매우 많았습니다만)
"기술의 발달을 미리 한정지어 판단하는 것은 어리석은 일이다. 따라서 현재 상황의 비교와 앞으로의 발전할 양상의 비교는 엄격히 분리되어 다루어져야 한다."
그리고 이렇게 엄격히 분리해서 비교한 결과
"자바는 전반적으로 많이 느리다" -> "자바는 상당히 빨라졌다" -> "자바는 대부분의 실무에 쓰기에 문제 없을 정도로 빨라졌다" -> "자바는 이제 일부 영역에서 C/C++보다 빨라졌다. 나머지 영역에서도 C/C++의 성능에 상당히 접근했다. "
라는 식으로 "현재 상황 비교"가 변천되어 왔죠. 그리고 저 마지막 결론이 나온것은 JDK 1.3에서 1.4로 넘어가는 시절입니다.
자바가 문제가 없다는 게 아닙니다. 메모리를 많이 소모한다던지, 여전히 Swing의 이벤트 반응 속도가 느리다던지(JDK 1.6에서 고쳐졌다는데 아직 확인을 못했습니다)
하지만, 현실을 아예 무시하고 자기 주장만 하는 사람들이 정말 많지요.
현실이 이런데 왜 이런 결과가 나왔냐? 어떻게 하면 그 노하우를 배울수 있을 것인가? 이런 논쟁이 좀 일어 났으면 좋겠습니다.
이 주제가 일부
이 주제가 일부 익명사용자 때문에 개그화되고 있는 것 같습니다. 자바와 같이 동적 최적화를 할 수 있는 언어가 일부 상황에서 빠르다는 것을 아직도 부정하시는 분이 계신다는게 신기합니다.
- CN의 낙서장 / HanIRC:#CN
- 죠커's blog / HanIRC:#CN
느린것은 사실입니다.
어디에 쓰느냐가 관건인 것이죠.
쉽게 하드웨어쪽에서 C/C++ 주로 사용된는 것과 같은 얘기겠죠.
ActiveX 같은 경우 개발의 편의성 덕에 델파이가 개발 언어로 자주 사용 됬습니다.
어셈블러, 코볼등의 언어들도 현재까지 사용되는 것은 물론이고
포트란 역시 지금까지 과학 수치연산에 많이 사용되죠.
자바는 웹어플리케이션이라는 영역을 차지하고 있는 것과 마찬가지로
어디에 어떻게 사용되는가 라는 문제가 앞서야 할 것 같습니다.
-- 하지만 자바의
-- 하지만 자바의 객체 레퍼런스는 어디까지나 참조의 역활을 할뿐 메모리 주소와는 상관이 없습니다.
-- 핸들러라고도 볼수 있겠습니다만,...
아 '핸들러'라고 하니까 자바가 추구하는 것에 아주 가깝게 들립니다.
명쾌한 지적이셨읍니다.
-- "자바는 전반적으로 많이 느리다" ->
-- "자바는 상당히 빨라졌다" ->
-- "자바는 대부분의 실무에 쓰기에 문제 없을 정도로 빨라졌다" ->
-- "자바는 이제 일부 영역에서 C/C++보다 빨라졌다.나머지 영역에서도 C/C++의 성능에 상당히 접근했다."
-- 라는 식으로 "현재 상황 비교"가 변천되어 왔죠.
-- 그리고 저 마지막 결론이 나온것은 JDK 1.3에서 1.4로 넘어가는 시절입니다. ...
그게 마지막 결론이었다구요. 누구의 결론이었나요.
그럼 JVM 기술이 그만큼 발달했다면, C/C++ 쪽에서는 프로그램적으로
어디까지 최적화할 수 있는 지 생각해 보셨읍니까.
-- 하지만, 현실을 아예 무시하고 자기 주장만 하는 사람들이 정말 많지요.
그런 생각을 아예 하지도 않고 "자바는 이제 일부 영역에서 C/C++보다 빨라졌다" 고 여전히 주장하실래요
전형적인 아전인수격인 사람들이 정말 많네요.
"자바는 이제 일부 영역에서, (시간관계로 최적화를 고려하지 않은) C/C++ 보다 빨라졌다" 면 그것은 말이 됩니다.
-- 현실이 이런데 왜 이런 결과가 나왔냐? 어떻게 하면 그 노하우를 배울수 있을 것인가?
-- 이런 논쟁이 좀 일어 났으면 좋겠습니다.
JVM 의 최적화 뿐만 아니라 C/C++ 쪽의 최적화도 눈을 돌릴 수 있는 논쟁이 좀 일어 났으면 좋겠읍니다.
-- 자바와 같이 동적 최적화를 할 수 있는 언어가 일부 상황에서
-- 빠르다는 것을 아직도 부정하시는 분이 계신다는게 신기합니다.
C/C++ 의 최적화가 정확히 들어가면, 동적 최적화를 하는 언어라 할지라도
일부에서조차 속도를 따라 잡기란 극히 어려운 일이라는 것을
아무도 믿으려 하지 않는 것도 참 신기합니다.
저는 자바에 대해 일종을 공포를 가지고 있읍니다.
제 컴에 이클립스를 깔아서 사용할려고 했는데 시스템이 버벅거려 도저히 쓸 수가 없었어요.
RAM 이 256 이었읍니다. 요즘 세상에 256 RAM 을 누가 쓰냐고 그러겠지만 좀 가난해서
어쩔 수 없었어요. 그 때 고사양(?)을 요구하는 자바란 것이 두렵게 느껴지더군요.
그래서 자바로 하면 지원되는 방대한 라이브러리로 하루 이틀이면 끝날 것을
1 주일 넘게 C/C++ 로 맨땅에 헤딩하면서 작업을 해왔읍니다.
그러고 보면 C/C++ 은 힘없고 가난한 사람들이나 쓰는 도구 같습니다.
결국 C/C++ 은 빈민층용, JAVA 는 부유층용 정도로 생각하면 될 것 같습니다.
부유층용이라는 것은 JAVA 를 충분히 가동시킬 만한 상황을 의미하는 것이지
그 이상의 의미는 없습니다.
그 놈의 C++ 은 또 왜 이렇게 어려운지 지금도 문법 책 펴놓고 낑낑대고 있네요.
한편으론 자바하는 분들은, 어쩔 수 없이 C/C++ 로 처리해야 하는 저 같은 사람도 있다는 것으로
충분히 행복해 해도 좋을 것 같습니다.
정말 C/C++ 은 가급적 하지 마시기 바랍니다.
납기일은 내일인데 메모리 누수때문에 개피본다는게 어떤 건지 안당해보면 몰라요.
참.. 애처로워
참.. 애처로워 보이는군요..ㅎㅎ
Java의 좋은점은 알지만
자기가 아는 언어로 모든걸 쇼부보려는 저 정신!
흘
당신은 C/C++ 로만 쇼부볼려 들지 않소?
남의 글을 제대로 않읽으시는 군요.
>> 뭐 온갖 종류의 최적화를 일일히 다 해주신다면야 당연히 C/C++이 무조건 더 빠르겠죠.
이게 제가 쓴 글입니다. 애시당초 인정하고 들어 가고 있습니다만.. 부디 남의 글을 제대로 읽어 주세요.
>> 그게 마지막 결론이었다구요. 누구의 결론이었나요.
각 시기별로 여러 플레임들의 결과였지요. 저는 이런 플레임을 십몇년째 보아오고 있습니다.
>> 그럼 JVM 기술이 그만큼 발달했다면, C/C++ 쪽에서는 프로그램적으로
>> 어디까지 최적화할 수 있는 지 생각해 보셨읍니까.
이미 충분히 알고 있습니다. 실제로 저는 CPU 캐시 사이즈에 한번에 들어갈수 있는 코드 사이즈라는 영역까지 최적화를 수행하는 C 프로젝트를 수행해 보았습니다.
그리고, 현제 최고로 성능이 좋은 JVM 역시 C/C++로 제작되었다는 사실도 잘 압니다.
>> C/C++ 의 최적화가 정확히 들어가면, 동적 최적화를 하는 언어라 할지라도
>> 일부에서조차 속도를 따라 잡기란 극히 어려운 일이라는 것을
>> 아무도 믿으려 하지 않는 것도 참 신기합니다.
예, 현재까지는 기술적으로 맞는 말입니다. 위에서 적었듯이 저는 믿습니다.
반면에 C/C++이 최적화가 아무리 들어가도 (인라인 어셈을 대규모로 집어넣기전까지는) 대규모 과학연산에서 포트란을 따라잡지 못한다는 것도 잘압니다.
프로그래밍 레벨의 최적화 정말 할수 있다면 좋겠지요.
하지만, 회사가 정말 돈이 많고, 경영진이 완전히 최적화된 SW가 아니면 출시할수 없다라는 경영지원을 해주는 프로젝트라면 가능하겠지만, 그런 회사는 거의 없고, 그렇게 때문에 최적화를 정확히, 완전하게 수행하는 프로젝트는 사실상 없다라는 사실도 잘압니다.
그래서 좋은 컴파일러 쓰려고 하는거 아니겠습니까?. 조금이라도 더 자동으로 최적화 해주는, 더 빠른 실행코드를 만들어 내는 컴파일러 말입니다.
>> 정말 C/C++ 은 가급적 하지 마시기 바랍니다.
>> 납기일은 내일인데 메모리 누수때문에 개피본다는게 어떤 건지 안당해보면 몰라요.
저도 납기일 당일 데모하는데 메모리 누수때문에 뻑 죽는 프로그램을 만들어 봐서 압니다. 아주 미칠 노릇이죠. 왜 회사에서는 잘 되다가, 데모만 하면 죽는지... -_-
저같은 경우는 임베디드와 엔터프라이즈 중간에 딱 끼어 있는 사람입니다. 임베디드 시스템을 만들면서, 이 시스템이 엔터프라이즈 시스템과 통합시키는 관리 서버까지 모두 만들어 봤죠.
그래서 내린 결론은 간단합니다. 생산성이 좋은 언어를 사용하자. 메모리관리를 자동으로 해주는 언어를 사용하자.
조엘온소프트웨어에서 나온 글에 저도 찬성합니다. SW 개발의 생산성 향상은 메모리 관리의 자동화에서 주로 발생합니다.
>> 1 주일 넘게 C/C++ 로 맨땅에 헤딩하면서 작업을 해왔읍니다.
>> 그러고 보면 C/C++ 은 힘없고 가난한 사람들이나 쓰는 도구 같습니다.
하시는 것이 속도가 그렇게 중요한 일이 아니면 한번 파이썬을 시도해보시는 건 어떻겠습니까?
개인적으로 상당히 추천할 만한 언어입니다. 높은 시스템을 요구하는 것도 아니고요.
음 파이선이라.. 이젠
음 파이선이라..
이젠 C 로 밥먹고 사는 일은 포기해야겠읍니다.
몸만 지치고 남는 것은 없는 것 같고..
좋은 충고 감사합니다.
Java Has Won For Ever !
두가지 종류의
두가지 종류의 사람이 있죠..
말잘하는사람과 컴퓨터의 구조를 이해하는사람..
전자는 자바하면좋구요.. 후자는 C하면 좋습니다.
C의 포인터의 강력함은 프로그래밍을 매우 윤택하게 해주거든요..
하지만 수학이나 컴퓨터기초에 약한사람은 오히려독될수도 있죠..
이런분들은 처음부터 전공을 잘못선택한듯.. 영업쪽이면 매우좋습니다..
공부좀 더하고
공부좀 더하고 오시죠.
님부터 하고 오시죠..
님부터 하고 오시죠..
> SW 개발의 생산성
> SW 개발의 생산성 향상은 메모리 관리의 자동화에서 주로 발생합니다.
엥? C++에 비해 자바의 생산성이 높다는 말은 이 얘기였나요?
그럼 별로 다를 것도 없겠는데요.
어 맞는 얘기
어 맞는 얘기 아닌가요.
C/C++ 의 메모리 관리는 java 랑 비슷하지 않는데
C/C++ 의 메모리 누수의 악몽을 경험하지 않은 분 같은데...
C++도 스마트
C++도 스마트 포인터나 컨테이너 쓰면 자동으로 돼요. C++ 쓰면서 메모리 누수로 고민한적 없어요.
그러니까 ^^
스마트포인터는 저도 많이 썼습니다.
하지만, 여전히 수동으로 프로그래머가 코딩을 해줘야 하고, 스마트포인터를 사용하지 않는 라이브러리와 연결해야 한다던지, 서로 다른 팀에서 만들어지는 모듈들의 서로 다른 메모리관리 방식이라던지(성능을 중요시 하는 프로그래머는 스마트포인터 잘 않쓰더군요), 작은 데이터를 위해서는 쓰기 어렵다던지, 여전히 포인터 연산을 잘못하면 Illegal Memory access가 뜬다던지.....
개인수준에서 만들수 없는, 팀단위의 프로그래밍에서는 여전히 심각한 문제가 됩니다.
그래서 내린 결론은 선택사항인 메모리 관리는 팀 전체가 받아들일수 있다면 좋지만, 그렇지 못할때는 강제적인 자동메모리 관리가 훨씬 좋다. 입니다.
아 여기에서..
팀 전체가 받아 들인다는 것은
팀원 전체가 실력적으로도 그것을 받아 들이는 데 문제가 없고
그 정책을 반발하거나 예전(또는 자기만의) 스타일로 코딩을 하지 않고,
마치 한사람이 짠것처럼 보일정도로 동일한 정책을 유지할수 있어야 한다는 겁니다.
플레임이 끝이없군요
Java 와 C/C++ 은 이미 업계에서 용도가 거의 구분지어지고 있는 상황아닙니까?
(물론 중간계가 존재합니다. 그런곳에서의 플레임은 의문이군요. 프로젝트를 무조건 자바로 해야한다 , C++ 로 해야한다 하고 다투면서
서로 언어 , VM 등등의 장단점을 논하는건 별로 의미가 없다고 봅니다. )
여기 플레임에서 아무리 불붙어도 결국 프로젝트는 개발자들이 익숙한 체계로 갈 확률이 높습니다.
아무리 Java 가 쓰기 좋은상황이라도 프로그래머가 그걸 배워나갈 비용이 크고 이래저래 시행착오도 겪어야 하고 이러면 피하게 되죠.
어떨때는 Java로 프로젝트를 구축해 달라고 갑이 말하면 을 입장에선 무조건 Java 로 해야만 하죠.
언어에 대한 속도 문제자체도 마찬가집니다. 단순히 느리다 라고 하면서 다툼만하는건 정말 바보짓입니다.
Java 는 여전히 그래픽분야에선 한수접어줘야 합니다. 그 분야에선 몇배 ~ 몇십배 느리더라 이런소리가 나올 만 하죠.
C/C++ 이 Java 보다 느릴분야도 분명 존재할 수도 있습니다. ( 제가 잘 모르므로 그냥 가정했습니다. )
당연한 소리 같지만 이 플레임 자체는 어차피 자신이 잘 아는 언어에 대해 ( 혹은 개발을 많이 해본 언어에 대해 ) 옹호하고 싸우는
말 이외에 할 이야기가 없습니다. ( 근거 역시 다들 객관성이 떨어진다는 소리밖에 못 듣지요. )
저같이 양쪽을 경험해본 사람으로써는 어차피 상황에 맞춰야 한다는 결론밖에 없었습니다. 그래서 이 플레임 자체가 무의미해 보입니다.
정말로 Java 가 개발속도가 빨라서 좋다 라고 아무리 말하고 싶어도
개발자들 전부가 C/C++ 위주의 멤버라면 진짜로 Java 가 개발속도가 빠르다 라고 할 수 있겠습니까?
거꾸로 C++ 이 실행속도가 빨라서 좋다라고 아무리 말하고 싶어도
Java 로 개발하면 프로젝트 기간이 반으로 줄어든다면 정말로 C++ 로 꼭 그 프로젝트를 해야한다고 주장하실 수 있겠습니까?
어느언어가 느리다 라고 말을 하고 싶을때도 정확히 어느 상황에서는 적어도 어느 언어가 좀 더 느리더라 라고 구체적으로 예를 드는게
플레임을 줄이는 논법이라고 생각합니다.
그냥 막연히 무조건 느리다 라고 하면 누구든지 발끈 하지요.
모든 언어의 태생에는 나름대로 다 이유가 있습니다.
그걸 무시하고 무조건 적으로 속도가 어떻더라 하는건 정말 무지한 발언이라고 볼 수 밖에 없습니다.
'어느 어느 상황에선 이언어가 너무 느려서 못 쓰겠으니 적어도 이 상황에선 다른 언어를 쓰자' 라고 한다면 아주 좋은 분위기로 흘러가겠지요.
벤치마크역시 당연히 객관적이지 못합니다.
언어의 속도 라는게 어차피 정의되기 힘든 부분인데, 막연히 상황에 끼워맞추고 벤치마크 결과로 봐라 하는건 별로 신뢰가 가지 않습니다.
막말로 Java 로 만든 3D engine 과 C++ 로 만든 3D engine 으로 벤치마킹을 한다고 하면 Java 진영에서 벤치마크 결과를 믿을까요?
애초에 이런 플레임은 자존심 긁기 밖에 안되고 각 언어의 각종 능력을 자랑하는 이전투구 자리밖에 안됩니다.
모두들 자기가 개발하는 플랫폼이나 언어에 대해 자부심을 가지고 각종 특징에 대해 상세히 파악하시는 점에 대해서는 박수를 치고 싶습니다만,
이런식으로 남을 헐뜯고 깍아내리려고 공부를 했는지 다시 생각해보셔야 할 분이 있는것 같아서 매우 안타깝습니다.
Neogeo - Future is Now.
그럼 될 수 있으면
그럼 될 수 있으면 C/C++ 보다는 자바로 가야하는 것 아닐까요.
교육을 해서라도 자바로 가야지 자바를 못한다고 C/C++ 을 고수한다면
프로젝트 막판에 등장하는 무시무시한 잘못된 메모리 참조는 막을 길이 뚜렷하게 안보입니다.
요즘은 3D 나 게임도(그리고 대부분의 분야에서) 자바로 웬만큼 속도가 나온다는데
더 이상 C/C++ 을 쓴다는 것은 어리석지 않을까요.
저도 이제부터 C 를 때려치고 java 를 해야 될 것 같습니다.
저처럼 C/C++ 은 조금 아는 사람이 볼만한 자바 입문서로는 무엇이 있을까요.
-- Java Has Won For Ever --
추천서..
Head first Java와 Thinking in Java 두권을 추천해 드립니다.
두권다 상당히 명작이고 많이 팔린 책입니다.
가볍게 보실 거면 Head first java, 진득하니 보실거라면 Thinking in java 입니다.
비슷한것을 자바로
비슷한것을 자바로 개발하면 1.5배정도 시간이 더걸립니다.
실제로 자바인원이 굉장히 많이 투입되죠.. 그만큼 간단한일을 어렵게 한다는뜻이죠..
소스분량만봐도 많구요.. 환경구축부터 다른언어에비해 상당히 복잡하며 어렵습니다.
학교 다닐때 보면
학교 다닐때 보면 전혀 아니던데요~~~
학교에서 1학년때 C (1,2학기) 배우고 2학년때 Visual C++(1,2학기) 과 자바(1학기) 배우는데...
대학교때 대부분의 학생들이 과제를 자바로 했습니다.
언어는 상관없이 프로그램 문제를 작성하라고 하면
90%는 자바로 작성합니다.
왜냐면 쉬워서요..
모가
모가 쉬워요?
그럼간단히 스트링내의 원하는 문자 제거하는 함짜보세여 예를들면 스페이스라던가..
아니그냥 간단히 "skdkglsldslfldsf dskfkfsls ** dflsdf" d 제거하여 "skkglslslflsf skfkfsls ** flsf" 요렇게 되는거 만들어보셔요. 말만하지마시고. 얼마나 쉽게 되나 함바여..
replaceAll
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
ㅡㅡ;; 말뜻을
ㅡㅡ;; 말뜻을 이해못하시네요..
replace 함수를 구현해보라는 말인데여..
그게 뭐가 어렵나요?
어렵지도 않지만 그렇게 일일이 구현하려면 자바를 왜 쓰나요?
뭐, 하스켈로는 더 쉽지만.
C로 한 번 구현해 보시죠.
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
다른
다른 익명입니다.
쉽고 어렵고를 떠나서 배우는 입장에서 위의 함수의 내부 동작을
예상 할 수 있겠습니까? 배울 때, 큰 그림을 그릴 줄 아는 능력도
중요하지만, 세세한 부분의 동작 원리를 아는 것도 중요합니다.
위의 함수를 C 로 나타내보면 위의 함수에 오버헤드가 어느 정도
숨겨져 있나 추측할 수 있습니다.
C로 짜면 오버헤드가 쉽게 눈에 보여서 좋다는게 아니고,
추상화도 중요하지만 어디에 어느 정도 오버헤드가 나는지는
알아야 하지 않겠습니까?
오버헤드
"세세한 부분의 동작 원리"는 밑으로 내려가자면 끝도 없습니다. 어떤 분들은 단순히 계산 속도를 빨리하기 위해서 비디오 카드에 있는 메모리에 접근하는 기법을 쓰시더군요. 살면서 그런 식으로 해야할 일이 얼마나 있는지는 의문입니다. 물론 그런 일을 해야할 사람은 C를 배워야 하겠습니다만.
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
>> "어렵지도 않지만
>> "어렵지도 않지만 그렇게 일일이 구현하려면 자바를 왜 쓰나요?"
뭐든 쉽다하니까 예를들어 해보라했던거구요. 물론 개발이란게 전혀 새로운걸 개발할테니 있는거면 개발할필요가 없겠죠..
그건 C나 다른언어도 마찬가지입니다. 예를들어 구구단 프로그램짜보란식의 예였지 구구단 몰라서 짜보란건 아니자나요?
제가 복잡한 예제를 내서 님이 직접구현해야할문제를 냈다면 님도 귀찮았을것이고 머하러 내가지금 그걸짜줘야하나 식으로 답할수있으니
그냥 간단하게 기존에 흔히 있던함수 재구현해보자 했던겁니다.
뭐 일단 님은 다른함수들을 많이 활용해서 하셨지만 그런거 안쓰고 구현할수 있는걸 보여줬으면 애초바램은 그랬구요.
어쨋든.C로하면
이정도면 될텐데..
살펴보면 님은 함수도 쓰셨고 함수내부에서도 또 루프를돌며 무언가 작업을 하겠죠?
일단 부하도 그렇거니와 구현자체도 C는 함수를 사용하지않고도 간단히 처리되는데반해 자바는 함수를 쓰고도 간단하지 않군요..
대체머가 쉽다는건지..
#include<stdio.h> void
에러나는데 바뀐 문자열은 어떻게 받아오죠???
memory leak 같은건 처리해줄수 있겠죠??
세그멘테이션 오류
가 발생하는군요~~
실행 가능한걸로 올려주시죠~
이건 좀 억지군요
이건 좀 억지군요 -_-;
C를 모르시는 분인데 무슨 테스트를 하신겁니까?
결국 printf("%s", NULL); 을 하신건데 뭘 테스트 하신거죠?
게다가 상수를 조작하는 상황은 그 잘난 실무 상황에서는 없습니다
원래 코드가 억지입니다.
메모리를 할당하고 해제하는 부분을 빼놓으니까 간단해 보일 뿐이죠.
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
아~~~
아~~~ 이무슨...ㅡㅡ;;
아니 사용법은 지켜가며 테스트해야지.. 함수 선언에 void 로 선언해놓은거 보면서 저런식으로 사용하세요?
혹시나 싶어 해보니 잘나오네여..
머가안되고 빠지긴머가빠져요..
또한구현방식도 C로는 효율적으로 call by reference로 구현되었기때문에 불필요한 메모리할당같은건 하지 않고도 구현되구요.
님소스는 call by value 수준이네여... 어느것이 효율적인지는 말안해도 아시리라봐여.
퍽이나 효율적이군요.
아니 그러니까 그 사용법이라는 게 딱 저 경우 밖에 못 쓰는 거죠. aaa("abcdab")도 되게 하거나 아니면 문자열을 삭제하는 대신 추가하는 걸로 (예: 'd' -> "ab") 고쳐보세요. 그래도 간단한지.
그리고 자바는 원시형을 빼면 모든 변수가 레퍼런스입니다. 거참.
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
님은
님은 참어리석습니다.
애초 요구사항을 보셔야지요.. 자신이 불필요한것 넣었다고 남도 넣길 강요하는게 말이되나요?
그러니 얼마나 자바가 불필요한행동을 많이 하고 있다는걸 님이 단적으로 나타낸말입니다.
님이 넣어보란게 못넣어서 안넣은게 아니라.. 불필요하니 그렇게 구현안한겁니다. 거~참..
요구사항?
그 간단한 C로 제 요구사항은 왜 못하나요? 솔직히 말하세요, 책에 있는 코드 베끼는 것 밖에 할 줄 모르죠?
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
자바는 문서에
자바는 문서에 메쏘드 이름만 있으면 문법 무시하고 아무 위치에나 쓰면 되는 모양이네요 -_-;
함수 원형을 보고 짜야지 프로그램이 돌아가는게 당연한거 아닙니까
아 글케 자신 있으면 진짜 실무에 쓰인 코드로 성능 테스트 해보던가요 -_-;;
자바로 실무 한것중에 성능에 의존적인거 어떤거 있나요? 코드 보여줘보세요. 제가 C로 짤테니 여기저기서 돌려보죠?
특별한거 없으시면 간단한 구조체 같은걸 해쉬테이블로 메모리에 랜덤하게 500만개 쯤 넣어놓고 랜덤하게 1000만번 찾아서 업데이트 하는거 구현해 보실까요? 자바에도 해쉬테이블 있으니까요. 아님 서버간 통신? 어떤거라도 아 성능 의존적인 실무에서 쓸만하구나 싶은걸로 단위 기능 정도로 고르시죠 바쁘니까..
논점이탈..
코딩/프로그래밍이 쉽다/아니다라는 것때문에 논쟁이 시작되었는데,
예제라고 올려주신 C 코드는 메모리 누수가 있는 버그 코드..
다른 사람이 메모리 할당에 대한 버그가 있다고 지적하고, 그것을 깨닫게 해주기 위해, 감소가 아닌 추가쪽의 요구사항을 구현해 보라고 하자 자기가 실수했다는 것을 깨닫고 버럭하면서 실무와 성능 타령.
님이 하셔야 할 것은 간단합니다. 버그 없는 제대로된 C 함수를 보여 주시면 되는 겁니다.
아무리 C 를몰라도
아무리 C 를몰라도 너무하시네여..
소스줘도 컴파일도 재대로 못하시는분이이런소리하시면 안되져..
소스 아무 이상없어여.
int main(){ char
한번 실행해 보세요~
실행해 보지 않아도
실행해 보지 않아도 되는게 보입니다..
다른 좋은 자바 개발자들에게까지 선입견 생길까봐 거시기 하네요 -_-;
$ ./a.out
실행 결과 입니다...
이게 문제 없는건가보죠??
$ gcc -vUsing built-in
root@linux:~# gcc -Wall
GCC가 이렇게 약간의 다른 환경으로 허접하게 동작하지 않습니다. 풀소스를 뵈줘보세요
#include<stdio.h> void aaa(
void aaa( char *src ){char
오타 내셨는데요? 마지막에 *src = 0; 입니다..
널 이스케입을 안하셨습니다
ㅋ 오해했군요~~~죄송
ㅋ
오해했군요~~~죄송
먼소리에여? 님이
먼소리에여?
님이 요구하는거 추가하는거는 조기밑에 누가 d -> dd 로 추가해보라는거 랑 비슷하져?
보세여. C는 상황에 맞게 최적화하는거에여.. 자바처럼 군더더기 덕지덕지 다붙여두는개념이 아니란거져.
님은 효율이란
님은 효율이란 단어의 의미도 모르시는듯. 필요 없는것까지 넣는게 효율인가요?
int main(){ char *aa=NULL;
한번 실행해 보세요~
그럼 위의 스트링의
그럼 위의 스트링의 변환 결과를 출력하는 방법을 알려주세요~
단....함수는 변경하지 않고요...
char *aa = "blabla"는
char *aa = "blabla"는 문자열 상수를 가리키는 포인터입니다. 대신에 char aa[] = "blabla"로 바꿔주면 aa에 메모리를 배정하고 문자열을 복사합니다. 이렇게 밖에 못쓰는 함수죠. C의 문자열 관련 함수들이 다 이렇습니다.
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
무슨
무슨 엉뚱한소리세여?
기초를 모르시니까 그런소리나오지요. 정말 무개념이라고 밖에 할수없네여.
C는 불필요한내용을 담지않고 필요한내용만담는게 어떤철학이라봐요 유닉스 철학과닮았죠.
사용할줄모르니 그런소리 나올수밖에요. 메모리할당은할당이 각각다처리를 맡은바 임무완수정도라고해야겠져.
즉하고 싶으면하고 안해도되고 마음데로 할수 있어요. 먼소리하세요. 자바같이 무조건 메모리 할당하고 이런게 아니에여.
C의 배열
C의 배열은 컴파일 시점에 크기를 정적으로 결정해서 실행 시점에 할당하는 겁니다. 할당을 안하긴 뭘 안합니까.
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
말을 못알아
말을 못알아 들으시는군여.
통상 메모리할당한다라는말은 수행중 할당을 말하는거에여.
메모리 누수가 발생하는 코드입니다.
예를 들어
사용자로부터 입력받은 5바이트의 문자열이 있을때,
C 프로그램을 이를 힙메모리에서 6바이트(Null문자포함)를 할당하게 됩니다.
그런데 메모리 재할당 없이 님의 함수를 통해 그중에 3바이트만(3글자를 버렸을때) 남기게 되면,
프로그램 내부적으로는 재할당이나 release가 없었기 때문에 여전히 6바이트만큼의 메모리가 사용되게 있다고 프로그램이 판단하게 됩니다. 따라서 힙메모리에서 (님의 함수에 의해 버려진) 3바이트에 해당하는 메모리를 더이상 쓰지 않게 되며, 메모리 누수가 발생하게 됩니다.
이러니 무개념이란
이러니 무개념이란 말이나오지여
애초 컴파일시에 잡혀버린메모리는 중간에 해제할수가 없어여.기초공부하시고 말씀하시길.
또한 대부분 애초잡힌메모리는 재사용되는경우가 많아여.. 따라서 해지를 안하는게 당연하져.
그런데 자바는 메모리낭비가 장난아니게 심하져? vm 뜰때부터 그엄청난메모리를 자기가 다확보해놓져..
더구나 위에 짜신 코드에도.. 이미 기존 메모리가 있는데 또 new 로 재할당하고 있져?
말이되는소리해여.
컴파일시가 아닙니다만..
실행시에 사용자에게 입력받을수 있는 scanf 는 쓰실줄 아시나요? 그 원리는 아세요?
malloc 과 free 함수는 아시나요?
컴파일시 잡힌 메모리도 free를 통해 해제 가능하다는것은 아시나요?
메모리 누수가 일어난 영역은 재사용되지 않는다는것은 아시나요?
할당되어 사용된 메모리를 해지 하지 않으면 메모리 누수가 발생한다는 것은 아시나요?
네 전 다 압니다.
네 전 다 압니다. 어쩌라구효?
자바의 메모리 관리요.. 좋은지 알고 있습니다. C만큼은 아니지만 자바로도 실무 프로젝트 하고 그랬거든요? C에서는 메모리 관리 못 접해보셨나봐요? APR써보세요
프로세스가 실제로 얼마의 메모리를 차지하는지 RSS를 한번 보세요 어떤놈이 같은 작업에 메모리를 더 쓰는지
아는 분이 왜 그런 실수를?
아는분이 짠 코드가 저렇나요?
힙 메모리에서 누수나는 최악의 코드이잖습니까
메모리를 더쓰든 덜쓰든, 메모리 누수나서 지속적으로 메모리 요구가 늘어나는 코드는 용납이 않되죠.
페이지
댓글 달기