URN Logo
UNIX Resources » Linux » China Linux Forum » Java&jsp技术 » 4 » java的一些看法JTEK
announcement 声明: 本页内容为中国Linux论坛的内容镜像,文章的版权以及其他所有的相关权利属于中国Linux论坛和相应文章的作者,如果转载,请注明文章来源及相关版权信息。
Resources
China Linux Forum(finished)
Linux Forum(finished)
FreeBSD China(finished)
linuxforum.net
  业界新闻与评论
  自由软件杂谈
  IT 人生
  Linux软件快递
  翻译作坊
  Linux图书与评论
  GNU Emacs/XEmacs
  Linux 中文环境和中文化
  Linux桌面与办公软件
  Linux 多媒体与娱乐版
  自由之窗Mozilla
  笔记本电脑上的Linux
  Gentoo
  Debian 一族
  网络管理技术
  Linux 安装与入门
  WEB服务器和FTP服务器
  域名服务器和邮件服务器
  Linux防火墙和代理服务器应用
  文件及打印服务器
  技术培训与认证
  TI专版
  Linux内核技术
  Linux 嵌入技术
  Linux设备驱动程序
  Linux 集群技术
  LINUX平台数据库
  系统和网络安全
  CPU 与 编译器
  系统计算研究所专栏
  Linux下的GUI软件开发
  C/C++编程版
  PHP 技 术
  Java&jsp技术
  Shell编程技术
  Perl 编 程
  Python 编 程
  XML/Web Service 技术
  永远的Unix
  FreeBSD世界
   
java的一些看法JTEK
Author: macolex    Posted: 2004-10-06 11:58    Length: 5,226 byte(s)
[Original] [Print] [Top]
「模擬」既然非真,當然在效率上就較吃虧了,所以就常給人 Java 執行超慢、超耗
資源的印象,其實那是指 Virtual Machine 的效能。為了改進 JVM 效能,使用許多
技術加速,其中最重要的莫如 JIT (Just In Time) Compiler (及時編譯器,注意:
不要跟「即時」[realtime] 搞混) 與 HotSpot 的 Adaptive Compiler 等 dynamic
compilation 技術。

Java Chip 是 Optimized for Java 的 OOP、exption-handling、memory/garbage
collection 的特製 chip,而 x86 (即傳統 CPU) 並沒有針對 C++ 所編譯的 machine
code 中的 new/exception-handling/memory allocation/late-binding 作硬體支援
的最佳化動作。

拜 VLSI 之賜,memory allocation 以及 garabage collection 的動作可交由硬體
來實作。在 modem 或電視中,用以數位類比轉換的 DSP (數位訊號處理) chip 而言
,有所謂的 bit-reverse (作 FFT [快速傅立葉轉換] 用的),倘若以一般 x86 來做
這個動作,起碼慢 10 倍以上。又如以往的浮點咚悖日麛颠算慢了 20 ~ 30 倍
,但因有了浮點加速器的出現,浮點咚愕乃俣瓤蔀檎麛颠算的 1.3 倍!

前述提到將 JVM 以 co-processor 形式實作的方式,可以參考 Nazomi Communica-
tions [2] 公司的產品,他們推出一套 Java 加速晶片,這個代號為 JA108 的產品
專門針對 2G/2.5G 或 3G 的手機使用。不需要加裝額外的記憶體,只需將這 JA 208
IC 植入原有系統設計中,便可大幅提升 Java 應用程式效率達 15 至 60 倍。
[2] http://www.nazomi.com/

接著,筆者在 Pentium II 上咦 linux 進行以下實驗:(原始碼與
machine code 的對照)

c++ 的 virtaul method calling:
┌──────────────────────────┐
│21: testx -> setx(20); // testx 是一個指標物件 │
│──────────────────────────│
│00401091 push 00000014 │
│00401093 mov eax,dword ptr [testx] │
│00401096 mov eax,dword ptr [eax] │
│00401098 mov ecx,dword ptr [testx] │
│0040109b call dword ptr [eax] │
└──────────────────────────┘
不算 argument 4 個指令

c 的一般 call:
┌───────────────────────────┐
│ good() │
│───────────────────────────│
│0040109f call @ILT+0(?good@@YAXH@Z) (00401000) │
│004010a4 add esp,00000004 │
└───────────────────────────┘
不算 argument 2 個指令

java 的 virtual call:
┌───────────────────────────┐
│my.getData(33); │
│───────────────────────────│
│ aload_2 │
│ bipush 33 │
│ invokevirtual #9 │
└───────────────────────────┘
不算 argument 2 個指令.

c++ 的 constructor:
┌────────────────────────────┐
│test *testx = new test(); │
│────────────────────────────│
│00401056 push 00000008 │
│00401058 call ??2@YAPAXI@Z (00401184) │
│0040105d add esp,00000004 │
│00401060 mov dword ptr [ebp-0c],eax │
│00401063 cmp dword ptr [ebp-0c],00000000 │
│00401067 je main+00000030 (0040107d) │
│0040106d mov ecx,dword ptr [ebp-0c] │
│00401070 call @ILT+15(??0test@@QAE@XZ) (0040100f)│
│00401075 mov dword ptr [testx],eax │
│00401078 jmp main+00000037 (00401084) │
│0040107d mov dword ptr [testx],00000000 │
└────────────────────────────┘
11 個指令

C++ destructor:
┌───────────────────────────┐
│delete testx; │
│───────────────────────────│
│004010a7 mov eax,dword ptr [testx] │
│004010aa mov dword ptr [ebp-10],eax │
│004010ad mov eax,dword ptr [ebp-10] │
│004010b0 mov dword ptr [ebp-14],eax │
│004010b3 mov eax,dword ptr [ebp-14] │
│004010b6 push eax │
│004010b7 call ??3@YAXPAX@Z (00401194) │
│004010bc add esp,00000004 │
└───────────────────────────┘
8 個指令

java 的 constructor:
┌───────────────────────────┐
│my my1 = new my(); │
│───────────────────────────│
│new #2 │
│invokenonvirtual #11 ()V> │
└───────────────────────────┘
2 個指令

由此可發現,對動態配置物件的操作而言,Java 一個 method call 只要一個
machine code,但用 x86 相對需要 4 個,這是 Java 在指令集層面直接支援所致。
我們顯而易見 Java 的一個優勢 —─ 目的碼很小,可輕易置於資源困窘的家電設備
中,再加上許多現成的 APIs 可進行呼叫、繼承的使用,簡潔的程式碼就可發揮強大
的力量。
----
[Original] [Print] [Top]
« Previous thread
有谁原意写个java的字体配置文件让它很好的支持中文呢?
Java&jsp技术
4
Next thread »
请教:CLASSPATH配置和EXT目录配置
     

Copyright © 2007~2009 UNIX Resources Network, All Rights Reserved.      About URN | Privacy & Legal | Help | Contact us
webmaster: webmaster@unixresources.net
This page created on 2009-09-07 16:50:07, cost 0.0194568634033 ms.