レス数が1000を超えています。残念ながら全部は表示しません。

Mac OSX はどうよ？(マカーお断り) Part3

1 ：名無しさん＠お腹いっぱい。 ：02/07/05 21:05

これまでUNIXを使ってきた人が、MacOSXについて論じるスレッドです。

前スレッド
http://pc.2ch.net/test/read.cgi/unix/1021342273/l50

624 ：名無しさん＠お腹いっぱい。 ：02/07/25 23:21

>>620
積極的な開発はしてない。
移植性が失われてないのを確認する程度。

625 ：名無しさん＠お腹いっぱい。 ：02/07/26 00:29

>>619
ていうか諸悪の元凶Motorola以外にすれば良いだけではないかと思う．
IBM PPC-G3でAltiVecみたいな感じの一部だけ高速化技術ってなかったっけ？
それをG5って云って，新型PowerMacに採用すれば万事ｳﾏｰではない？

intelチップにして早くなるのは嬉しいけど，
PPCの燃費の良さは魅力的だけどなぁ．

626 ：名無しさん＠お腹いっぱい。 ：02/07/26 00:38

PCアーキテクチャへの移行はありえないと断言しておこう。
死ぬほど種類の多いハードウェアのドライバーを開発する馬力はAppleにはない。
無数の組み合わせを検証するなんて夢のまた夢だ。

ドライバーだけならWindows用のを流用するのは技術的に可能だけど、
各種ユーティリティーを含めて実行できるようにするのはまず不可能。

627 ：名無しさん＠お腹いっぱい。 ：02/07/26 00:42

何を血迷ったか、SH-4あたりに移行してしまってﾏｽﾞｰ

628 ：名無しさん＠お腹いっぱい。 ：02/07/26 00:47

参考にすれ
http://pc.2ch.net/test/read.cgi/mac/1027044294/27

629 ：名無しさん＠お腹いっぱい。 ：02/07/26 00:55

>>628
これ、某誌の記事ほとんどそのままじゃん…

630 ：名無しさん＠お腹いっぱい。 ：02/07/26 01:08

結局、いわゆるPCではMacOSXは動かないけど
CPUがPentium4のMachintoshはでるかもしれない
ってことか？

CPUが速くなって値段が安くなれば、俺的には十分だな…

631 ：名無しさん＠お腹いっぱい。 ：02/07/26 03:18

そのジョブスへのインタビューですが、もう少し厳密に言うと、
「Pentiumへの移行はあり得る？」という質問じゃなくて、
「モトローラから"IBM"などその他のチップベンダに乗り換える予定は？」
なんだけどね。で、ジョブスの答えはというと、
「我々の一番重要な課題はまずMac OS 9からMac OS Xへの移行である。
　その後ようやくCPUの移行という選択肢が考慮できる環境になれる。
　選択肢を持てるということ自体は悪くない」
という非常に無難なやり取りだったわけです。

632 ：名無しさん＠お腹いっぱい。 ：02/07/26 09:02

POWER4キボンヌ。
PowerMacからPOWERMacへ。

633 ：名無しさん＠お腹いっぱい ：02/07/26 09:17

MotoG5(8500)には期待できないから、
IBM POWERかIBM G5採用の他にPowerPCが生き残る術はないよ。
でなければ、IntelかAMDのPowerPC互換チップ採用するしかなくなる。
まあMac OS Xやアプリが快適に動くに越したことはないし。
さもなくば全機種DualかQuadでお茶を濁す以外に道がない。

634 ：名無しさん＠お腹いっぱい。 ：02/07/26 11:49

DualCPUとかはそれはそれで快適だろうから，
もしクロックが十分に上がっても続けて欲しいけど．

いまの世の中に，OSがサクサク動くかどうかを真っ先に検証される
フラッグシップマシンてあんまりだよね．

635 ：F-Secure SSH for Mac ：02/07/26 12:42

最近、海外の噂系サイトで
「Appleは来年POWER4ベースのMCMチップを採用する。」とか書かれてたよ。
でもPOWER4チップ、単価高いからな〜。
あくまでも噂と言う事で。

Appleがエンタープライズ系を考えているのであれば・・・。

636 ：名無しさん＠お腹いっぱい。 ：02/07/26 13:34

>>635
POWER4チップって実際の所、単価はどの位なんだろ
1000チップ位買うとしてさ。

637 ：名無しさん＠お腹いっぱい。 ：02/07/26 15:12

なんかまたマカーっぽい話題に流れてるな。
ちょっと油断をするとこうだ。

638 ：名無しさん＠お腹いっぱい。 ：02/07/26 15:24

