Tagged: GSoC Toggle Comment Threads | Keyboard Shortcuts

  • Akarsh Simha 1:28 am on July 17, 2008 Permalink
    Tags: GSoC,   

    Memory Management UI – Trial #2. 

    I’m going on my third north Indian trip tomorrow, spiritual purposes only. So I’m off the net for next 2 days. I happened to hurriedly do this:

    I’d want comments on that UI, because I have no idea about UI design.

  • Akarsh Simha 2:33 am on July 14, 2008 Permalink
    Tags: GSoC, , , Tycho-2   

    2.5 million stars in trunk! 

    Yay! All the machinery for loading 1e6 stars has been moved to trunk and the 2.5-million-star Tycho-2 catalog has moved to the ‘Download Data’ (Get Hot New Stuff) feature. I plan to put up a screencast on how to use this and the conjunction tool from KStars sometime, along with a whole lot of other features.

    To get the Tycho-2 deep catalog, just click on File->Download Data and click ‘Install’ next to ‘Tycho-2 Star Catalog’.

    • Carlos Scarsi 3:53 am on September 2, 2008 Permalink | Log in to Reply

      Hi. I’m new in linux and kstars. My kstars only goes up to mag 9, not 12. The tycho-2 catalog is installed. I’m using it on ubuntu (gnome). Do you know why? Thank you very much. Carlos Scarsi

    • Akarsh Simha 1:02 pm on September 20, 2008 Permalink | Log in to Reply

      @Carlos: Sorry for such a late response. It is probably because you aren’t using the latest version.

      The Tycho-2 catalog works only with KDE 4.1.60 or something like that (and above). Currently, the 2.5 million stars are in what we call the ‘trunk’ (the source code that developers work on). You will either need to wait till Ubuntu ships the new version of KStars or compile it from the sources.

      Mail me at akarshsimha () gmail ! com if you need a faster response. (Replace the brackets by @ and ! by .)

  • Akarsh Simha 5:49 am on June 4, 2008 Permalink
    Tags: GSoC,   

    KStars loads 41560 stars in 225ms!!! 

    “We all know Linux is great…it does infinite loops in 5 seconds.”
    –Linus Torvalds

    KStars is now no longer far behind, thanks to James Bowlin. James seems to know every bit of computer architecture. One interesting thing that I learnt from him, after he repeatedly tried to put it into my head, is that malloc()s are like hard disk seeks. You had better do a BIG malloc() at once than make several small malloc()s. He knew for sure, that much of the time KStars spent in loading stars in the StarComponent::readData() method went into the constructors!

    So he suggested something that I initially thought was un-implementable: Forget C++ constructors. Let’s do our own memory management. Create a template StarObject with some default data initialized in it. Whenever you want to create a new StarObject, just memcpy() it to make a new one!

    Now, the first question I asked is what about those memory allocations that the constructor does? For instance, StarObject::StarObject() creates a new QString to store the spectral type. James said we’d take care of that by allocing them in a StarObject::init() function that sets up our freshly copied StarObject. I still had a lot of doubts in mind.

    I decided to jump in and see what happens. Went and made some changes in StarObject – implemented a StarObject::init() that did the job of a constructor, and after a few segfaults, changed StarObject::SpType from QString, to QString *, so that I could alloc it freely at my will. Now, this could create some bugs and memory leaks in KStars if not used properly, but every programmer will have the sense to look at my “WARNING:” comments. I couldn’t believe that it actually worked! And I was really amazed to see the whooping 6x increase in speed, with the readData() method taking 6 microseconds per star instead of the earlier 42!!!

    I had some funny idea of how C++ might store the class, but it turned out to be different. I still don’t know how it does that – it looks fuzzier after I implemented this.

    I’m pretty sure that things will break (and segfault) when KStars learns to remember the user-added information links and observation log in the Detail dialog. We will probably fix this in the trunk before the KDE4.1 release, but that means that I’ll have to make some more changes before it safely merges into the branch.

    I’m now trying another suggestion that James made, about loading all star name data into memory, to avoid the disk head seeking between two different files. Now that the fread() that grabs the data from the binary files takes a significant fraction of the load time, this might be an important factor. Earlier, it would’ve simply gotten buffered by the time StarObject::StarObject() would finish. This requires me to add a header to the star name file describing the number of records, so that’s going to change everything right from the data file generating program. I can’t wait to see how much of an efficiency boost I’ll get. It might not be much, though.

    • arunchaganty 7:34 pm on June 5, 2008 Permalink | Log in to Reply

      I’m just wondering, have you tried profiling KStars to see where things are getting bottlenecked?
      <pimp class=”shameless”>
      Anjuta has a great profiler plugin, which gives you a beautiful call graph and stats table among other things…

    • Akarsh Simha 1:45 am on June 6, 2008 Permalink | Log in to Reply

      Well… I’m still far from using an IDE. I don’t know how to use KDevelop / Eclipse / Anjuta. Some day, I must spend time converting EMacs into the powerful IDE that it can be. Something that integrates with my terminal would be heaven.

      Well, you must teach me how to use Anjuta to do such things. I dunno if other IDEs provide such features, so I might want to use Anjuta for these things.

      Thanks for the tip, and happy hacking.

    • Gopala Krishna 4:00 pm on June 8, 2008 Permalink | Log in to Reply

      Looks like very interesting work 🙂 Nice to know 🙂
      Just in case, you might probably also try to use placement new[1] to allocate StarObject.

      Also, would it be possible to load the star data in separate thread so that you can be responsive atleast. Ofcourse this doesn’t increase the loading time, but the stars will get loaded in the background.


    • Akarsh Simha 8:41 pm on June 8, 2008 Permalink | Log in to Reply

      Hmm… I hope the placement new will not “construct” the object. Thanks for that information. I’ll test the speed of this operator and of it doesn’t cause any overhead, I’ll consider modifying the code to use that.

      We were already considering loading stars in a different thread, but maybe that’s for later. Besides, this portion of the implementation is only for the stars that are loaded once, during startup, where loading in a different thread is of no use. However, that, and nonblocking file reading will help immensely for dynamic loading of stars, during runtime, when we need to display fainter stars.

  • Akarsh Simha 5:14 am on May 18, 2008 Permalink
    Tags: GSoC,   

    First steps to acheiving faster loading of stars in KStars 

    So far, this is what I’ve done:
    1. Written a PHP script to load star data from our flat file into a MySQL database. Tested it on our current 125980 star database.
    2. Understand some of the fundamental ideas involved in this project.

    What needs to be done:
    1. Put HTM trixel data also into the MySQL database
    2. Read all of James’ emails describing the whole roadmap to success.

    PS: I wrote this post only for my satisfaction, to give me the feeling of having done something towards GSoC.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc