Schedulable lightweight virtual processes and concurrent loops P&L: -11.5 (≃ -20657 JPY)

An approach to building concurrent software
YAML 企画 生産

Imagine a nested for loop, it is composed of multiple loops. We can simulate concurrency by executing parts of loops and rapidly switch between them.

This is what a kernel scheduler does and I think it's a very interesting part of an operating system. Unfortunately most programs are not written to be multithreaded so computers use very little of resources available to them.


年間 IRR: -1.0000
最新 正味現在価値@割引率=0.1: -11.4888 ħ (-20636.71 JPY)
(通知しない) ログインしてください。

(通知しない) ログインしてください。

(通知しない) ログインしてください。

(通知しない) ログインしてください。

(通知しない) ログインしてください。

(通知しない) ログインしてください。

(通知しない) (不必要) ログインしてください。

面白い。 Pythonでの同時実行のネイティブサポートは使用せず、基本的な列挙、インデックス作成、割り当てのみを使用しました。それが理解するのに必要なことだと思います。これには教育的価値があります。

Interesting. You did not use any native support for concurrency in Python, and used only basic enumeration, indexing, assignment. I guess, that is what it takes to understand. This has educational value.

(通知しない) ログインしてください。

それが私がそれを仮想並行性と呼ぶ理由です。 IOの同時実行性を提供するには、スレッドを使用する必要があります 永久にループしたり、ブロックしたりするものは作成できません。だから私はこれからすべてのコードを書いて、決してブロックしたり、繰り返したりしないようにします。これは、マルチスレッドスケジューラの開発中に学んだ重要な教訓です。

ブロッキングはプログラムからは見えません。プログラムは、ブロックしていることを認識していません。メソッドがブロックして回避できることを知っておく必要があります。 私の他のアイデアは、並列のwhile doループで、構文糖衣構文を介してブロッキングを非ブロッキングに変更します。 こんな感じ

A1=並列while{ Buf = socket.recv(1024) } 行う { Parallel for(Socket socket:sockets){ Socket.send(buf) } } クロスマージA1

この構文は、データの受信をブロックするために複数のスレッドを起動します。そして、それぞれについて、スレッドプール内のスレッドをスピンアップして処理し、すべての接続に並列に送信します。

私が持っているもう1つのアイデアは、優先実行順序を変更することです。そのコードラウンドのそのスケジューラーは、毎回同じ順序でティッカーをロビンします。ループを他のループよりも多く実行できない理由はありません。

That's why I call it virtual concurrency. You would need to use threads to provide IO concurrency Anything that loops forever or blocks cannot be composed. So I shall write all my code going forward to try never block and be reetrant. This is an important lesson I learned while developing my multithreaded scheduler.

Blocking is invisible to the program. The program isn't aware it is blocking. You need to know that a method can block to work around it. My other idea is a parallel while do loop which changes blocking to be non blocking through syntactic sugar. It looks like this

A1 = parallel while { Buf = socket.recv(1024) } Do { Parallel for (Socket socket : sockets) { Socket.send(buf) } } Crossmerge A1

This syntax spins up multiple threads to block on receiving data. And for each one it spins up a thread in a thread pool to handle it and send it to every connection in parallel.

Another idea I have is to change the priority execution order. That scheduler in that code round robins the tickers in the same order every time. There's no reason why we cannot execute the loops some more than others.



    : Mindey
    :  -- 
    :  -- 
    

chronological,
(通知しない) ログインしてください。

スレッドごとに必要なwhile(true)ループは1つだけであることを付け加えておきます。 他のすべては、スレッド内で同時にスケジュールできます。

I shall add that you only need one while (true) loop per thread. Everything else can be concurrently scheduled within a thread.



    :  -- 
    : Mindey
    :  -- 
    

chronological,
(通知しない) ログインしてください。

複数のティッカーからの入力を待ってから出力を送信する結合可能なティッカーを作成する必要があります。 これにより、分割してマージするパイプラインを作成できます。

I need to write a Joinable Ticker that waits for inputs from multiple tickers before sending output along. This lets us create pipelines that split and merge.

(通知しない) ログインしてください。

複数のCPUコアのパフォーマンスをどのように利用するかを考えています。コードの書き方を大幅に見直す必要があります。

ループは私の設計と簡単に並列化できることに気づきました。

N = 0 .. N=3×3×3

Nごとにすべてのスレッドでtickメソッドを実行すると、ループ全体を一度に実行できます。

I am thinking of how to use the performance of multiple CPU cores. It requires a drastic rethinking of how we write code!

It occurred to me that loops could be trivially parallelized with my design.

N = 0 .. N = 3×3×3

If you ran the tick method on all threads with every N, you could run the entire loop in one go.

(通知しない) ログインしてください。

