<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
	<title><![CDATA[ No.324 - 電装工芸日記 - 舞台照明機器の製作とか - ]]></title>
	<link>https://www.densokogei.jp/tegalog/tegalog.cgi</link>
	<description><![CDATA[ 今年は開発案件を進めたい ]]></description>
	<language>ja</language>
	<copyright>Copyright 2026</copyright>
	<lastBuildDate>Fri, 24 Apr 2026 07:46:09 +0900</lastBuildDate>
	<generator><![CDATA[ <!-- てがろぐ Version: -->Powered by <a href="https://www.nishishi.com/cgi/tegalog/" target="_top">てがろぐ</a> Ver 3.4.0 ]]></generator>
	<!-- BEGIN ENTRIES -->
	<!-- One Entry Data for RSS Feed -->
<item>
	<title><![CDATA[ 　numpy.arrayを含むtupleをsocketで送る… ]]></title>
	<description><![CDATA[ 　numpy.arrayを含むtupleをsocketで送るにはシリアル化ってのをすればいいらしい。pythonのオブジェクトをバイナリ化する方法とのこと。<br />　pickleというライブラリを使います。pickle.dumps()でシリアル化し、pickle.loads()で戻します。<br />　テキストと３次元のnumpy.arrayが混在するtupleが一発で処理出来ました。<br />　変換したデータのtypeはbytesですからsocketで送れるハズです。<br /><br />　ただ、pickleのシリアル化/復号には時間がかかる様子。<br />　先人の調査によると、scoket自体はとても速いけれどpickleの処理が案外遅くて総処理時間は他の方法と似たり寄ったりみたい。<br />　ただ、先人の比較方法はデータ量を起点にする比較が主で、都度のデータは少なくコネクションの回数が多いケースの比較ではありません。multiprocessingのQueueはコネクション毎のマネージ処理が重い感じがするので、コネクション自体は軽いsocketに分があるかもしれません。<br />　また、DMXのスロットデータを格納するnumpy.arrayは何も指定しないとint32やint64になりますが、uint8やuint16を指定すれば１スロット当たりのデータ長は小さくなります。つまり、データ総量が小さくなります。<br />　試さないとわからんですけど、オーバーヘッドが大きい通信処理でデータ量を減らせば十分な速度を確保できる期待感があります。DMXの1スロットは1バイトですから、Art-Netエンジンではスロットに対する計算処理をせずにuint8で運用するのがいいのかもしれません。今のところ、比較抽出のnumpy.maxはあってもスロットデータに計算らしい計算は当てないのでuint8で運用しても問題無さそう。<br />　つか、通信自体はsocketが凄く軽いことに驚いた。PythonというよりOS本体に依存するので当然かもしれませんが。<br /><br /><a href="https&#58;//www.densokogei.jp/tegalog/tegalog.cgi?tag=%50%79%74%68%6f%6e" class="taglink" title="Python">#Python</a>  -- Posted by 電装工芸 〔850文字〕 ]]></description>
	<link>https://www.densokogei.jp/tegalog/tegalog.cgi?postid=324</link>
	<guid>https://www.densokogei.jp/tegalog/tegalog.cgi?postid=324</guid>
	<category>tegalog</category>
	<pubDate>Thu, 07 Jul 2022 21:08:52 +0900</pubDate>
</item>

	<!-- END ENTRIES -->
</channel>
</rss>

