i presented my idea of adding a keyword queue
to c that will build internal queue of function calls
and then run it after the scope of parent function ends

like

void f()
{ queued f1();
queued f2();
queued f3();
}

will do (behind the scene)

internal_queue[0].fp = f1;
internal_queue[1].fp = f2;
internal_queue[2].fp = f3;

for(int i=0; i<internal_queue_top) internal_queue[i].fp()

it aslo should hold the arguments in the queue but i oomitted
it for simplicity (i mean it might be done in few ways and
i dont want to consider now which one is better)

thete is also not fully clear for me when to call the queue,
i assume for now after the parent scope ends but maybe there
would be needed explicit keyword to run it and meybe
c should offer few queues like

queued(1) f1(); //queue number one

such internal queue is good thing for sure imo (or more
caustios to say - seem good for sure)

it gives handy way of decomposition like sai i will calc
mandelbrot code i could write

for(int j=0; j<image_height; j++) queued calc_mandelbrot_vertical_line(j);

and though it not gives much of benefit - it just generates queue of
saj 900 pointers the advantage is 1) it is simple 2) closes
us to paralelisation - as if weare able to run queues in parralel
this all to do it for simple paralelisation

for(int j=0; j<image_height; j++)
queued(1) calc_mandelbrot_vertical_line(j);

run_queue_pararelly(1); //some keyword here needed
//code here 'waits' untill full queue is executed

and thats is - implementation could depend on copmpiler
and hardware manufacturers (it should be run in cpu cores
managed by some manager but maybe also on some hardware
that more resembles gpu channel sets etc)

tghis is in fact probably better thet those kernels i was
writing back then

here above i assume that the queue queued a tasks that are
common ram-write independant.. the question is qhat to
do here with some other tasks that are somewhat colliding

i cannot find hovever for me any exampla good for
consideration for this i mean somewhat colliding tasks that
i could think of to be queued and what i would need to add
yet to help to deal with (manage) that collisions

maybe someone knows such example for consideration?

fir wrote:
>
>
> i presented my idea of adding a keyword queue
> to c that will build internal queue of function calls
> and then run it after the scope of parent function ends
>
>
> like
>
> void f()
> {
> queued f1();
> queued f2();
> queued f3();
> }
>
> will do (behind the scene)
>
> internal_queue[0].fp = f1;
> internal_queue[1].fp = f2;
> internal_queue[2].fp = f3;
>
> for(int i=0; i<internal_queue_top) internal_queue[i].fp()
>
> it aslo should hold the arguments in the queue but i oomitted
> it for simplicity (i mean it might be done in few ways and
> i dont want to consider now which one is better)
>
> thete is also not fully clear for me when to call the queue,
> i assume for now after the parent scope ends but maybe there
> would be needed explicit keyword to run it and meybe
> c should offer few queues like
>
> queued(1) f1(); //queue number one
>
> such internal queue is good thing for sure imo (or more
> caustios to say - seem good for sure)
>
> it gives handy way of decomposition like sai i will calc
> mandelbrot code i could write
>
> for(int j=0; j<image_height; j++) queued calc_mandelbrot_vertical_line(j);
>
> and though it not gives much of benefit - it just generates queue of
> saj 900 pointers the advantage is 1) it is simple 2) closes
> us to paralelisation - as if weare able to run queues in parralel
> this all to do it for simple paralelisation
>
> for(int j=0; j<image_height; j++)
> queued(1) calc_mandelbrot_vertical_line(j);
>
> run_queue_pararelly(1); //some keyword here needed
> //code here 'waits' untill full queue is executed
>
>
> and thats is - implementation could depend on copmpiler
> and hardware manufacturers (it should be run in cpu cores
> managed by some manager but maybe also on some hardware
> that more resembles gpu channel sets etc)
>
> tghis is in fact probably better thet those kernels i was
> writing back then
>
> here above i assume that the queue queued a tasks that are
> common ram-write independant.. the question is qhat to
> do here with some other tasks that are somewhat colliding
>
> i cannot find hovever for me any exampla good for
> consideration for this i mean somewhat colliding tasks that
> i could think of to be queued and what i would need to add
> yet to help to deal with (manage) that collisions
>
> maybe someone knows such example for consideration?