私はこれのマルチスレッドバージョンをJoinableループなしで作成しました。でも今回は休憩中です。 どういうわけか、マルチスレッドを結合可能なループに結び付ける必要があります。 参加可能ループが2つ以上の値を受け取った場合、処理を続行します。これにより、パイプライン処理での分割とマージが可能になります。 結合されたプロセスをできるだけ早く発生させ、マルチスレッド化する必要があります。 私の設計では(まだJavaで実装していません)、各スレッドには、チェックできるものを再チェックしてチェックするスケジューラがあります。 問題は、ティックをスレッドに分割することです。ティッカーのレベルが1つしかない場合は簡単です。 一度に8つのバッチにチェックマークを付けることができます。別のスレッドで。 私の例では、3つのコレクションのネストされたループと、2つのタスクに分割され、それらの2つのタスクが1つのタスクに結合されて、結果が出力されます。 ネストされたループ、個別のタスク、および結合されたタスクをバッチで実行する必要があります。 古いスレッドに同時ループを送信する方法が必要です。すべてのスレッドによってチェックされるティックプールと呼ばれる共有コレクションを持つことができます。 現在の製品番号はスレッドに関連付けられています。 64は8の倍数であるため、÷8を選択しました。スレッドあたりのバッチ数をクリーンアップします。

`

一方(真){

ティックプールのForループ:

current [loop] <thisThreadN [loop]の場合:

current [loop] = current [loop] 1

NewTickersOrResult = Loop.tick()

NewTickersOrResult.isTickersの場合:

NewTickersOrResult.tickersのnewTickerの場合:

 Current [loop] = threadNum×newTicker.size()/ threadCount

 thisThreadN [loop] = threadNum×newTicker.size()/ threadCount threadCount

Pool.extend(NewTickersOrResult.tickers)

そうしないと:

Print(NewTickersOrResult.result)

}

`

I created a multithreading version of this without the Joinable loops. But at this time I am taking a break. I need to somehow tie the multithreading to the joinable loop. When Joinable loop received 2 or more values, it continues processing. This allows a split and merge in pipeline processing. I want joined processes to occur as soon as they can and to be multithreaded. In my design - that I am yet to implement in Java - each thread has a scheduler that rechecks what can be ticked and ticks it. The problem is splitting ticks over threads, it's easy if there is only one level of tickers. You can just tick batches of 8 at a time. In separate threads. My example has a nested loop of 3 collections and a split into two tasks and then those two tasks join into one task to print out the results. I want the nested loops, separate tasks and the joined tasks to be executed in batches. Kind of need a way to send concurrent loops to old threads. Could have a shared collection called the tick pool which is checked by all threads. The current product number is associated with a thread. I picked ÷ 8 due to the 64 being a multiple of 8. Clean number of batches per thread.

```

While (true) {

For loop in tick pool:

If current[loop] < thisThreadN[loop]:

current[loop] = current[loop] + 1

NewTickersOrResult = Loop.tick()

If NewTickersOrResult.isTickers:

For newTicker in NewTickersOrResult.tickers:

 Current[loop] = threadNum × newTicker.size() / threadCount

 thisThreadN[loop] = threadNum × newTicker.size() / threadCount + threadCount

Pool.extend(NewTickersOrResult.tickers)

Else:

Print(NewTickersOrResult.result)

}

```

(通知しない) ログインしてください。

解決する必要のある問題があります。これは並列処理とは関係ありません。

このようなネストされたループがあると想像してください

` 手紙の場合手紙の場合:

数の数について:

印刷(文字番号)

シンボル内のシンボルの場合:

印刷(文字記号) `

これらの3つのループを同時に実行したいと思います。 1つのアプローチは、インデックスに基づいて実行する関数を選択することです。そして、数字と文字をラウンドロビンで結合します。 だから私たちは

A1

A2

このアプローチの問題は、ループが分離されていないことです。それらはマージされた1つのループです。

コレクションをマルチコレクションにすることでこれを解決できると思います。 [文字、[数字、記号] そして、各サブリストのラウンドロビンから選択し、ループを個別のオブジェクトとして公開します。

I have a problem I need to solve. Which isn't related to the parallellism.

Imagine I have a nested loop that looks like this

``` For letter In letters:

For number in numbers:

Print(letter + number)

For symbol in symbols:

Print(letter + symbol) ```

I want these three loops to run concurrently. One approach is to pick the function to run based on the indexes! And merge the numbers and letters together round robin. So we get

A1

A2

The problem with this approach is that the loops aren't separate. They're one loop that has been merged.

I think I can solve this by causing collections to be a multi collection. [Letters, [numbers, symbols] And picking from each sublist round robin and exposing the loops as separate objects.

(通知しない) ログインしてください。

私は自分の論理のバグに気づきました。 スレッド0は、ループの反復0〜8を担当します スレッド1は8-16を担当します スレッド2は16-24を担当します 等々 ラップアラウンドを処理しないという数学的ロジックが原因で、現在、間違ったスレッドでループの反復を実行しています。モジュロ演算子を使用します。 理想的には、各ティッカーはその範囲のスレッドでのみ呼び出されます。

I realised my bug in my logic. Thread 0 is responsible for loop iterations 0-8 Thread 1 is responsible for 8-16 Thread 2 is responsible for 16-24 And so on I'm currently executing loop iterations on the wrong thread due to a mathematical logic of not handling wraparound. I use the modulo operator. Ideally each ticker is only called on the thread for its range.

(通知しない) ログインしてください。