しかし、Power4ってそんなにいいのだろうか？

PowerPCの特性は、「リーズナブルでパフォーマンス」なわけで、費用
対効果を重視したチップなわけで、そういう意味では高性能にして高
価格維持を狙った Intel系や、そもそも高価格のSPARC とかとは一線
を隔すわけだ。

いや、CPUだけでそうなるとはいわないけどさ、例えばCPUをPOWER4 に
して、POWER4 が生きるようなハードウェア構成にして、性能が出たと
しても、それっていくらになるのかな？
もしもそれで在りし日の Quadra みたいにMac1台100万円とかになった
ら、買う人、いる？

639 ：597 ：02/07/26 15:35

>>637
食い残しリンゴのシールにこだわるのがマカー。でよろしいでしょうか。

マカーはこれでも読んどいて。
http://www.linuxworld.com/site-stories/2002/0724.macx.html

640 ：名無しさん＠お腹いっぱい。 ：02/07/26 17:12

CPUとかくだらないことに、マカーはぎゃーぎゃーうるさいんだよ。

641 ：名無しさん＠お腹いっぱい。 ：02/07/26 17:34

今のDarwinカーネルってCPU2個までしか対応していないらしいんだけど、
4個対応のカーネルって当分無理なのかなぁ。
Machってもともとそういうの強いんでないの?
Machのえらい人います?

642 ：名無しさん＠お腹いっぱい。 ：02/07/26 17:59

マカーはうるさいって。

643 ：偉い人ではないですが ：02/07/26 18:01

>>641
Darwinのソースをしっかり読んだ訳ではないですが、
モノの本で100CPUうんたらという記述もあったのと、
MkLinuxの頃のOSF Mach3等を見た限りではMach自
体は殆ど変更無しでいけそうです。
最大２個まで、っていう話は、カーネルの実装の話で
はなくて、カーネルのmake時の変数で指定したCPUが
２個だった、って話だと思います。だとしたらNCPUS=4
でカーネルを作り直せばいいのかな。

勿論、２個だと現れなくて、４個にしたら顕在化する
様なバグが無いという保証は無いわけなんですが。

詳しい事は、Darwinのソースをgrep NCPUSしてみて、
そのあたりから色々眺めて見ると解ると思います。

644 ：名無しさん＠お腹いっぱい。 ：02/07/26 18:23

本で読んだのか。

645 ：名無しさん＠お腹いっぱい。 ：02/07/26 18:38

>>638
100万円でおさまったら大バーゲンだろうな。

それ以前にアーチテクチャがそもそも量産向きでないから
とても絶対量を確保できないだろうけど。

646 ：Are you ready ? # ：02/07/26 18:58

とりっぷてすと

647 ：Are you ready ? # ：02/07/26 18:59

再テスト

648 ：名無しさん＠お腹いっぱい。 ：02/07/26 21:07

CPU談義するにしてもx86-64とかIA-64って選択肢について誰も触れて
ないのは何かの陰謀？

Pentium4なんてクロックの見た目の数字を上げて馬鹿を釣るだけの
ためのCPUになにがしかの期待を持ってるオタンコナスがこれだけ
いるのは禿しく不気味…

649 ：名無しさん＠お腹いっぱい。 ：02/07/26 21:33

ひとつ言っとくよ、ここはＯＳのスレッドで、マック本体のスレッドじゃ
ないんだよ。そういうのは、新マック板でやっとくれ。

650 ：名無しさん＠お腹いっぱい。 ：02/07/26 22:47

Darwinカーネル自体はほとんど変更なしでCPU数、がんがん増やせまっせ。
ただ、それをどう活かすか、っていうののほうが問題だけど。
4CPU以上って、ハードウェアが馬鹿高値くなる割にメリットは少ない気がする、
正直なところ。

651 ：名無しさん＠お腹いっぱい。 ：02/07/26 23:04

>>650
BSDサーバの部分も大丈夫なの?
排他制御にgiant lock使っててCPU増やしてもいまいちスケールしないとか無い?

652 ：643 ：02/07/27 00:15

>>650,651
カーネルの構造はともかく、スレッドをプロセサに自由に
割り当てる事が出来るので、それを有効活用すればいいん
だろうけど、そういうノウハウみたいなものはあるのかな？

私が知ってる範囲では、概念について書かれたものはあっ
ても、プロセサ/プロセサセットの使い方とか、こうすれば
パフォーマンスがでる、といった設計の指針になるような
文献を知らない。あれば教えて欲しい。

