faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Native code FUD
by Matthias Ettrich on Sunday 08/Aug/2004, @17:46
|
Performance and memory consumption is not only a matter of the instruction set and how the runtime system executes it, but depends largely on data structures, the object model itself and on what kind of APIs and programming style the programming languages in use imply or encourage. This is not about static versus dynamic compiler optimizations techniques or the benefits of having another layer on top of the CPU's instruction set. This is about comparing how developers today write native applications on both Microsoft Windows and Linux, and how they write Java or .NET applications. So I could have said "C/C++" instead of "native code".
C++ does not necessarily mean speed, even if the language makes it harder to write slow programs. Just imagine a C++ programming style where all functions and inheritances are virtual, all classes inherit from a common base class that does central object registration, all objects are always allocated on the heap and every single pointer or array access is checked beforehand. If you then create an API that encourages the creation of massive amounts of small objects that call into each other through listener interfaces, and requires dynamically checked type casts to narrow objects, then you would not end up with the speed we see with Qt and KDE today, and for that matter any other well written C/C++ software.
What makes C++ code so fast is not only that the CPU understands the assembly directly, at least not exclusively. Most of its speed stems from the powerful language. It's good when a JIT compiler can optimize function calls, but it's better if you don't even need a function call. It's good when an allocator is really fast when allocating small objects, but it's better if you don't have to allocate anything at all. And so on.
This is why C++ is here to stay, on both Microsoft Windows and on Linux. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Native code FUD
by Richard Dale on Sunday 08/Aug/2004, @21:33
|
"Just imagine a C++ programming style where all functions and inheritances are virtual, all classes inherit from a common base class that does central object registration, all objects are always allocated on the heap and every single pointer or array access is checked beforehand"
Well I've used Objective-C/OpenStep (ie Apple Cocoa) a lot. It was easily fast enough 10 years ago, and it certainly is now. In Objective-C every method is effectively virtual, including the equivalent of 'static' methods. All classes inherit from NSObject, and the NSArray class doesn't allow you to drop off the end and crash. All Objective-C instances are allocated on the heap.
"If you then create an API that encourages the creation of massive amounts of small objects that call into each other through listener interfaces, and requires dynamically checked type casts to narrow objects, then you would not end up with the speed we see with Qt and KDE today"
This is where Objective-C diverges from the java approach. In Cocoa there are many fewer instances required to do something, and the inheritance heirachies are flatter. You can use delegation or categories (ie dynamically adding/changing methods to running instances) where you would need to subclass in java. Listener interfaces are a design disaster as they ignore the dynamic reflection possibilities in java. Qt takes a static language and makes it more dynamic via the moc and signals/slots, while Swing java takes a dynamic language and implements a clunky api based entirely on static typing.
I'm fussy and I don't like a lot of software, but I really think Qt/KDE is the best application framework since NeXTStep (especially with the KDE 3.3 ruby bindings).
|
[
Reply To This | View ]
|
Re: Native code FUD
by Tim Jansen on Monday 09/Aug/2004, @00:38
|
"All Objective-C instances are allocated on the heap."
BTW this is not strictly necessary in Objective-C, and neither in Java or C#. They could use stack-allocation for many short-lived objects. It would require more/better analysis of the code though, to determine for which objects it is possible.
(Similarly all the other performance problems listed by Matthias can be solved by more intelligent compilers - we're just not there yet)
|
[
Reply To This | View ]
|
Re: Native code FUD
by Richard Dale on Monday 09/Aug/2004, @00:50
|
"BTW this is not strictly necessary in Objective-C,"
It isn't possible in Objective-C - you create an instance by messaging a class object, and then sending an initialization message to the new instance. Only string literals of the form @"mystring" can be statically allocated
Instances are allocated in 'autorelease pools'. You can create you're own autorelease pools, and you would do that if you have a lot of short lived objects.
C# already allows to allocate short lived objects on the stack.
|
[
Reply To This | View ]
|
Re: Native code FUD
by Rayiner Hashem on Monday 09/Aug/2004, @08:09
|
Lot's of compilers are already at that point. Stalin, CMUCL, d2c, Bigoo, etc, all do these sorts of optimizations. It's just something that hasn't come to C# and Java compilers yet (and will never come to C/C++ compilers, because of their semantics).
|
[
Reply To This | View ]
|
|
Re: Native code FUD
by lypanov on Thursday 12/Aug/2004, @07:53
|
umm i very much doubt this...
c is here to stay. but c++ i doubt.
dynamic optimisation is not possible
without a jitting mechanism and a
language that doesn't overspecify.
good jit compiler do inlines of
the methods based on execution
profiling. the best c++ compiler
can only guess. and slowly at
that. sure with profile feedback
it can do much better. but still
nowhere near perfect.
also its because of the
overspecification of interfaces
in c++ that we don't see automatic
removal of virtual keywords based
on profiling / path analysis
same goes for the need to
explicitly use zone allocators
rather than have the runtime
figure it out at er.. yeah
runtime :)
Alex
|
[
Reply To This | View ]
|
Re: Native code FUD
by Richard Dale on Thursday 12/Aug/2004, @17:06
|
"c is here to stay. but c++ i doubt.
dynamic optimisation is not possible
without a jitting mechanism and a
language that doesn't overspecify.
good jit compiler do inlines of
the methods based on execution
profiling. the best c++ compiler
can only guess. and slowly at
that. sure with profile feedback
it can do much better. but still
nowhere near perfect."
I think you've lost the plot here. Which is most important - a gui framework based on a more expressive dynamic language such as ruby, or a statically compiled language which is a bit faster at runtime because of jit compilation? And should a toolkit be written in the same language that end users will program it in?
Which gui toolkits are so awesome that they just need a bit of jit'ing to make them perfect? MFC, Swing, WinForms, Delphi, Taligent, WxWidgets, GTK+, GTK#. To me they're all just a bunch of dogs compared with Cocoa or Qt/KDE.
C# is a complex systems programming language (as a systems programmer I find it fun), but it is most certainly not a RAD language that everyday programmers will feel comfortable with. Ruby doesn't have jit'ing, but does anyone care, it's just much easier to get stuff done with ruby (or python) than C# or java or C++. Why can't we talk about the programming language usability vs. efficiency tradeoff? The Qt toolkit will never be as popular as it should be while it is C++ specific - a jit'ed C# version wouldn't solve that problem at all.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
