How these to c++ web service framworks compare in performance namely staff-wsf and witty?
I did not perform bench marking, But can get idea from following
Although implemented in C++, Wt’s main focus or novelty is not its
performance, but its focus on developing maintainable applications and
its extensive library of built-in widgets. But because it is popular
and widely used in embedded systems, you will find that performance
and foot-print has been optimized too, by virtue of a no-nonsense API,
thoughtful architecture, and C++ …
given in webtoolkit tutorial
Related
Can the v8's code generating backend be used in a third party programming language, in a way similar to LLVM is used? Is it "general enough" for that, can you even separate the backend from the v8?
I found this, but it does not help to answer my question:
https://github.com/v8/v8/wiki/TurboFan
V8 developer here. No, V8's compiler is not designed to be used as a stand-alone compiler. It is closely intertwined with the rest of the V8 runtime system, and very much tailored towards JavaScript.
Of course, many of the concepts in Turbofan are applicable to other compilers/languages too. If you have a couple of person-years of engineering time available, you could totally extend (or fork and adapt) it to support one or more other languages. But that would be a lot of work.
I need to create a desktop-application that has to handle some animations and a bunch of logic.
I thought about creating it with node-webkit which I never have used before.
Is anybody here who already wrote some desktop-apps and experienced the performance compared to something coded in c++?
So there's 2 parts to this question:
1) Speed comparison of Javascript executing under V8 (node-webkit), vs C++ compiled into native code
On most computationally-intensive tasks, you'd expect a 3x to 10x slowdown in execution (depending on the benchmark). An example can be found at http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=gpp ; if you want more examples search for other v8 benchmarks.
2) Speed comparison of browser-based UI toolkits (based on the DOM and CSS, and perhaps WebGL) as rendered with Chrome's engine, vs whatever desktop UI toolkit (for example, Qt, WxWidgets, etc) and/or 3D-rendering API (DirectX, OpenGL, or various different wrappers around them) that you'd be using with C++.
This unfortunately is rather difficult to benchmark, as there are tons of different UI toolkits out there, each with differing performance characteristics for each type of animation / widget that you might use (depending on how they were implemented). If you're 3D rendering and want to compare Javascript+WebGL on Chrome to C++ with DirectX, see https://www.scirra.com/blog/58/html5-2d-gaming-performance-analysis for an example benchmark (their figures indicate a ~5x slowdown); if you want more examples search for performance benchmarks comparing WebGL to OpenGL and DirectX.
Generally speaking, well-implemented C++ should execute faster than Javascript running under node-webkit, simply because there's fewer layers of abstraction away from the hardware. That said, unless you're building an exceptionally computationally intensive application, the difference will likely not be visible on a modern desktop, and you should be focusing more on ease-of-development rather than performance.
Using node-webkit also gives you advantage of the countless UI libraries built for browsers, which will likely accelerate your development time, especially if you already have experience in frontend web app development. There are also advantages in terms of portability - unless you use a cross-platform UI tookit like Qt with C++, you will need platform-specific UI code, whereas with node-webkit you get cross-platform portability for free.
I am looking for a programming language/platform which is suited for handling around 1 to 2 GB of data, and can run signal processing algorithms fast enough across platforms (including modern mobile platforms). Did someone come across suitable solutions?. Please share your research and experience on cross-platform development.
My current research effort is complicated, owing to
the increased deployment of powerful [mobile] platforms,
the backing of Java through the popularity of Android (currently the #1 tag on stackoverflow)
I had mixed experience with C# and Mono (It is fast, but cross-platform compatibility can take some additional effort).
I am not looking for High performance computing(HPC), but into developing code with a data and computing-intensive background that performs well with as little effort as possible. A case study scenario for this would be Python code which is adapted to the Cython compiler.
I am not looking for UI-centric projects with solutions such as Phonegap and Adobe Air, but I know little about its performance.
Links:
Cross-Platform Development of High Performance Applications
Using Generic Programming
Native Client: A Sandbox for Portable, Untrusted x86 Native Code
You can perhaps start having a look at Droidcluster
Is there, by chance, an emerging Haskell UI framework for Windows?
I recently took up looking over the language, and from what I see, it would be for great little "one-off" applications (elaborate scripts).
However, without a good UI framework I can't see it getting in under the smoke and mirrors of the more obvious contenders.
I've read that there are many frameworks, but none are full-featured.
I'm just wondering if this is something that's on the rise, or is it simply too difficult to get enough developers going in the same direction with one?
The two main frameworks are wxHaskell and Gtk2Hs. Both of these have been used for real work. From what I know my preference would be Gtk2Hs because it handles resources properly (i.e. uses the GC). wxHaskell requires the programmer to release widgets once they are no longer required, so you can get all the classic memory leaks and stale pointer screws with it.
The problem with both is that everything is in the IO monad. This reflects the fact that they are comparatively thin wrappers around existing GUI libraries for imperative languages. Of course this means you are no worse off than you would be writing a GUI in an imperative language, but you are hardly much better off either.
There are some interesting experimental libraries to be found on Hackage, including Grapefruit and Conal Elliott's "Tangible Values" ideas in GuiTV. Both of these try for a more declarative approach.
(Disclaimer: I am the wxHaskell maintainer)
Both wxHaskell and Gtk2Hs are more or less complete. That's to say, both wrap a great deal of the functionality provided by their underlying libraries. They also both, as mentioned earlier, require a rather 'imperative' style of programming in the IO monad.
There have been many discussions on the relative merits of each. I would say that wxHaskell is the easier of the two to get working, especially on Windows, as it can be installed via cabal (see http://www.haskell.org/haskellwiki/WxHaskell/Install#On_Windows)
The FRP frameworks (Grapefruit and others) provide a more 'functional' style of programming, at the cost of having much reduced widget coverage. I have the feeling that this is still an open research area, and not really ready for 'prime time'.
In practice, I've never had resource management issues with wxHaskell, although I agree that it's possible, and is an area handled better by Gtk2Hs, which uses reference counting in the underlying library.
For completeness, I should also mention that a Qt binding (QtHaskell?) also exists - it is relatively young, but apparently reasonably complete.
I rather feel that the Haskell community, small as it is, would do well to fix on one GUI framework, but accept the difficulty of this (e.g. licensing, support for all OS platforms etc.).
Also you can use wxWidgets (i mean C++ library) with Haskell. Here is an example: https://bitbucket.org/afiskon/hs-a-star-gui/src Such approach has some advantages over wxHaskell: 1. You can use UI generators (Code::Blocks, wxFormBuilder) 2. Your application takes less disk space 3. You can use all features of wxWidgets.
It should also be noted, that last version of wxHaskell uses wxWidgets 2.9, which probably will never be ported to Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=16;bug=613431
Ok, this is an interesting question to ask because everyone has a say in it.
What is your favorite library to program in for GUI's and the language that you program it in. Give a short reason why. (ex. Gtk, Qt, Windows, etc..) Just an FYI, this includes any scripting language that you program a GUI in Python, Perl etc...
Frankly I've always done Gtk in C, but I'm starting to warm up to Qt in C++ with the new KDE. I've never been a big fan of Windows programming.
ChrisW. stated that I did not give a reason for Gtk/Qt so here goes. I started with Gtk because when I started programming GUI's I was working in Linux and there was more Gtk information available. Started utilizing Qt when I started working more in KDE but really the move to Qt was based on trying to move to C++ and learn more languages. I've never been a fan of basic Windows programming, but I do enjoy a little DirectX now and then :P
Recently I had the opportunity to work with both wxWindows and QT, while some time ago I wrote some small programs using FLTK and Gtk. My conclusion is that widget libraries tend to be very similar; each one has its strenghts and its quirks.
Instead of advocating a specific library, then, I would like to advocate the use of high level languages in GUI programming: the development cycle is way faster and GUI programs are rarely CPU bound, so the performance hit is rarely a problem.
If a GUI program has to perform some intense computations, just develop a core library in C or C++, but keep the interface in Python or whatever other interpreted language.
People like to bash Swing for being old, slow and ugly, but it's just not true. Swing is mature, is faster than ever on Java SE 6/10, looks decent enough, and is tolerable to program. Above all, I've found Java + Swing to be the most trouble-free cross-platform combination. It also works remarkably seamlessly with Jython (Python on JVM).
SWT could also be an option, but so far I've been happy with Swing.
I realise you're focusing on application GUIs but if you want a quick, powerful and fun way to visualize anything on your computer, you can't go past Processing
From the site:
Processing is an open source
programming language and environment
for people who want to program images,
animation, and interactions. It is
used by students, artists, designers,
researchers, and hobbyists for
learning, prototyping, and production.
It is created to teach fundamentals of
computer programming within a visual
context and to serve as a software
sketchbook and professional production
tool. Processing is an alternative to
proprietary software tools in the same
domain.
WPF in particular, and XAML in all its reincarnations (WPF, Silverlight, Moonlight).
C# on top of .Net 3.5/Mono: $0
Visual Studio Express/MonoDevelop: $0
Being able to tell the designer "make my program pretty" and continue coding features: priceless.
I liked writing to video memory under DOS: for an animated game (i.e. an Asteroids clone), that was as fast (performant) as I knew how to do it (certainly faster that using the BIOS API).
This is really a somewhat subjective question, so there is no best or correct answer to it. The following is based on my (limited) experience:
I personally like wxWidgets with PLT Scheme for writing simple but flexible GUIs. There are much more advanced toolkits, but I usually do not need their features. wxWidgets is flexible and the Scheme interface follows Scheme traditions of being powerful with a relatively simple structure. I like the fact that wxWidgets is portable, and yet tries not to actually draw its own widgets, but can use native or common toolkits of the environment it is used under. It is written in C++ but I never used its C++ interface.
That is not to say that in my opinion Scheme will generally be the optimal language to write your application in. In fact there are many kinds of applications I would not write in Scheme, even though I like the language. But regarding the GUI programming part, that is my favourite because of its straight-forwardness, and the way that a functional language like Scheme goes well with declarative-style GUI programming.
Of course you will not have the same level of control when using that as when having your program involved in every stage of the window construction and input reaction, by using an event loop (such as with Win32API or Xt/Intrinsics). But that is not always convenient and often unnecessary, and seems to become decreasingly common.
Note: The wxWindows toolkit was renamed wxWidgets, but my installation of a rather recent version of PLT Scheme still comes with the older wxWindows. I am not sure whether there is an updated package of wxWidgets available or if it is going to be included in a future version of PLT Scheme.
Qt4 without question for me. Now that it has an LGPL license it makes sense for all kinds of applications that previously weren't possible. Additionally, it changes C++ in ways that dramatically improve the experience of using the language. (Things like a foreach and forever loop, atomic operations on integers, and memory management)
Gtk and is the primary window-drawing graphical subsystem I have experience working with (and is therefore my favorite XD).
As far as general graphics subsystems go, however, OpenGL (typically in combination with GLUT) has been an easy and productive ride for me. Regrettably I have little DirectX experience to compare to, though :S
For writing souped-up versions of standard Windows components, I loved Borland's VCL, and am very pleased with .NET.