653 ：名無しさん＠お腹いっぱい。 ：02/07/27 00:18

>>651
詳しい検証はしてないけど、おおむね大丈夫ぽいかな？
I/O kitが分離されてるから、I/O的にもいけそうだし。

654 ：名無しさん＠お腹いっぱい。 ：02/07/27 00:37

>>652
事例ごとに論文を直接あたるしかないんじゃない？
「並列化して、効率が落ちなかったら成功だ」っていう笑い話が
あるくらい、難しい分野だよね。

655 ：名無しさん＠お腹いっぱい。 ：02/07/27 00:43

>>656
おまえいつもいるな

656 ：名無しさん＠お腹いっぱい。 ：02/07/27 00:57

>>655
予言者にはかなわないや

657 ：名無しさん＠お腹いっぱい。 ：02/07/27 00:59

>>655
一日３回くらい、だが何か？

658 ：名無しさん＠お腹いっぱい。 ：02/07/27 01:00

負けた・・・

659 ：名無しさん＠お腹いっぱい。 ：02/07/27 01:14

漏れは仕事でスレッドプログラム書いてるが、ほとほと世の中にはスレッドセーフな
コードをかける奴が少なくて泣いてます。んなもんで、CPUが沢山あったところで、
「一つのアプリケーションが」高速化する見込みは(うまいこと並列化する見込みは)
ほとんどなかったり。

ただ、「複数のアプリケーションが動いても遅くならない」だったら可能性はある。
ただ、その場合はアプリがマルチスレッドで書かなくていい分、OSがマルチスレッ
ドに対応しなきゃいかんし、「複数CPUで動いても大丈夫なハードウェア」でなけ
ればならない。とくにメモリとキャッシュの関係とか、CPUが増えれば増えるほど
頭の痛くなるハードウェアの問題は多い。

ま、とりあえず何が問題かは

http://www.amazon.co.jp/exec/obidos/ASIN/487193862X

これでも読んで勉強してみろ。

660 ：名無しさん＠お腹いっぱい。 ：02/07/27 02:39

カーボンのマルチスレッドは泣けますが何か？

661 ：名無しさん＠お腹いっぱい。 ：02/07/27 10:58

>>659
これおもしろそう。多謝！

>>660
泣け。

662 ：マカー ：02/07/27 11:23

みんな氏ね！！

663 ：名無しさん＠お腹いっぱい。 ：02/07/27 11:45

マカーハッケソ！

664 ：名無しさん ：02/07/27 11:51

>>652
> カーネルの構造はともかく、スレッドをプロセサに自由に
> 割り当てる事が出来るので、それを有効活用すればいいん
> だろうけど、

絶望的な無知…

665 ：名無しさん＠お腹いっぱい。 ：02/07/27 12:30

>>664
なんか別なハナシとごっちゃになってるような気配

666 ：惣流・アスカ・ラングレー ：02/07/27 13:40

>>662
私を殺さないで！！マカー！！

ｽﾏｿ

667 ：名無しさん＠お腹いっぱい。 ：02/07/27 15:50

マカーを追放できたのはいいが、また別の勘違いグループが
きてるような気がするんだが・・・

668 ：名無しさん＠お腹いっぱい。 ：02/07/27 16:18

↑相手にされないにもかかわらずいつもいる人

669 ：名無しさん＠お腹いっぱい。 ：02/07/27 18:44

>>666
そう、よかったわね。

670 ：名無しさん＠お腹いっぱい。 ：02/07/27 19:32

>>672
おまえいつもいるな

671 ：名無しさん＠お腹いっぱい。 ：02/07/27 19:35

このスレに予言者が降臨しますた。

672 ：名無しさん＠Ｅｍａｃｓ ：02/07/27 21:55

>>675
おまえも、いつもいるな

673 ：名無しさん＠お腹いっぱい。 ：02/07/27 23:44

3

674 ：名無しさん＠お腹いっぱい。 ：02/07/27 23:44

2,1

675 ：莫迦誰 ：02/07/27 23:45

>>672
バレたか…

676 ：???<THORN>?N ：02/07/27 23:49

>>1000
おまえ、いつもいるな

677 ：652 ：02/07/28 00:53

>>664
>望的な無知…

どこがだか教えてくださいおねがいします

678 ：名無しさん＠お腹いっぱい。 ：02/07/28 00:55

>>677
単なる煽りと思われ。
気にする価値なし。

679 ：名無しさん ：02/07/28 01:50

>>677
>>651の話は理解できているの?

680 ：677 ：02/07/28 02:01

