So for now the best is to build a toy that is equivalent in processing time to the original and see by myself what I'm able to get. We have many ideas, many theories due to the nature of the GC so the best is to try.
Páll -> Thanks for the links Le mardi 31 mai 2016 18:44:17 UTC+2, Páll Haraldsson a écrit : > > On Monday, May 30, 2016 at 8:19:34 PM UTC, Tobias Knopp wrote: >> >> If you are prepared to make your code to not perform any heap >> allocations, I don't see a reason why there should be any issue. When I >> once worked on a very first multi-threading version of Julia I wrote >> exactly such functions that won't trigger gc since the later was not thread >> safe. This can be hard work but I would assume that its at least not more >> work than implementing the application in C/C++ (assuming that you have >> some Julia experience) >> > > I would really like to know why the work is hard, is it getting rid of the > allocations, or being sure there are no more hidden in your code? I would > also like to know then if you can do the same as in D language: > > http://wiki.dlang.org/Memory_Management > > The most reliable way to guarantee latency is to preallocate all data that > will be needed by the time critical portion. If no calls to allocate memory > are done, the GC will not run and so will not cause the maximum latency to > be exceeded. > > It is possible to create a real-time thread by detaching it from the > runtime, marking the thread function @nogc, and ensuring the real-time > thread does not hold any GC roots. GC objects can still be used in the > real-time thread, but they must be referenced from other threads to prevent > them from being collected." > > that is would it be possible to make a macro @nogc and mark functions in a > similar way? I'm not aware that such a macro is available, to disallow. > There is a macro, e.g. @time, that is not sufficient, that shows GC > actitivy, but knowing there was none could have been an accident; if you > run your code again and memory fills up you see different result. > > As with D, the GC in Julia is optional. The above @nogc, is really the > only thing different, that I can think of that is better with their > optional memory management. But I'm no expert on D, and I mey not have > looked too closely: > > https://dlang.org/spec/garbage.html > > >> Tobi >> >> Am Montag, 30. Mai 2016 12:00:13 UTC+2 schrieb John leger: >>> >>> Hi everyone, >>> >>> I am working in astronomy and we are thinking of using Julia for a real >>> time, high performance adaptive optics system on a solar telescope. >>> >>> This is how the system is supposed to work: >>> 1) the image is read from the camera >>> 2) some correction are applied >>> 3) the atmospheric turbulence is numerically estimated in order to >>> calculate the command to be sent to the deformable mirror >>> >>> The overall process should be executed in less than 1ms so that it can >>> be integrated to the chain (closed loop). >>> >>> Do you think it is possible to do all the computation in Julia or would >>> it be better to code some part in C/C++. What I fear the most is the GC but >>> in our case we can pre-allocate everything, so once we launch the system >>> there will not be any memory allocated during the experiment and it will >>> run for days. >>> >>> So, what do you think? Considering the current state of Julia will I be >>> able to get the performances I need. Will the garbage collector be an >>> hindrance ? >>> >>> Thank you. >>> >>
