Sun Microsystems 最期の神託

**名無しさん＠お腹いっぱい。** · 2009/05/11(月) 19:40:54

コンピュータの歴史上に数々の革新を生んできたSun Microsystemsも、
いよいよ神託(oracle)によって最期を迎える。

「汝自身を知れ」

【前スレ】
Sun Microsystems 最上川上流
http://pc12.2ch.net/test/read.cgi/unix/1239259163/

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 11:23:52

2010年末に出るSandyBridgeでピーク性能はNehalemの4倍だからね
下手すりゃVenusより早くてVenusより速い

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 11:36:01

下手しなくてもVenusより早いよｗ

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 12:39:26

Mac mini ならぬ SPARC mini を￥89,800 で出せば大ヒット間違いなし

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 12:42:48

高い弁当箱だな

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 15:41:07

>>254
信者の妄想ｳｾﾞｰ

Appleのようにx86を採用せず、あえてSPARCでやる必要性は、何?

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 15:47:11

所詮妄想なんだ
そっとしといてあげなよ

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 18:21:12

SPARC WS は漢の浪漫だろ？w

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 18:28:50

ﾌﾟﾌﾟ
浪漫とか言っちゃってるし｡ｲﾀﾀﾀ？www

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 18:40:27

分かっていても、いざかかれるとむかつくなwww

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 18:45:25

我が飢えてるの悩みか

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 19:57:39

>>258
SPARC Station 使ったこと有るけれど、ありゃ、なんだね

すげぇ遅いし、使いにくいGUIだし

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 20:07:53

信心が足りませんなぁ

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 20:10:04

Ultra1使ってたけど、Netscape Navigatorの描画が糞トロくて、呆れた。
描画している途中が見れるって、どういうことよ。

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 21:00:15

SuperSPARCは同クロックの486程度
UltraSPARCはPentium程度の性能だからな

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 21:31:11

x86とくらべたらいけませんや
むしろx86で満足なら現行のSun WSはx86なんだからそれを買ってやればいい

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 21:36:11

ていうか
Sunがワークステーションをx86に移行したのに、
なんで小型筐体のワークステーションをSPARCでやらんとならんのよ。

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 21:43:40

懐古趣味の老人用

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 21:47:11

ttp://www.unixhonpo.jp/campaign/Ultra24.html

ほらよ
大好きなx86のWSが半額以下で出てる

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 22:56:49

SPEC int 2006 rates
SGI Altix 4700 Density System (Itanium Processor 9150M 1.66GHz/24M) 256コア→3354
Fujitsu SPARC Enterprise M9000 256コア→ 2288
IBM Power 595 (5.0 GHz, 64 core, SLES) 64コア→ 2155

SPEC fp 2006 rates
SGI Altix 4700 Bandwidth System (Itanium 2 Processor 9040 1.6GHz/18M) 256コア→3507
IBM Power 595 (5.0 GHz, 64 core, SLES) 64コア→2184
Fujitsu SPARC Enterprise M9000 256コア→2005

SPARC64 VIIからVIIIfxに換装すれば、痛を越えられるか。

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 23:32:06

うわSPARCショボと思ったがSGIか
Itaniumのシステムはラックいくつだｗ
それにPOWERでHPCってあまりないだろ
もうItaniumも流行らないな
要するに意味ある比較とは思えない
SPEC MPIで比較せよ

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 23:34:56

負け惜しみだと思われると痛くもない腹を探られるよ

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 23:41:35

ええ、
いっぱいラック並べたらそりゃ勝てるでしょ
って話が何か間違ってるのか

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 23:43:55

Altix4700
Densityはラック2本
Bandwidthはラック4本

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 23:46:28

M9000の最大構成にするのにラック何本使ってもいいのよぉ

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 23:49:49

M9000も256コアならラック2本+α
Power595の64コアはラック1本ただし大きめ

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 23:54:48

なお、Altix4700の最大構成は1024コアらしい。

**名無しさん＠お腹いっぱい。** · 2009/05/16(土) 23:59:14

ラックを多く並べれば勝てると思えるのはいいね

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 00:03:15

>>273が涙目

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 00:04:52

SPEC CPUだしな

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 00:11:20

今時SPARCはないよな

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 00:19:38

CPUはもうあまりきにならない

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 00:25:19

OSとドライバだけだな

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 00:29:29

OSもそれほどもう気にならない
ドライバというか必要な機器が使えればそれもどうでもいい

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 00:38:52

おまいの脱力感は伝わった
Winodwsマンセーということで

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 00:44:06

Windowsはちょっと…

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 00:47:25

SolarisとNICのドライバが好っき

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 00:56:16

SunはケチらずにNiagara2搭載の10GbE TOE NICを安値で提供して、
10GbEのNICで市場を席巻してしまうべきだろう。