anyway though i dont know the answer, as i cant state question
as for a moment, i may say that this queue is good thing becouse it
shows a direction - first part - and the rest i think is much easier

for exampel i think if you had such couple of queued fubctions
and they are somewhat dependant they may comunicate by reading its own
variables - write can do a crash but read is safe imo and
such isleted function can just check what his neighbour state is and use
it...instead of thi rather idiotioc waited in loop or mutex it could
maybe eventually put himself at the end of the queue (or his child) -
and this putting child at end would mean "do it later then"

fir wrote:
> fir wrote:
>>
>>
>> i presented my idea of adding a keyword queue
>> to c that will build internal queue of function calls
>> and then run it after the scope of parent function ends
>>
>>
>> like
>>
>> void f()
>> {
>> queued f1();
>> queued f2();
>> queued f3();
>> }
>>
>> will do (behind the scene)
>>
>> internal_queue[0].fp = f1;
>> internal_queue[1].fp = f2;
>> internal_queue[2].fp = f3;
>>
>> for(int i=0; i<internal_queue_top) internal_queue[i].fp()
>>
>> it aslo should hold the arguments in the queue but i oomitted
>> it for simplicity (i mean it might be done in few ways and
>> i dont want to consider now which one is better)
>>
>> thete is also not fully clear for me when to call the queue,
>> i assume for now after the parent scope ends but maybe there
>> would be needed explicit keyword to run it and meybe
>> c should offer few queues like
>>
>> queued(1) f1(); //queue number one
>>
>> such internal queue is good thing for sure imo (or more
>> caustios to say - seem good for sure)
>>
>> it gives handy way of decomposition like sai i will calc
>> mandelbrot code i could write
>>
>> for(int j=0; j<image_height; j++) queued
>> calc_mandelbrot_vertical_line(j);
>>
>> and though it not gives much of benefit - it just generates queue of
>> saj 900 pointers the advantage is 1) it is simple 2) closes
>> us to paralelisation - as if weare able to run queues in parralel
>> this all to do it for simple paralelisation
>>
>> for(int j=0; j<image_height; j++)
>> queued(1) calc_mandelbrot_vertical_line(j);
>>
>> run_queue_pararelly(1); //some keyword here needed
>> //code here 'waits' untill full queue is executed
>>
>>
>> and thats is - implementation could depend on copmpiler
>> and hardware manufacturers (it should be run in cpu cores
>> managed by some manager but maybe also on some hardware
>> that more resembles gpu channel sets etc)
>>
>> tghis is in fact probably better thet those kernels i was
>> writing back then
>>
>> here above i assume that the queue queued a tasks that are
>> common ram-write independant.. the question is qhat to
>> do here with some other tasks that are somewhat colliding
>>
>> i cannot find hovever for me any exampla good for
>> consideration for this i mean somewhat colliding tasks that
>> i could think of to be queued and what i would need to add
>> yet to help to deal with (manage) that collisions
>>
>> maybe someone knows such example for consideration?
>
> anyway though i dont know the answer, as i cant state question
> as for a moment, i may say that this queue is good thing becouse it
> shows a direction - first part - and the rest i think is much easier
>
> for exampel i think if you had such couple of queued fubctions
> and they are somewhat dependant they may comunicate by reading its own
> variables - write can do a crash but read is safe imo and
> such isleted function can just check what his neighbour state is and use
> it...instead of thi rather idiotioc waited in loop or mutex it could
> maybe eventually put himself at the end of the queue (or his child) -
> and this putting child at end would mean "do it later then"

in fact i dont know to much cases for paralelisation, some i can think of:
1) thing like mandelbrot drawing - strightforward paralelisation (separated)

2) raytracing - im not sure but as far as i remember its also
strightforward i mean you can divide screen on pieces each piece
generates rays, and checks the scene collisions

3) rasterisation - also not sure but here input is a big arrays of
triangles (geometry) - probably this input can be divided on parts
the rasterizer multiplies it by camera matrice and projects on 2d
then rasyerises... possibly each of this piece can be rendered into
seoarate frame+depthbuffer than after ar generated those separate
buffers can be "added"

but each of this case seem to be simple do no oportunnity
to test more complex queue scenarios