×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

AstroPi3 Scripts revised

  • Posts: 19
  • Thank you received: 1
Not sure if I have a bug here Rob, but could do with a pointer or two if not.

Seems INDI/EKOS can't see my Atik cameras, yet they seem to have drivers in the right place, but then I am only just beginning my Linux Learning...

Posted EKOS output here after searching for asolution on the boards, it contains a link to the initial thread I raised wehen I first got stuck:

indilib.org/forum/ekos/5710-ekos-setup-q...noobie.html?start=24
4 years 5 months ago #44962

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559

Replied by Hy Murveit on topic AstroPi3 Scripts revised

Rob,

One more thing. I have started configuring the KStars part of the install script (could do this with Indi & Phd2 too, I suppose) to compile optimized. Currently your script compiles debug binaries.

That is, I re-ran cmake with the following flag
-DCMAKE_BUILD_TYPE=Release
and then recompiled the entire system with my standard 'make -j 6 kstars'

This results in dramatic speedups for KStars on my RPi4 4Gb. I've suggested to Jasem that he consider releasing this way; he will look into it.
You (and anyone else adventurous) should try and give it a shot. It does make the compile a little slower, but once compiled, it's really much faster.
Let me know what you think!
4 years 5 months ago #45061

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226

Replied by Andrew on topic AstroPi3 Scripts revised


I'm not sure I follow. Are you claiming that applications get a performance boost when compiled this way? Please explain.
4 years 5 months ago #45068

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
This is an interesting idea. I'm not sure about it though. Are you saying there is a speed improvement in building the program or a speed improvement in running the program?

I understand that typically software is distributed as a "release" build instead of a "debug" build. But with KStars I have always built it as debug due to the fact that it is open source software that is continuously under development. So if there is a crash or issue, I would want it to have all the debug symbols so that we can get a detailed backtrace of the crash. Doesn't compiling as a "Release" build mean that the debug symbols would not be available? I think that would be an issue for diagnosing potential problems.
4 years 5 months ago #45069

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559

Replied by Hy Murveit on topic AstroPi3 Scripts revised

@Ihoujin: When you run the compiler the standard way, it does NOT make much of an effort to make your code run quicker (e.g. by noticing that a value you just computed will be needed again soon and keeping it on hand, avoiding a trip to memory. There are many optimizations, see the like below). It simply tries to make the compiler run quickly and accurately. Depending on the code, you can get dramatic improvements with -O2 or -O3 flags to g++. For instance, I noticed that stretching images from my camera in kstars' fitsviewer goes from about 0.5s - 1.0s / image to something like 0.15s/image. I've been looking at the speed of the fitsviewer computations, and those things get much faster with optimization. Of course, code that runs fast anyway, or waits for cameras or the UI won't be affected much. I believe it is standard practice to release optimized code, however, see Rob's point below. Here's a link to the g++ page on its optimizer and what it might try improve: gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Rob: Debug vs execution speed is always a tradeoff. However (a) you can still have all the logs you've had before, and (b) you don't have to strip away the symbol tables, they can mostly still be there and still be used with optimized code. it's just that it's possible that the compiler, depending on its options, will change the order of certain operations, if that doesn't effect the end result but allows for quicker code. I believe that any commercial code you currently use is optimized. I think that for the most part it won't affect debugging you do for other users. For debugging on your own system, sure you can compile with debug flags while developing and debugging if you prefer. The main gotcha is that it is possible that the optimized code, which let's say is optimized correctly but is a little bit different than the non-optimzed code, can expose (or hide) bugs. That is, say you have a memory error (you overwrite some pointers in memory). The debug and optimize versions may react differently in one version than the other, so errors you see in optimized code may not show up in non-optimized code, or vica versa. However, I'd say this is relatively rare and worth the price paid for getting much quicker overall performance. Try it!
4 years 5 months ago #45073

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559

Replied by Hy Murveit on topic AstroPi3 Scripts revised

Rob: and, yes, I was saying that there should be a noticeable improvement in execution speed. Compile times will be longer.
4 years 5 months ago #45074

Please Log in or Create an account to join the conversation.

  • Posts: 472
  • Thank you received: 165
There is CMAKE_BUILD_TYPE=RelWithDebInfo which is a bit of both, you get symbol info so you get useful stack traces, but the code still is optimized. I've found it a good tradeoff between speed when actually using the program and still being able to pinpoint issues if they happen and then possibly switch to debug build if the cause isn't clear and the problem can be reproduced.
4 years 5 months ago #45077

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226

Replied by Andrew on topic AstroPi3 Scripts revised

For me, and many users, debugging is not something I'd get too into, so I would happily try this for myself. Might I suggest creating a new thread under development for this idea.
4 years 5 months ago #45080

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
To clarify,

I don’t mean that by including the debug symbols, that the typical end users would be the ones actually debugging the code. What I mean is that if an end user encounters a reproducible crash, that they could use the debug symbols to get a clear backtrace so that they can send it to the programmers so that they can figure out the issue. On numerous occasions, when a user has reported an error, getting clear crash info from them has been immensely helpful in finding the issue. Don’t get me wrong, log files are also great for finding issues, but if the program actually crashes, then the cause of the crash will not be recorded in the log because the program is now crashed. But if debug symbols are included the user can be told how to get the backtrace and the problem can be found.
4 years 5 months ago #45082

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559

Replied by Hy Murveit on topic AstroPi3 Scripts revised

Agreed. I'm all for symbol tables. Optimization doesn't preclude that.
Perhaps the -DCMAKE_BUILD_TYPE=RelWithDebInfo that @jpaana suggested is the way to go. Haven't tried that.
I do know that optimization, is like a RPi4. Once you have it, you don't want to go back.
4 years 5 months ago #45083

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559

Replied by Hy Murveit on topic AstroPi3 Scripts revised

This gives more details on RelWithDebInfo
bytefreaks.net/tag/relwithdebinfo
4 years 5 months ago #45085

Please Log in or Create an account to join the conversation.

  • Posts: 73
  • Thank you received: 8
I use a pretty neat dual fan all aluminum case I got from Amazon. The whole case is a heat sink and it seems to work pretty well.
My RP4 runs at 47C with default clock speeds.
I then overclocked the GPU and CPU to 600/2000 respectively and now it runs at 51C.

Hopefully that will help speed things up even more.
4 years 5 months ago #45121

Please Log in or Create an account to join the conversation.

Time to create page: 0.466 seconds