>>679
うん？
650で
>Darwinカーネル自体はほとんど変更なしでCPU数、がんがん増やせまっせ。
>ただ、それをどう活かすか、っていうののほうが問題だけど。
って言ってるから、
651の
>いまいちスケールしないとか無い?
っていう話の他にも「どう活かすか」って時に考慮する事は
あるでしょう、ってつもりで書いたけど。

681 ：名無しさん ：02/07/28 03:17

http://louis.gerbarg.org/papers/AdvancedSynchronization.pdf
辺りを読んでみてはどうでしょう?

Kernelの構造に影響を受けずにSMP並列度が上がるのは、
計算ノード間の通信量の少ない数値計算くらいです。
Kernel threadはほとんどお仕事しませんから。

682 ：名無しさん＠お腹いっぱい。 ：02/07/28 08:16

> 計算ノード間の通信量の少ない

ならSMPじゃなくてもええべなー

683 ：名無しさん＠お腹いっぱい。 ：02/07/28 09:34

>>682
SMPではっきりと嬉しいのは、FreeBSDのカーネルをparallel makeする
ときくらいかなあ。まあ、ユーザーが大勢いるときはそれなりにメリットが
出てるんだろうけど、あまり意識しないなあ。

684 ：名無しさん＠お腹いっぱい ：02/07/28 10:01

parallel palallel ミンキーモモ

685 ：名無しさん＠お腹いっぱい。 ：02/07/28 11:21

>>684
おまえいつもいる?

686 ：名無しさん ：02/07/28 11:55

>>682
「ない」んじゃなくて、「少ない」です。

687 ：名無しさん＠お腹いっぱい。 ：02/07/28 11:57

Finkのaptおかしいなと思ったら、

Binary distribution moved to new location
http://fink.sourceforge.net/news/bindist_move.php

場所変わったのね。

688 ：名無しさん＠お腹いっぱい。 ：02/07/28 12:26

>>659
> 「一つのアプリケーションが」高速化する見込みは(うまいこと並列化する見込みは)
> ほとんどなかったり。

サーバ製品だったらSMPは十分うまみがあると思うんだが。
通常のデスクトップビジネスアプリが、SMPの需要を生み出しているということはないでしょう。

でも、普通にthreadableなコード書けないのは、
少なくとも通常のソフトベンダではないのでは？

689 ：名無しさん＠お腹いっぱい。 ：02/07/28 16:01

なんでもいいけど、MacOSXの話をしてくれ。
パソコンオタクは消えろ。

690 ：名無しさん＠お腹いっぱい。 ：02/07/28 16:56

>>689
してるのがわからない哀れなDON

691 ：名無しさん＠お腹いっぱい。 ：02/07/28 17:12

やっぱスレタイトルがいまいちかも。
次スレでは「Darwinはどうよ？」にしない?

692 ：名無しさん＠お腹いっぱい。 ：02/07/28 18:44

「Darwin / Mac OS X 総合スレッド」とか。

693 ：名無しさん＠お腹いっぱい。 ：02/07/28 20:21

「Darwin / Mac OS X総合スレッド (マカーお断り)」とか。

694 ：名無しさん＠お腹いっぱい。 ：02/07/28 20:34

>>693
流れの読めない夏厨ｲﾀｲ

695 ：名無しさん＠お腹いっぱい。 ：02/07/28 20:36

「ものすごい勢いでWinﾕｰｻﾞがMacﾕｰｻﾞをバカにするスレッド 懲りずにPart 4」とか??

# 激しく板違い。

696 ：名無しさん＠お腹いっぱい。 ：02/07/28 20:36

「Darwin / Mac OS X 総合スレッド(夏厨お断り)」

697 ：名無しさん＠お腹いっぱい。 ：02/07/28 20:41

いろいろもめるし、「Mac OS X」というのは入れないほうがいいんじゃない？
あとマカーっていうのも。

698 ：名無しさん＠お腹いっぱい。 ：02/07/28 20:50

>>688
>サーバ製品だったらSMPは十分うまみがあると思うんだが。
>通常のデスクトップビジネスアプリが、SMPの需要を生み出しているということはないでしょう。

それは私も思いますね。
SMPに限らず、ネットワーク透過なメッセージパッシングとか、
エンドユーザーが使うデスクトップOSにとっては余りメリット
がありそうに思えない所にMachの美味しそうな特徴があったり
するので、それを活かせるアプリが出て来る可能性は低いかと。

699 ：名無しさん＠お腹いっぱい。 ：02/07/28 21:11

「Win廚がUNIXユーザを騙るスレッド」

700 ：名無しさん＠お腹いっぱい。 ：02/07/28 21:47

