コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2021年2月18日 >>> 2021年2月9日
link もっと後

2021年2月16日

一般のご家庭にPCは何台ある?

内閣府の「主要耐久消費財等の普及率」「主要耐久消費財の保有数量の推移」(リンク)によると、2人以上の世帯のPC普及率は77.0%、100世帯辺り123.6台(2020年3月)だそうです。

保有世帯だけを考えれば123.6 / 0.77 / 100 = 1.61 [台/世帯] ですから、世帯人数 <PC台数です。PCを日常的に使う習慣がない限り、共有のPCが1台あれば十分ですし、納得感ある結果です。

一般のご家庭にPCは何台置ける?

では、一般のご家庭にPCは最大で何台置けるでしょうか?

PCの消費電力は様々ですが、夢はでっかく、高性能PCとして、AMD Threadripper 3990X, NVIDIA GeForce RTX 3090のマシンを考えましょう。CPUとグラボのTDPは280 + 350W = 630Wです。他の部品や損失を考えると、PC 1台あたり800W程度と思われます。

一般家庭の我が家の電気契約(40A)ですと、5台程度でブレーカーが飛びます。200V系のコンセントを増設し、200Vで給電すれば電流は半減するので10台くらいは置けるでしょう。30A契約のご家庭も多いでしょうから、「高性能PC 8〜10台」これが一般のご家庭の限界と思われます。

逸般の誤家庭にPCは何台置ける?

では、色々逸脱した逸般の誤家庭の場合はどうでしょうか?

家庭の電気契約は「従量電灯B」という契約(従量電灯B・C電気料金プラン - 東京電力エナジーパートナー株式会社)がほとんどです。従量電灯Bの最大契約アンペア数は60Aで、全て200Vから取ると最大12kWです。したがって12000 / 800 = 15台が限界です。ふーむ、意外と伸びませんね。

冷却の電力は完全に無視しています。冷却を無視したまま15台も置いたら、家の中は一瞬で灼熱地獄になり、人間もPCも死ぬと思います。

業務用なら青天井

大口需要向けに「従量電灯C」という契約もあります。

従量電灯Cの場合10Aごとに基本料金が従量的に増える青天井の契約になります。一般家庭でも契約可能のようです。基本料金を比較すると、従量電灯B< 従量電灯Cとなるため、一般のご家庭だと損するだけで契約する意味はありません。

本来、家電が大量にある豪邸や、業務用の電気機器がある商店用ですが、60Aに満足できない真の逸般の誤家庭にも向いているかもしれませんね。

編集者:すずき(2021/02/28 00:27)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2021年2月15日

Wikipediaの数学のページを眺める

群とか環とか体とか、大学で教えてもらった記憶がうっすらありますが、何回見ても忘れます。幸いにもWikipedia先生に割と詳しく解説されているので、まとめておこうと思います。

集合Gと二項演算uの組(G, u)を考えます。uは乗法や加法と呼ばれる場合があるようです。以降u(a, b) をa + bの形で表します。

半群
閉性を満たす: 二項演算u(u: G + G -> G)の結果はGに含まれる
結合法則を満たす: a + (b + c) = (a + b) + c
モノイド
単位元eが存在する: a + e = e + a、整数の加法でいえば0
逆元xが存在する: a + x = x + a = e整数の加法でいえば -a
アーベル群
交換法則を満たす: a + b = b + a

下にある群は、上の群の性質をすべて満たします(以降も特に断りがなければ同じ)。なので、モノイドは半群の性質を満たしますし、群はモノイドと半群の性質を満たします。

集合Rと2つの二項演算u, tの組(R, u, t) を考えます。(R, u) はアーベル群です。uは加法、tは乗法と呼ばれるようです。以降t(a, b) をa * bの形で表します。

乗法半群
閉性を満たす: 二項演算t(t: R * R -> R)の結果はRに含まれる
結合法則を満たす: a * (b * c) = (a * b) * c
乗法モノイド
単位元eが存在する: a * e = e * a、整数の乗法でいえば1
環(モノイドでない場合がある)
加法の上に左分配律を満たす: a * (b + c) = (a * b) + (a * c)
加法の上に右分配律を満たす: (a + b) * c = (a * c) + (b * c)
可換環(モノイドでない場合がある)
交換法則を満たす: a * b = b * a

