06:16 <Neeraj> Hi @all mentor, I would be grateful if you could spare a few minutes to review my proposal and provide feedback.

07:31 <satacker[m]> <Neeraj> "Hi @all mentor, I would be..." <- Sure, please ping me.

07:34 <Neeraj> satacker[m] , hi sir can you review my proposal, and give me some feedback

07:36 <Arnav-Negi> satacker[m] Hi I had a use case in mind should i put it here or in a query to you?

08:21 <satacker[m]> <Neeraj> "satacker , hi sir can you review..." <- Please refrain from addressing me as Sir.

08:21 <satacker[m]> <Arnav-Negi> "satacker Hi I had a use case..." <- You can put it right here. Need not worry.

10:01 <Arnav-Negi> satacker[m] I was thinking about using async I/O in a server-client model for the server to handle client connections asynchronously

10:01 <Arnav-Negi> I can formulate this better in some time if the idea seems okay to you

10:03 <satacker[m]> Yes, this seems to be better than the game stuff you proposed earlier, although the mechanism is in most cases server-client. But go on, elaborate more.

10:21 <Arnav-Negi> Yeah is it fine if I elaborate after 2-3 hours?

10:22 <Arnav-Negi> Also "although the mechanism is in most cases server-client" I didn't get what this means

10:45 <satacker[m]> By that I meant that it's a common use case; there are many applications that rely on server-client model. Thus you'll have to elaborate.

10:51 <Arnav-Negi> Ohh yeah sure

11:12 <zao> On frame processing - HPX and games are a weird mix as there's a fair amount of stuff that has thread affinity there and you'd have to mix a traditional game loop and message pump with HPX threads without them bogging the main thread down. I never managed to figure out how to weave in HPX, despite people here advising me on how it might be done.

11:12 <zao> That might say more about my ability though :D

11:15 <satacker[m]> zao: :D

11:15 <satacker[m]> Also, do you have any suggestions for Async I/O P2300 and coroutines?

11:18 <satacker[m]> https://github.com/STEllAR-GROUP/hpx/wiki/Google-Summer-of-Code-%28GSoC%29-2023#async-io-using-coroutines-and-sr

11:18 <satacker[m]> This one

11:24 <HHN93> What is the procedure to submit GSoC proposal? simple fill it on the gsoc website?

11:24 <HHN93> or do we have to send it to any mailing list?

11:25 <satacker[m]> You should be able to see your status on summerofcode dasboard

11:25 <satacker[m]> There's no need to mail anything to anyone

11:26 <HHN93> oh ok, some other organisations require you to mail it so wanted confirm if ste||ar requires us to do it too

11:43 <HHN93> how can we get cmake to output assembly?

11:43 <HHN93> obj dump works but I want the compiler to generate .asm with the -fverbose-asm

11:47 <zao> I'd reckon that one of the least horrible solutions is probably to do a verbose or no-op build and copy+modify the compiler invocation it does.

11:48 <zao> Ooh, you could even replace the compiler with a small script that looks at its command line and runs it twice, once with -S -fverbose-asm and once to compile the actual thing :D

11:49 <zao> (all great solutions, I'm sure)

11:49 <zao> As for getting it to do it properly, I for one do not want to dig into CMake deeper than I need to.

12:20 <K-ballo> i doubt there's a "proper" way, cmake builds binaries

12:20 <K-ballo> it may be able to dump assembly on the side, or even generate assembly while failing to actually build

12:42 <Arnav-Negi> satacker[m] So in a multithreaded server model, the server application creates threads for each client connection

12:43 <Arnav-Negi> and then there is an I/O operation for the request

12:43 <Arnav-Negi> Instead we can do this using a thread pool and coroutines along to implement asynchronous I/O

12:44 <Arnav-Negi> This would ensure the server is always doing constructive work since it doesnt have to wait for I/O

12:47 <Arnav-Negi> I would love to have some feedback on this, I might also be able to add S/R to the use case once I read more documentation on P2300

13:42 <satacker[m]> Does HPX have thread pools?

13:43 <satacker[m]> gonidelis: any suggestions for the use case?

13:44 <hkaiser> satacker[m]: all of hpx is a giant thread pool ;-)

13:46 <satacker[m]> :-) well, umm, ...

13:48 <hkaiser> satacker[m]: what are you looking for?

13:50 <satacker[m]> Some libraries define threadpool as a constant number of threads that run in parallel and keep the incoming work spinning between those.

13:50 <hkaiser> yes, that's what hpx does

13:51 <hkaiser> you can also create more than one pool to separate NUMA domains, for instance

13:56 <satacker[m]> Okay, time for revelation, for the project that was an example, I was expecting to use more than one Numa domain and read large scale graphs, i.e. simply use BFS/DFS/etc. And process the required node stored on disk.

13:56 <satacker[m]> In this example, BFS/DFS/etc will use S/R facilities, I/O will be done with io_uring and coroutines.

13:57 <satacker[m]> srinivasyadav18: hkaiser: anything better that comes to your mind?

13:58 <hkaiser> sounds nice, gonidelis[m] works on porting the NWGraph library to HPX, this might be a nice combination

13:59 <satacker[m]> GSoC students, everything is out now, it's up to you to take this project discussion ahead.

16:04 <Arnav-Negi> Has parallelized FFT been implemented as an example yet?