Hello. Forgive for a silly question.
I tried to make it via the Chunk system. But could not understand as.
How it is the best of all to make? (applying parallelism of JOB and ECS)
for ( iFirst = 0; iFirst < iMax; iFirst++ ) {
for ( iSecond = 0; iSecond < iMax; iSecond++ ) {
}
}
If either first or second is readonly you make the outer loop the one that can be written to and dispatch that as an IJobParallelFor or IJobForEach or IJobChunk. If both require writing you need some intermediary data structure and write collapse mechanism to make it thread-safe.
No offense Dreaming as your answer is correct (I think) but if I didnt already have 6+ months of experience twisting my code to work with Burst, I would not have a clue what a single word of that explanation means.
In much simpler terms:
Alexandr, you can have a for loop inside a for loop, except only one of those loops can be “jobified” using IJobParallelFor/ForEach/Chunk. A Job can not be scheduled (started) within another job but a for loop can both be located inside a job struct (Execute method) or can be used to schedule multiple jobs (highly not recommended).
A job example of your two for loops will be:
var jobHandle = new ParallelJob
{
JobMax = iMax;
}.Schedule(iMax, 1);
[BurstCompile] // Never forget!
public struct ParallelJob : IJobParallelFor
{
// [ReadOnly] or [WriteOnly] public NativeArray<Blittable> here!
// Jobs can take [ReadOnly] basic types but must be "wrapped"
//in a NativeArray<int (example)> for [WriteOnly], even if it's a length of 1.
[ReadOnly] public int JobMax;
public void Execute(int index)
{
for (var iSecond = 0; iSecond < JobMax; iSecond++ )
{
// Do stuff
}
}
}
This also doesnt do anything as there’s no read or write NativeArray that the job is accessing but this is a literal Job translation of your two for loops.
Thanks for confirmation of the guesses!
Perhaps:
public void Execute(int index)
{
for (var iSecond = index; iSecond < JobMax; iSecond )
{
// Do stuff
}
}
Thanks for patience.
Thanks.
I am lost from abundance of different information. It is relevant?https://docs.unity3d.com/Packages/com.unity.entities@0.0/manual/component_system.html
https://docs.unity3d.com/Packages/com.unity.entities@0.0/manual/component_group.html
In what difference of ToComponentDataArray and EntityQuery?
How by means of EntityQuery to receive NativeArray? There it is written “After creating a EntityQuery, you canGet a NativeArray containing all the selected entities”.
It is wrong in IJobParallelFor?
public void Execute(int iFirst){
for (var iSecond = iFirst; iSecond < JobMax; iSecond ){
outNativeArray [ iFirst ] = outNativeArray [ iFirst ] + 1;
outNativeArray [ iSecond] = outNativeArray [ iSecond] + 1;
}
}
I about ways to directly find components (without obvious use of NativeArray) and to choose with what to work.
Sort of
struct TestJob : Some_iJobs<Translation>{
public void Execute(Entity entity, int iFirst, ref Translation translation) {
for (var iSecond = iFirst; iSecond < JobMax; iSecond ){
//How here to choose other Translation?
}
}
}
Thanks again for your patience.
I feel your questions are too detailed - try to describe what you are trying to solve, but in a meaningful way (i.e. not “cylce in a cylce”).
For what you are saying, it sounds i.e. like a brute force collision / proximity system. I.e. comparing positions of all entities agains each other?
Translation only as example of a component.
But the general gist is right to compare everything with everything. And make changes if necessary.
It seems to me in the depth of Unity there is something similar for work of Physics. Would be great to have an opportunity to influence this cycle. (Add my code to it and not re-create my own search of elements…)
Ok, that makes it clearer. As usual, there are many solutions to one problem. Depending on where you want to write the results of that comparison to, I suggest:
if you write to same entities:
this parallelizes by chunk
if you write to some data structure:
this parallelizes as you define the batchsize
It is difficult to me to understand in words how exactly it needs to be written without obvious examples.
If it is not difficult, you can give both examples with the Translation component? It will be so much more clear. Thanks a lot! Forgive for inconveniences.
what you ask for is really basic and if you spend a moment trying to figure it out, I am sure you will.
I attach something for you, which is different from your ask, but somewhat similar. it’s an example of two groups of players (spheres), say Group Red and Group Blue targeting the closest enemy of the opposing group. You can ignore the visualization (debug lines via line mesh)
IJobForEach works in parallel?
IJobForEach, IJobChunk work in parallel (per Chunk) unless you schedule them Single
IJobParallelFor works parallel obviously, at a level you control
IJob single thread (you can schedule a few of those to run parallel though, if they do not depend on each other – that’s pretty much what the other jobs do, i think)
I hope this is explained in the manual, check it out…
This is kind of related to a question I asked before, I hope people don’t mind if I post it here. I’m curious what people here would think and how they would make this into a job.
foreach (GameObject gobject in BusinessObjects)
{
currentBusinesscript = gobject.GetComponent<BusinessInfo>();
GameObject [] people = currentBusinesscript.EmployeesInd;
foreach(GameObject dodobject in people)
{
currentBusinesscript.PaperMoneyHeld -= GlobalWages;
dodobject.GetComponent<PersonInfo>().PaperMoneyheld += GlobalWages;
}
}
I have like a 100 entities each with roughly a random number of 0 to 100 entities in an array/dynamic buffer. I did wonder if you could do the whole lot in a single job. I thought about putting the business entities into a single native array and the entire employee entities(about 2000) into another and then iterate through them all with Ijobparrallel or something like that but I don’t think they would match up.
Try to make it an IJob or an IJobForEach using ScheduleSingle first. Given your numbers I suspect that the performance boost from just that might be enough for you. Once you get to that point if you still want to make it run wide, come back with the single-threaded version and we can give you much better opinions and suggestions.
Many thanks, a lot of things became clearer. Especially presence of parallelism everywhere (if not to specify one-threading) except IJob. If iJob depends on other iJob and it is one.
Very much confuses huge existence of classes, but are only units used and it is unclear why so. What of them really should be used? For example iJob is absent in examples to HelloCube.
https://docs.unity3d.com/Packages/com.unity.entities@0.0/api/index.html
Sorry, meant syntax. (The principle, but not the solution of my problem.)))
And how in a physical cursor this problem is solved? (In the same place too it is necessary to compare everything between itself to define a collision.)
I.
MonoBehaviour
for ( iFirst = 0; iFirst < iMax; iFirst++ ) {
for ( iSecond = 0; iSecond < iMax; iSecond++ ) {
}
}
II.
iJob
for ( iFirst = 0; iFirst < iMax; iFirst++ ) {
for ( iSecond = 0; iSecond < iMax; iSecond++ ) {
}
}
III.
IJobForEach
for ( iSecond = 0; iSecond < iMax; iSecond++ ) {
}
This just came on top of my head. This is just algorithm. Didn’t try it.
The idea is to merge arrays into one array and then use it in jobs. You didn’t mention anything about array you are traversing so I didn’t know how the initialization should look like.
// Initialize.
// NOTE: You should use native array. I'm using normal array for simplicity
// These lines should be before scheduling the job.
int[] array = new int[iMax * 2];
for(int i = 0; i < iMax; i++)
{
array[i] = array[i + iMax] = originalArray[i];
}
// This `for` should be a IJobParallelFor job.
// You need to run it iMax to the power of two times to cover all cases
for(int i = 0; i < iMax * iMax; i++)
{
// You can put these lines in one job
int firstIdx = i / iMax;
int secondIdx = iMax + i % iMax;
// Then you can do operations on the array
// Example:
if(array[firstIdx] == array[secondIdx])
// Do something
}
Encoding the algorithm’s iterators into a single iterator with the combination number does allow for better work distribution across threads, but it does not necessarily make the algorithm thread safe. In fact, now both firstIdx and secondIdx must index [ReadOnly] arrays or else you have a race condition.