群と違って、環はモノイド(単位元が存在する)である必要はないみたいです。

零因子

可換環では零でない零因子という困ったことが起きます。

  • a * x = 0となるx != 0が存在するときaは左零因子
  • y * a = 0となるy != 0が存在するときaは右零因子

困る例として挙げられていたのはa * b = 0かつa != 0でもb = 0とは限らない、もしくは、a * b = a * cかつa != 0でも、b = cとは限らない、という例でした。

具体的な例が載ってませんでしたが、行列の和と積を考えると発生しそうに思えます。

左零因子になるかな?
A =
[1, 1]
[0, 0]

B =
[ 1, 0]
[-1, 0]

C =
[0, -1]
[0,  1]

A * B =
[0, 0]
[0, 0]

A * C =
[0, 0]
[0, 0]

A != 0だがB, Cは零行列ではない。A * B = A * Cだが、B = Cでもない。

環はこういうパターンが無数に出てきて、さらに条件を厳しくしないと困る場合がありますよ、ということですかね?

整域

変わった名前ですが、環の一種のようです。環で発生する零因子による困った問題を排除しています。

整域(乗法モノイドである必要がある)
零が唯一の零因子: a * x = 0かつa != 0ならばx = 0
非自明環: 自明環(零のみの集合は {0} 環となるので、自明環と呼ばれる)ではない

力尽きた

群環体の「体」まで辿り着きたかったのですが、整閉整域、一意分解整域、主イデアル整域、ユークリッド整域、体、有限体、と訳のわからない名前のオンパレードで、力尽きました。また今度調べます。

編集者:すずき(2021/02/16 01:52)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2021年2月14日

USB Type-C DisplayPort Alternate mode

現在使っているThinkPad E480はUSB Type-C端子とHDMI端子しかありません。先日(2021年2月12日の日記参照)新しく購入したディスプレイ2つに画像を出力するには、USB Type-CのDisplayPort Alternate Mode(VESAの機能紹介のページ(英語))を使う必要があります。接続はこんな感じです。


E480とデュアルディスプレイの接続

このときE480とディスプレイを繋ぐUSB Type-Cケーブルは3つの役割を果たします。

  • USB 2.0/3.1のデータ通信(ディスプレイがUSBハブになる)
  • USB Power Deliveryによる電力供給
  • DisplayPort Alternate Modeによる画像出力

たった1本のUSB Type-Cケーブルで3役もこなす凄いヤツです。今まで「ACアダプタ」「DisplayPort」「USB Type-A」の3つに分かれていたコネクタが、USB Type-C 1つに統合できますから、省スペースが命のノートPCにとっては大歓迎の機能でしょう。

実はさほど便利じゃない

そんな凄いヤツを使い始めて数日ですが、既に嫌になってきました。正直な感想として、少なくともユーザーからすると便利と思えないし、使わなくて良いなら使いたくないです。

ケーブルの問題
1本で済むのは良いですが、ケーブルが硬すぎます。USB PD対応USB 3.1ケーブルはかなり高速な信号を通す関係上、3重シールド5〜6mm幅以上のごついケーブルばかりです。これならACアダプタとHDMI 2本の方がまだマシです。どちらもかなり細いので。
E480の問題
ノートPCの液晶、DisplayPort、HDMIの3系統を使えると思いきや、3画面に拡張デスクトップを設定するとバグるので、ノートPCの液晶とDisplayPortをミラーにしています。ノートPCの液晶が完全に無意味ですが、蓋を閉めるとスリープしちゃうので、半開きでテーブルの隅に放置しています。切ない。
USBハブの問題
ディスプレイがUSBハブの役目も果たしますが、ディスプレイの電源を切るとUSBハブとしての機能もOFFになります。マウス程度なら問題ありませんが、通信するような機器は繋ぐと毎回切られてストレスMAXです。あとUSBオーディオDACは繋いでも動作しませんでした。何か制約があるんですかね?
USB PDの問題
ディスプレイ側のUSB PDによる供給力の上限は、現状60Wの製品が多いです。60WはノートPCによっては給電能力がギリギリです。ディスプレイのUSB PD供給能力が足りない場合、純正アダプタに戻して給電し出画は諦めるorバッテリーを削りつつDisplayPort Altで出画するorディスプレイを買い替える、究極の3択を迫られます。