なぜ、やらない。
できない理由はなんだ。

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 00:57:18

10GbE TOE NICがそんなに安く作れないんだろう

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 01:00:25

コアが全部生きてるのを選別しないと意味ないしな

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 01:07:25

Niagara2搭載のNICって熱そう

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 01:07:31

NiagaraのPCI Expressはホスト専用だからだろう。
ターゲット(?)としても動作するように作ってあれば・・・

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 01:15:26

ttp://www.chelsio.com/assetlibrary/products/S320E%20Product%20Brief%20080826A.pdf
このへんが1000ドル切ってるんで・・・

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 01:22:13

さすがにミリ

でも、DELLで買うと$1150くらい

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 01:32:54

ttp://accessories.us.dell.com/sna/products/Storage_Accessories/productdetail.aspx?c=us&l=en&s=bsd&cs=04&sku=A1998638
Chelsio S320E-CXA
10GbE dual port TOE CX4
$1,151.95

ttp://accessories.us.dell.com/sna/products/Storage_Accessories/productdetail.aspx?c=us&l=en&s=bsd&cs=04&sku=A1998637
Chelsio S310E-CXA
10GbE single port TOE CX4
$835.95

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 04:01:14

ここでMIPSが華麗に復活

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 05:39:24

MIPSのどこが悪いのか、いまだに、わからん。

R3000をUNIXワークステーションで、
R4000をPDAで使ったが、
素直で良いCPUだったと思う。

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 08:42:11

別に悪くはないと思うが。

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 08:47:06

それで安くて性能が高けりゃ良かったんだけどな
MIPS/IRIX使ってたけど酷かったわ

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 08:48:59

MIPSにも性能が他と比較して高い時期はあったんだ。
ただ、それが続かなかった

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 12:48:56

スレタイに沿った話をすると、
Solaris/x86 は PRIMERGY と組み合わせて xAMP サーバやインターネットサーバ、
ファイルサーバとしてテンプレ化して売る
Solaris/SPARC は従来通り Oracle プラットフォームや基幹業務向けとして売る
という使い分けをした方がいいと思う。

ただそうすると、現行の PRIMERGY＋RHEL の組み合わせとモロ被るのが難点
顧客視点で言うと、知名度の点で残念ながら RHEL＞Solaris なんだろう
Solaris の運用のしやすさはもっとアピールした方がいいと思うけどねぇ

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 13:36:54

http://nseki.tumblr.com/post/108605269/cool-laptop-at-tokyo-barcamp-on-twitpic

こんな事やってるから潰れるんだよ

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 13:44:48

Sunが事実上の自社ハード専用OSとして展開してたのが原因だし仕方がない
Linux@x86の隆盛に慌ててOpen Solarisも用意したけど時すでに遅し

x86コア集めたNiagaraT2みたいなのをAMDと共同で開発して、超メニィコアCPU用意した方がいいんじゃない?
ZFSのLinux実装が不完全だから、トランザクションに特化したハードウェアプラットホームを用意してLinuxに水をあけるべきかと
バグ取りとか最適化は、RHELとFedoraの関係みたく、オープンソースというお題目でタダ働きしてくれるOpen Solaris陣営にまかせればいいし

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 14:55:26

オープンソースの連中馬鹿にしてると痛い目にあうよ

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 15:02:30

>x86コア集めたNiagaraT2みたいなの
これIntelも作ろうとしてたけどキャンセルされたって話だったよね
なんでだろうね
ttp://www.theinquirer.net/inquirer/news/1029138/new-from-intel-its-mini-cores

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 15:16:03

>>299
それはMIPSが悪いんじゃなくて、SGIの高付加価値マシンを、汎用に使うから高いのだ。

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 15:36:21

>>304
充分痛い目にあってるのにまだ気付いてないっぽいのが、もう、ね

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 15:42:24

おっとJarisの悪口はそこまでだ

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 15:47:12

>>305
金持ち(Intel)が道楽(基礎研究)として作るのと
貧乏人(Sun)がメシのネタ(製品)として作るのはわけが違うぜ旦那

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 16:04:42

>>303
事情通を気取っているが実は半可通ていうやつに見えるな

x86でSolarisを売っていこうという動きはSunSoftを分社化したときにあった
しかしSPARCサーバのソフト強化を図るためSunSoftを吸収され立ち消えた

オープンにしようという動きはSolaris 8前後に行動があったけど
社内の抵抗勢力に潰された
技術で喰ってる会社なのに事務部門がヘンに力を持つとろくでもない

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 16:45:20

つまり、SPARCが癌なのか。

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 17:21:53

>>311
元祖SPARCを捨てて、FのSPARC64をメインに本家も採用すればよかった
んじゃないかって俺は想っている。

