Dear Norman, Thank you for spending much time on answering my problems.
Maybe I should consider the time cost of using DoPE on Genode, because my work should be finished before February, 2015.
Then my answers are given below:
* Which version of Genode are you using?
We're using version 13.02.
* Are you using Qt4 or Qt5? (If you are still using Qt4, I would recommend you to switch to Qt5)
Qt 4.7.4 was using. I tried to replace Qt4 with Qt5, but failed. The reason maybe the ways I used are wrong because of my lack of knowledge about that. So, could you give me some tips or tutorial about Qt4's updating to Qt5? Sorry to bother you, Norman.
* Which Genode base platform are you using?
Fiasco.OC, because our prototype and research are all based on microkernel architecture till now.
* Have you tried to run your GUI application on base-linux? If yes, have you compared its performance to the same application compiled for native Linux w/o Genode?
I would like to carry some experiments before giving an answer to you.
* On base-linux, you could use normal Linux profiling tools such as oprofile to find out where the CPU time goes.
It's good way, but I should consider how to make sure that Fiasco.OC-based Genode's performance is improved.
* Can you make a Git branch with your application publicly available (e.g., on Github) so that I could give it a try? By being able to reproduce the problem, I could help you much better with investigating the issue.
I'm so sorry for being not able to do this, because parts of source code of our prototype could not be public. I really appreciate you help, and if some day our team leader agree to open source code to the public, I would like to invite you to our team.
Thank you for all your assistance.
Yours Sincerely,
Shuo Wang University of Chinese Academy of Sciences.
------------------ Original ------------------ From: "norman.feske";<norman.feske@...1...>; Date: Thu, Mar 27, 2014 09:45 PM To: "genode-main"genode-main@lists.sourceforge.net; Subject: Re: Some questions about performance optimization related to GUIframework on Genode
Hello Shuo Wang,
thank you for your interest in Genode! Please excuse the delayed response. I was offline for a few days.
The most serious problem I meet now is that system is very slow when running applications we made before, so I doubt whether this is related to GUI framework. I plan to transplant DoPE to Genode, in order to make a comparation between DoPE and Qt. But I am worried about reasonability about my design of experiments, so I need help from the developers.
DOpE is definitely faster than Qt as it is even usable on low-performance devices such as FPGA softcores, e.g., the Milkymist SoC [1]. So for those kind of special-purpose appliances, DOpE still seems to be attractive. However, in the context of the Genode OS framework, I would advise against using DOpE. I would rather spend the energy on investigating the performance problems you observe with Qt.
The reason for my stance is that DOpE lacks a lot of features that are universally expected from modern GUI toolkits (e.g., support for theming, international characters, common widget types like menus). Furthermore, it has been practically unmaintained for several years now. If you still like to go forward with experimenting with DOpE on Genode, I can possibly assist you. I already ported DOpE to an early version of Genode in 2008 and could possibly revive the port. However, I am not committed to actively maintain or even improve it.
As I said above, I would rather try to find out why Qt performs so badly for you. This raises the following questions:
* Which version of Genode are you using?
* Are you using Qt4 or Qt5? (If you are still using Qt4, I would recommend you to switch to Qt5)
* Which Genode base platform are you using?
* Have you tried to run your GUI application on base-linux? If yes, have you compared its performance to the same application compiled for native Linux w/o Genode?
* On base-linux, you could use normal Linux profiling tools such as oprofile to find out where the CPU time goes.
* Can you make a Git branch with your application publicly available (e.g., on Github) so that I could give it a try? By being able to reproduce the problem, I could help you much better with investigating the issue.
Best regards Norman
Hello Shuo Wang,
Maybe I should consider the time cost of using DoPE on Genode, because my work should be finished before February, 2015.
I have just dusted off the Genode version of DOpE and cleaned it up a bit. If you like to give it a try, you can find it here:
https://github.com/nfeske/dope
- Which version of Genode are you using?
We're using version 13.02.
- Are you using Qt4 or Qt5? (If you are still using Qt4, I would
recommend you to switch to Qt5)
Qt 4.7.4 was using. I tried to replace Qt4 with Qt5, but failed. The reason maybe the ways I used are wrong because of my lack of knowledge about that. So, could you give me some tips or tutorial about Qt4's updating to Qt5? Sorry to bother you, Norman.
Qt5 is supported since version 13.08. To try it out, you might consider updating to a newer version of Genode. In Genode 14.02, you find plenty of examples at 'libports/run/qt5_*.run'. Using Qt5 is actually not very different from using Qt4. You can find more information about switching to Qt5 at the following link:
http://www.genode.org/documentation/release-notes/13.08#Qt5_available_on_all...
- Which Genode base platform are you using?
Fiasco.OC, because our prototype and research are all based on microkernel architecture till now.
Are you using Fiasco.OC on the ARM, x86_32, or x86_64 architecture? If ARM, which SoC is used?
- Have you tried to run your GUI application on base-linux? If yes, have you compared its performance to the same application compiled for
native Linux w/o Genode?
I would like to carry some experiments before giving an answer to you.
- On base-linux, you could use normal Linux profiling tools such as
oprofile to find out where the CPU time goes.
It's good way, but I should consider how to make sure that Fiasco.OC-based Genode's performance is improved.
Trying out the same scenario on different kernels is a good way to see whether the performance problem is related to the specific kernel or somewhere in the generic code (which is by large the majority of the code). If you can reproduce the performance problem on base-linux, you can debug it there (using Linux' profiling and tracing tools). Once you solved the problem on Linux, it will most likely be fixed on Fiasco.OC as well. On the other hand, if you observe the performance on base-linux to be fine, the problem lies somewhere in the Fiasco.OC-specific code.
By testing your program on additional kernels (e.g., base-hw, base-nova), different kernel configurations, or CPU architectures, you might be able to further cross-correlate between the varying factors of those experiments. With Genode, it is quite easy to conduct such experiments, which might give you additional hints to encircle the problem.
I'm so sorry for being not able to do this, because parts of source code of our prototype could not be public. I really appreciate you help, and if some day our team leader agree to open source code to the public, I would like to invite you to our team.
:-)
How about investigating the performance problem using the examples in Genode's source tree then? Do you experience the same poor performance for those? For example, how does 'make run/textedit' perform on your platform?
Best regards Norman
-
Kloisiie -
Norman Feske