ケーブルの問題は今後、技術革新で細くなることを祈るしかありません。E480の問題は回避策不明です。HWの制約?USBハブの問題は、E480ならUSB Type-Aコネクタが別にあるので、そちらを使えば回避可能です。USB PDの問題は今の所E480だと困っていません。

しかし将来的にノートPCを買い換えるとUSB PDの問題が起きる可能性があります。回避策はあるでしょうか?USB Type-Cが3つ付いていて、1つはDisplayPort、2つ目はUSB PD電源供給、3つ目はPCに繋ぐ、変なハブ的なものがあれば良い?もはや「ケーブル1本でOK」のコンセプトは完全崩壊だし、ディスプレイ側のUSB PDは死蔵確定です。そんな訳のわからんことになるなら、素直にDisplayPortとUSB Type-Cのコネクタ2個付けてくれよって思います。

そもそもDislayPortとUSB PDなんて全く無関係のものを統合したら、どちらか壊れただけでPCが機能不全になることくらい、聡明なVESAやUSB-IFの面々には明らかなはずですけど、何でこんなデザインにしたんですかね?理解しがたいよ……。

USB PDとDisplayPort Alt Modeを見ると思い出すのは、あの商品

昔SHARP SF1という製品がありました(DIMEの記事)。スーパーファミコンとテレビが1つに合体した、当時小学生だった私には夢のような製品でした。配線なしで見た目スッキリ、場所も取らない、ACアダプタやビデオケーブルを接続する手間も不要、いかにも便利そうじゃないですか?結構お高いのもあって、友達が持っているのを見て羨ましかったです。USB Type-Cも似たような売り文句です。

しかし後から聞くところによれば、テレビが故障するとスーパーファミコンを外せないから他のテレビに繋げなくて困る、逆にスーパーファミコンが故障するとテレビごと修理になって高ぇわテレビがなくなるわで困る、元より不便になっています。元々バラバラの製品を無理やり一蓮托生にしたら、そりゃそうなりますわな……。無関係の機能をデタラメに統合してはいけない、という好例です。

残念なことにUSB Type-CもDisplayPortとUSB PDの機能統合で、似たような落とし穴に落ちています。小学生の私に「21世紀になっても人類はSF1と同じ過ちを繰り返しているよ」って教えてあげたいですね。

編集者:すずき(2021/02/15 21:33)

コメント一覧

  • hdkさん(2021/02/15 06:24)
    テレビデオも壊れたときがと聞いて買いませんでしたが、狭い学生宿舎で数年使えればいいだけならあれも手だったのかもとは思います。
    USB Type-Cのハブは、一本させば全部つながるというのなら、外して会議室や外出先に持ち出し・戻ってつなぐ用途では楽になりそうです。同様に使えるドッキングステーションやウルトラベースもありましたよね。
  • すずきさん(2021/02/15 11:27)
    そうですね、1年だけとか、出張の時だけ、といった使い方にはとても便利だと思います。
    今回は常用したかったので、困りました。DisplayPort Alt mode は存在していただいて構わないんですけど、代わりの機能がないところが一番困ったところです。
open/close この記事にコメントする



2021年2月12日

在宅勤務環境改善

COVID-19が流行し始めた昨年2月ころ、在宅勤務が主となりました。当時の気持ちを正直に言えば「すぐ収束して、電車通勤に戻るだろう」で、完全にナメていました。在宅勤務の環境もまったく整えておらず、ダイニングテーブル、ノートPC+8インチのモバイルディスプレイでした。夕食時は邪魔だから、仕事道具をガサガサ片付ける、といった具合です。

そんなこんなで1年間やってきたものの、COVID-19の予想外の長期化、それに加えて会社方針(COVID-19が収束しようとしまいと、今後は在宅勤務)もあって、在宅勤務の環境を改善することにしました。

部屋

家には、奥さんが一昨年の在宅勤務で使っていた部屋があって、幅100cmの机と背もたれ付きのオフィスチェアがあります。そのスペースを譲ってもらうことにしました。

  • 1年目: 奥さん在宅勤務、私は電車通勤
  • 2年目: 2人共電車通勤
  • 3年目: 奥さん電車通勤、私は在宅勤務