それから、Solarisの処遇。これは完全にここ数年の動きは失敗だったといわ
ざるを得ない。Solaris/x86をリリース停止にしようとしたあの時とか、OpenSolaris
出すとかぬかした時とか、さらには、Cobalt買収して、SunはLinuxと友達とかほざ
いていた時とか、全部、くだくだ。

当時からハイエンドにしか目が行っていなかったし、ミッドレンジ以下はどこか軽視
していたので、ここでSolarisではなく、Linuxに注力すべきじゃないか？x86版の
Solarisはかならずどこかで役に立つと俺は進言していたのだが、どちらも手遅れ
だったみたいだな。あの可愛い子どうしているかな・・・・　俺のこのメッセージを受け
とってくれたはずなんだけれどな。

社内でも笑われたけれどね。俺はもう一度彼女に会いたいな。
ちょっと丸っとしていたけれど、とてもキュートで、黒めがねの似合うSolarisエンジニア
でさ、Linuxの動向とか調査ってことで俺の所に話に来たことがあって、そこが出会い
だった。

そんな俺の今の興味は、アテモヤ栽培。Sunから離れて行く年月、今回の買収劇も
正直驚いていないけれど、Sunは判断ミスが多かったと思う。

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 18:38:34

x86とLinux
どちらも、ろくなもんじゃない。しかし、安い。
だから、SPARCやSolarisの苦肉の代替手段として、みんな嫌々ながら使った。
それで実績が増え、改良も進み、もうSPARCやSolarisいらないんじゃないの? と思われるようになった。

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 19:13:49

同じコンシューマレベルでの戦いが明暗を分けたよな、どこも
x86はIntel vs AMD, LinuxはFedora vs Debianが常に戦ってて日進月歩だ
エンタープライズにあぐらを書いてたJavaは、いつの間にか家電にまで浸透したFlashに駆逐されかけてるし

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 19:15:21

あてがわれていたSPARCやSolarisを嫌々ながら使っていただけ
Linuxやx86は解放者だった

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 19:18:28

ヲレも最後にあてがわれたのがBlade100だった
たしかにPCは解放者だったかも
LinuxじゃなくてWindowsとcygwinに移ったが

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 19:21:02

>>314
>Fedora vs Debian

いつ戦ってたの?

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 19:26:57

Fedoraが出たての頃かな？
まだRedHat vs Debianを引きずってるぐらいの頃

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 19:28:24

>>314
> エンタープライズにあぐらを書いてたJava

最初はクライアント・サイドのテクノロジーだったんだよ。

ところが、JVMやOSの実装によって挙動が異なる上に、JVMのバージョン間にも挙動の違いがあったりして、
サポートしてらんねーとプログラマがブチキレ。あと、JVMの起動が遅かったことも災いしたね。
(いまではJVMの起動はあっという間で、ネイティブのアプリと遜色ないどころか、むしろ作りが良くて速いことも)
それで、サーバサイドに活路を見いだして移っていったのさ。

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 19:36:50

Javaはまだ芽があるだろうと思うけどね。
グダグダはあったとは言え。
携帯市場(特にARM)向けにもっと積極的になって欲しかった所だけどね。
サードパーティーのつけいる隙を作ってしまったのは痛い

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 20:29:37

FujitsuのSPARC64部隊はどこまで本気なんだろうといつも思う
Fはカネのために独自技術を捨てていく方向じゃないの？

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 20:36:39

この先日本のスパコンはどうなってしまうのん？

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 20:39:04

>>321
SPARC64作ってる部隊は、メインフレームのCPUも作ってる。
やめるときは、その両方をいっぺんにやめることになるだろうね。

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 22:09:14

>>320
Javaは残るだろうけど、SunやOracleのJavaじゃなくて、IBMのJavaとしてな。

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 22:21:09

>>321
サーバ事業はもはや本業ではないとのこと

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 22:32:50

>>318
何だ昔の話か。

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 23:15:07

>>319
>いまではJVMの起動はあっという間で、ネイティブのアプリと遜色ないどころか

それはねーよ

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 23:33:13

あるんだな、それが。

ネイティブの優れた実装 > Javaで凡人が書いた実装 > ネイティブの下手な実装

同じ程度の人間ならネイティブよりもJavaのほうが高性能を得られるよ。

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 23:38:16

これはコンパイラ(+VM)の差や…
同じアルゴリズムで実装して適切な最適化が加わったらJavaがネイティブより速いわけない
お前は一体どういう魔法にかかったんだ？
それにJVMの起動があっという間て、どんな悠長な世界に過ごしてるんだ

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 23:40:31

10年前に比べたらあっというまだろうよ

**名無しさん＠お腹いっぱい。** · 2009/05/17(日) 23:51:56