もとがNeXT/OpenStepだからな。

701 ：名無しさん＠お腹いっぱい。 ：02/07/28 23:18

「Darwinはどうよ？」シンプルでいいんじゃない？
スレタイをいくら工夫しても気に食わない書き込みする奴はいるさ。

702 ：名無しさん＠お腹いっぱい。 ：02/07/29 01:10

「ウニクサがDarwinをかたるスレ Part3 1/3」

703 ：名無しさん＠お腹いっぱい。 ：02/07/29 01:47

IPsec、調子よろしおますか?
http://www.kame.net/newsletter/20020322/

704 ：名無しさん＠お腹いっぱい。 ：02/07/29 09:15

つらつらとxnu見ていたら、osfmk/i386のcpu_number.hに

#if NCPUS > 8
#error cpu_number() definition only works for #cpus <= 8
#else

なる所を発見。
いろいろと邪推してしまいそうです。
もしかすると、OPENSTEPのコードがそのまま残っているだけ???

705 ：名無しさん＠お腹いっぱい。 ：02/07/29 11:24

「MacOSXはズバリ最高!!(マカ熱烈歓迎)」にしろ

706 ：名無しさん＠お腹いっぱい。 ：02/07/29 15:38

マカーは役に立たないし、うざいだけだから、いらない。

707 ：名無しさん＠お腹いっぱい。 ：02/07/29 15:38

>>705
是非ともそのスレはUNIX板ではなく新Mac板に立ててくれ。
UNIX板には立てるな。

708 ：名無しさん＠お腹いっぱい。 ：02/07/29 15:41

タイトルどうでもいいよ。ノイズが入らないなら。
あと、sageてくれよ。

709 ：名無しさん＠お腹いっぱい。 ：02/07/29 16:00

>>708
何故？

710 ：名無しさん＠お腹いっぱい。 ：02/07/29 16:37

「蘇ったNeXTStepはどうよ？」でどうよ？

711 ：名無しさん＠お腹いっぱい。 ：02/07/29 17:31

>>704
それはAPICの仕様かなにかの制限じゃないですか。
すくなくともMachにそういう制限は無かったよ。

712 ：名無しさん＠お腹いっぱい。 ：02/07/29 18:26

>>710
その禿しくマニアックな綴りはどうにかならんのか？

713 ：名無しさん＠お腹いっぱい。 ：02/07/29 18:29

>>704
NeXTSTEP/OPENSTEPにはSMP対応カーネルなど（少なくとも公式には）
存在しませんでしたが何か？

714 ：名無しさん＠お腹いっぱい。 ：02/07/29 22:45

>>712
文句はJobsに言え。

715 ：名無しさん＠お腹いっぱい。 ：02/07/29 22:50

>>713

んだんだ、公式には 1CPU版しかなかったべさ。

68040 x 2 のDual 試作機はx1よりも遅かったし、PPC601ではシングルしか
試作されなかったし、その直後にJobsが「ハードウェアやんぺ」してくれた
ので日の目さえ浴びれなかった(新川崎には転がってたがな)

Canonが引き取ったNeXTの工場がFirePowerになり、日本電算機のJPower
になったのは... ま、余談だな。

716 ：名無しさん＠お腹いっぱい。 ：02/07/29 23:21

誰かおおもとのMachのコードチェックｷﾎﾞﾝﾇ

717 ：名無しさん＠お腹いっぱい。 ：02/07/29 23:31

>>716
MkLinuxのカーネルソースでも落してくればぁ〜

718 ：名無しさん＠お腹いっぱい。 ：02/07/29 23:33

>>717
それじゃ「おおもと」にならんでしょ。
ちょっとうんざり。

719 ：名無しさん＠お腹いっぱい。 ：02/07/29 23:34

>>718
MIT版のほうってこと？

720 ：名無しさん＠お腹いっぱい。 ：02/07/29 23:35

なんでMITが出てくるの？

721 ：名無しさん＠お腹いっぱい。 ：02/07/29 23:37

ああメンゴ、CMUね…

722 ：名無しさん＠お腹いっぱい。 ：02/07/29 23:39

2.5以前のだよ。
自分で見ることのできるソースは見るさ。

723 ：名無しさん＠お腹いっぱい。 ：02/07/30 00:11

つうかさー、おおもとのMachにはPPCのはあるのかよ
Machはcurrent_cpu()でごちゃごちゃ、ってだけとちがう？
問題はMPをサポートしてるハードに近い部分だと思うがどうよ

read.cgi ver5.26+ (01/10/21-)