すっかり勤務形態が逆転しました。会社のみなさんの話を聞くと、東京の狭い家で夫婦とも在宅勤務、子供まで自粛で家に居て、全く仕事にならん……みたいな地獄化したご家庭もあるみたい。我が家も夫婦同時に在宅勤務だと、スペースの確保がちょっと大変だったと思います。交代で在宅勤務になったのは、今思えば割とラッキーだったのかな?

テーブル

ダイニングテーブルはしっかりした作りで、間違いなく家で一番上等なテーブルです。一方のダイニングチェアは年中使い続けるような椅子ではなかったらしく、1年間酷使し続けたところ、座面、背面のクッションが潰れ椅子のフレームが腰にガツガツ当たるようになりました。痛ぇよーー。

部屋を移ってスペースが広がったので、大きめのデュアルディスプレイも目指します。幅120cmの机を買い足し100cmの机は横向きに合わせL字にします。

買ったのは山善のAMDT-1260 AMDL-70という一番シンプルな天板と脚だけのテーブルですAmazonへのリンク)。Amazonで9,000円くらいとお安いです。理由はわからないですが、山善の公式サイトには載っていないんですよね。なぜだろね?

ディスプレイ

机の幅を考えると27インチx2が載りそうです。ただし、机の奥行きがあまりない(60cm)ので、大きすぎると端が見えなくなって、かえって使いにくいです。という点を勘案して24インチx2にします。

買ったのはEIZO FlexScan EV2480です。Amazonで1台4万円くらい。デュアルディスプレイにしたので、総額8万円くらい掛かりました。非常に高価ですが、これでも中位機種なんです。ちなみに上位機種のEV2495は1台7万円します。強烈!

FlexScanは重たいのが難点(純正スタンドがめちゃ重い)ですが、変な色やら、映らないやらのトラブルは皆無で非常に快適です。以前勤めてた会社(パナソニックやソシオネクスト)でも大変お世話になりました。良いメーカーですよね。

編集者:すずき(2021/02/15 11:41)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2021年2月11日

デノーマルフラッシュの速度改善効果

目次: ベンチマーク

先日(2021年2月5日の日記参照)非正規化数(Denormal数)の計算は遅いと書きましたが、いかほどでしょうか?どのくらい遅いのか、デノーマルフラッシュでどの程度速くなるのか、この2点について見ていこうと思います。

おそらく世の中のどのFPUも割り算が一番苦手なはずです。入力を正規化数、非正規化数の2パターン用意して、下記の演算をたくさん実行してみます。

浮動小数点の割り算の速度を測るためのコード(中心部分)

#define SIZE    10000

union uuu {
	double f;
	long long n;
};

...

void test_speed(union uuu *val)
{
	for (int i = 0; i < SIZE; i++) {
		dst[i].f =
			val[i].f / 1.08f -
			val[i].f / 1.07f +
			val[i].f / 1.06f -
			val[i].f / 1.05f +
			val[i].f / 1.04f -
			val[i].f / 1.03f +
			val[i].f / 1.02f -
			val[i].f / 1.01f;
	}
}

コードは全部貼り付けると邪魔くさいのでGitHubにおきました(GitHubへのリンク)。前回のFTZ, DAZのテストに使ったコードも一緒に入っています。

x86系のCPU

まずはx86系のCPUで測ってみましょう。手元にあるのはZen系(AMD Ryzen 7 2700)と、Atom系(Intel Pentium J4205)なので、この2つで測ります。コンパイラはgcc (Debian 10.2.1-6) 10.2.1 20210110、最適化レベルはO2です。

Ryzen 7 2700の結果(Linux 5.10.9-1)
10000 loops