JITコンパイラの動的最適化でネイティブ超えるには、ある程度条件がそろわないとね
GCCとか最適化の水準が低めになってる奴ならまだしも、ICCとかだとさすがに勝てないよ

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 00:12:38

まあJVMの起動があっという間というと語弊があるが、
最近のJREをWindowsにインストールすると
Java faststartupみたいな(名前うろ覚え)プロセスが裏で立ち上がるのよ。
OfficeとかAcrobat Readerの高速起動化プロセスみたいなヤツ。
なので、実際、体感ではかなり早くなってる。
＃が、ふつーの人間はJavaアプリなんか使わないから....。

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 01:03:05

> 同じアルゴリズムで実装して適切な最適化が加わったらJavaがネイティブより速いわけない
1.1 の頃まではそうだろうが、最近はもっと気の利いた高速化が導入されていて
速いわけないとは言えない。
ネイティブではどう背伸びしてもできない最適化もあるしね。
まぁ、それとて仕組みを調べてガチガチにくめばネイティブでも似た効果は
得られるかもしれないけど、結構大変だよ。
確かにいろいろとオーバーヘッドになる要素はあるが、それによって
もたらされる利便性とトータルでみないと。

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 01:10:30

実際にJava使ってないだろ?
あるいは、よっぽどネイティブで優れた実装できる手腕をお持ちか?

俺には無理だ

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 04:52:01

1996年ぐらいのときは　HotSpot 技術でCで書いたプログラムより高速に動作するように
なると盛んに宣伝してた。実際にHotSpot技術がリリースされたのが1999年ぐらいで、
当然ながらほとんどの場合で Cで書かれた場合より遅い。
HostSpot は出る出る詐欺だったよ
1996～97年ぐらいの JavaWorld っていう雑誌見ると OS からアプリケーションから
組込みまで全部 Java で書かれるようになるというようなことがよく書かれていて、
Java万歳って思っていた時期がありました。

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 04:58:05

vistaなんてそのコンセプトをパクってどれもマネージドコードで書かれてるじゃん

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 08:12:07

>>314
AjaxとかFlashマジでヤバいよ
Web用スクリプト言語のくせにGPU直接制御して3Dとか
ありえないこと企んでたり
さすがのAppleもビビって長い間iPhoneには使わせなかったけど
GoogleはAndroidであっさりFlash対応
AndroidでJavaプログラミング～って、ホルホルするより
Flexでアプリ書いた方がずっと楽して勝てそう

立場のないJava可哀想
一応付き合うけど本命にするのはちょっと…

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 08:45:44

・Flashが3DをHWレンダリングする様になった
・FlashがAndroidに搭載された

これだけの話でそこまで興奮出来るのは浦山歯科

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 13:09:00

>>303
だからさー、それ作れるんならとっくに作ってるさ。簡単に作れるんなら
障壁になるもんなんか何もないだろ? 金も人間も工場も時間もあった。

「x86がクズ」だから、に決まってんじゃん。

>>305
お得意のやつだろ。できもしないんだけど一応喧伝。プロパガンダ。

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 13:10:50

>>297
じゃあさ、x86のどこがいいのか、具体的にあげてみろよ? ひとつもないぞ。

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 15:01:19

安いこと(それだけ)
半年待つと、ちょこっと改良された製品がでてくること
3年経つと、大きく改良された製品が出てくること
Windowsが動くこと
(上と関連して)ドライバがあること

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 15:02:28

SUNファンなら Solaris Innovation Forum 2009 行けよな！
http://jp.sun.com/company/events/sif09/

Oracle Open World の1/5ぐらいの規模だけど

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 19:17:54

>>341
もちろん、わかった上で書いてると思うけど（どっかのバカと違ってw）..

それ、ソトヅラであって、「どこが」には相当しないよね。
この業界のダメさ加減をまさに象徴してるわ。

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 19:25:42

SparKのどこがいいのかkwsk

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 19:28:37

(^.^)?

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 19:31:28

>>343
そういう自己中心的な考えだからIAサーバーに市場とられてるんですが。

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 19:37:20

バカを演じて釣りやってるだけだろ
相手すんなよ

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 19:41:14

長いものに巻かれてシリウマに乗りまくってるバカどもが
儲けてもないくせに声だけデカいからほんとメーワクだよな。責任取らせなくちゃ。

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 19:53:40

>>344
よく落ちるところだと思う

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 21:40:52

ライオンだな

**名無しさん＠お腹いっぱい。** · 2009/05/18(月) 21:56:54

>>339
そんなにSPARCが素晴らしいなら、
Transmetaのようにx86をエミュレーション
すりゃよかったのに。

OSも作っているんだから、変換したコードを保存して再利用することも、容易でしょう。
サーバは比較的に同じコードを繰り返し実行するので、変換のオーバーヘッドは問題になりにくいよ。