Normal -----
FTZ:OFF, DAZ:OFF
  0.912859[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:OFF, DAZ:ON
  0.880695[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:ON, DAZ:OFF
  0.880633[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:ON, DAZ:ON
  0.880653[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)

Denormal -----
FTZ:OFF, DAZ:OFF
  1.806291[s]
  dst : -4.446591e-323(0x8000000000000009)
FTZ:OFF, DAZ:ON
  0.783578[s]
  dst : 0.000000e+00(0x00000000)
FTZ:ON, DAZ:OFF
  1.513203[s]
  dst : 0.000000e+00(0x00000000)
FTZ:ON, DAZ:ON
  0.783183[s]
  dst : 0.000000e+00(0x00000000)
Pentium J4205の結果(Linux 5.4.95)
1000 loops

Normal -----
FTZ:OFF, DAZ:OFF
  1.024671[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:OFF, DAZ:ON
  1.025767[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:ON, DAZ:OFF
  1.025151[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:ON, DAZ:ON
  1.027414[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)

Denormal -----
FTZ:OFF, DAZ:OFF
  12.147070[s]
  dst : -4.446591e-323(0x8000000000000009)
FTZ:OFF, DAZ:ON
  0.309857[s]
  dst : 0.000000e+00(0x00000000)
FTZ:ON, DAZ:OFF
  7.126950[s]
  dst : 0.000000e+00(0x00000000)
FTZ:ON, DAZ:ON
  0.312373[s]
  dst : 0.000000e+00(0x00000000)

Ryzen 7 2700でもPentium J4205でも、Denormal数が計算に出現すると遅くなりますが、J4205はその傾向が顕著で10倍くらい遅いです。FTZ, DAZをONにすると、効果覿面に速くなります。

ARM系のCPU

次にARMで測ってみましょう。手元にあるのはRK3399です。Cortex-A72とCortex-A53が混載されているので、両方で測ります。カーネルはLinux 5.11.0-rc3-next-20210113、コンパイラはgcc (Debian 8.3.0-6) 8.3.0、最適化レベルはO2です。

ARMは仕様上FTZとDAZが分かれていない(FZという両方合わせたような機能がある)ので、片方だけONにした結果はありません。

Cortex-A72の結果
$ taskset 0x10 ./a.out 10000

...

10000 loops

Normal -----
FTZ:OFF, DAZ:OFF
  7.153237[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:ON, DAZ:ON
  7.118581[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)

Denormal -----
FTZ:OFF, DAZ:OFF
  8.008282[s]
  dst : -4.446591e-323(0x8000000000000009)
FTZ:ON, DAZ:ON
  1.779883[s]
  dst : 0.000000e+00(0x00000000)
Cortex-A53の結果
$ taskset 0x1 ./a.out 10000

...

10000 loops

Normal -----
FTZ:OFF, DAZ:OFF
  11.693382[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)
FTZ:ON, DAZ:ON
  11.691307[s]
  dst : -3.668038e-02(0xbfa2c7c56ca81140)

Denormal -----
FTZ:OFF, DAZ:OFF
  12.196882[s]
  dst : -4.446591e-323(0x8000000000000009)
FTZ:ON, DAZ:ON
  11.697961[s]
  dst : 0.000000e+00(0x00000000)

Cortex-A72はデノーマルフラッシュの効果抜群ですが、Cortex-A53はデノーマルフラッシュによる変化はほとんどありません。どちらもARMが設計した同世代のCPUにも関わらず、速度の傾向は大きく異なります。詳細な理由はARMにしかわかりませんが、なかなか興味深い結果です。

編集者:すずき(2023/09/24 13:47)

コメント一覧

  • とおりすがりさん(2022/06/21 18:08)
    詳しくはわからず恐縮なのですが、
    Cortex-A72, A-53 がそれぞれ big.LITTLE 構成における big, little だそうなので, Cortex-A72 のほうがちょっとリッチな回路を積んでいるのかもしれません。
  • すずきさん(2022/06/22 00:20)
    はい、私も同意見です。A72 はおそらくデノーマルフラッシュで遅くならないような設計の FPU なのでしょうね。
open/close この記事にコメントする



link もっと前
2021年2月18日 >>> 2021年2月9日
link もっと後

管理用メニュー

link 記事を新規作成

<2021>
<<<02>>>
-123456
78910111213
14151617181920
21222324252627
28------

最近のコメント5件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」

最近の記事3件

  • link 24年3月25日
    すずき (03/26 03:20)
    「[Might and Magic Book One TASのその後] 目次: Might and Magicファミコン版以前(...」
  • link 21年10月4日
    すずき (03/26 03:14)
    「[Might and Magicファミコン版 - まとめリンク] 目次: Might and Magicファミコン版TASに挑...」
  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/26 03:20