At 6:31 AM -0800 11/21/03, ben@ekran.org wrote:

I think this would be the only alternative other than tcl/tk myself.

I've been using tcl/tk for many many years now and It can be very very fast. The bottom line is not just that the toolkit is slow, its the damn fact that the PD patcher is a vector drawing. This stuff is just never all that fast in a toolkit (not enough need for them to optimize for it is there?)

How about replacing some of the vector drawing with bitmaps? Pd doesn't do a whole lot that really requires vector drawing - there are no fancy Bezier curves and it doesn't even scale things very well (or at all in certain cases). I'm thinking that the GUI elements like sliders and buttons would be perfect for having bitmaps (gee you ever notice how every single other app uses them for graphic interfaces???). This would allow for even more variation in the look and feel of pd, and all windowing systems have a good deal of optimization for blitting pixmaps to screen and so forth. How capable is tcl/tk for doing something like this? Of course, this is not an answer to the real underlying problems with the Pd GUI, only yet another in a series of patches that sidesteps issues (it would potentially make Pd better looking though!).

Of course I would not want to loose any great features, like dynamic patching, and dyanmic GUIS, I would like to keep all this (possible in SDL/GL?)

Yes. Here's my thoughts on how to do a GL patcher setup:

• objects would be divided into two classes: static and dynamic
• edit mode would do straight GL immediate mode calls
• switching out of edit mode would build a display list of static elements
• dynamic objects, like arrays, would use vertex arrays for best performance
• you could even design all of the UI elements in Maya and save them

as .obj files

It's basically just replacing the tcl/tk calls with GL ones, and keeping track of windows in a context (maybe GLUT is deficient here). Hell, GL is cross-platform enough that foregoing a lib like SDL wouldn't be that big of a deal compared with the entire retooling of the GUI. Also, you've got a pretty capable team of GEM coders that have worked on cross-platform GL for years as a resource.

And for the record (for those not running on all platforms) windows takes the prize for fastest GUI patching. My ol 800 is great for it, In fact so much better I do most patching in (ick) windows. Linux is next, its pretty good, ok for almost everything, but I'd guess about 30% behind windows. OSX is almost useless for large copy-paste operations and GOPs on the g4 733, so slow I've been thinking about a performance environment where you use a windows/linux machine to run the GUI, and the PD DSP on the mac. Lots of extra effort, but perhaps worth it to get some nice gui feel...

Ahh, the joys of throwing pixels right into the framebuffer with next to no management. It gets you 'Snappy'®TM, but little else. Obviously, little consideration was made for relatively antiquated toolkits like tcl/tk when designing Quartz (there wasn't even much consideration of the classic Mac toolkit either, but that's a whole different subject). And thus we have arrived at the current situation where the old stuff looks bad and performs even worse, while the eye candy is pretty well optimized. Exposé seriously rocks on that 733 and cheap Geforce2MX, but drawing dinky little outlines of squares and numbers inside them requires more resources! And here's a truly mindblowing, fucked-up stat: GEM handles decompressing and display of a DV stream more efficiently than Wish drawing two spinning number boxes at the corners of a 720x480 patcher!!

cgc

Enough of me blabing.

B.

Hi all,

MAX is fast (I think) due to a C GUI interface, I don't think anyone here wants to maintain that unless it solves a huge GUI difficiency.

Max is fast because the Quickdraw toolkit it uses is native on Macs. It's not native on Windows (it's an additional layer), thus Max is relatively slow (especially with overlapping objects) there.

Unless there is a specific toolkit made for doing fast vector drawing stuff, I don't see how switching to another toolkit is really going to make a huge difference.

The main problem with tcl/tk is that

• the communication protocol is incapable of handling bulky data, like

bitmaps and point clouds or video frames.

• it has really limited capabilities for multimedia applications, like

transparency etc. As soon as one (like me) wants to move away from the puristic line-drawing patchers, one inevitably has to move to another toolkit. Obviously, all graphical externs - which are really just a few - have to be adapted then.

greetings, Thomas

On Thu, 20 Nov 2003 19:22:14 -0600 chris clepper cgc@humboldtblvd.com wrote:

The main complaint is speed and looks right? Well, how about pulling out all the stops and going full on 3D rendering using OpenGL via GLUT or SDL? That would shut people the hell up about both. You want to see that array update at hundreds of FPS? Not a problem. You want glowing, translucent baubles in your patch? Sure go right ahead.

How about FLTK? It supports OpenGL (if you really want to use it) and is very portable

(works on Windows, Linux, OSX, *BSD, and maybe more), and some of the people I've asked say that it is really fast. I wouldn't know how much is it faster (FLTK is the only GUI lib I've ever used), but it is one of the smallest GUI libs I've seen. Only problem there could be is that it is written in C++, so it is not as fast as it can be, but is much easier to work with.

GLUT and SDL are highly portable, work on most platforms, and handle windowing, drawing, input devices and events. What more could you want? Oh yeah, you have a crappy video card... tough!!

I have really slow machine (Celeron 300MHz) so my life is optimization. It would be nice

not to be forced to use GLUT or OpenGL or whatever, but to have is as an option. I really think FLTK is the solution, but tell me if there is something faster, cause I would really like to get the best out of my machine.

My 2 pesos of input of the discussion.

Good point. I'm using pd for few weeks, so I don't know what is the philosophy of the

programmers. Excuse me if I've said something totally off topic. :o)

Koji ce mi ovo Mandrak U se i u svoje SuSE

On Sat, Nov 22, 2003 at 02:49:16PM -0500, Larry Troxler wrote:

Of the top of my head, I think FLTK would be a great choice. And, probably because it's small, it seemed to me to be easier to learn than the more full-featured GUI systems (not that that should be a major factor, mind you).

It's small enough to be statically linked (<100K!), and the latest cvs version support "themes", the holly grail of sexiness for all those non PD users out there. No wonder why themes are sometimes called "skins"...

Ok, this is what prompted me to post. I thought that this argument finally got put to rest years ago. Ok, I'll bite : why would using C++ for a given application, result in slower run-time performance than the same thing coded in C?

C++ is a kludge, but not always a bad one. Fltk is a good example. I just compiled version 2-cvs, and the examples are very convincing.

-- Marc

On Sun, 23 Nov 2003, Larry Troxler wrote:

Yeah, whatever. I hope you realize that you answered some totally unasked question, that is completely independent of your initial assertion, namely that C++ is slow.

C++ can't be slower then C, because it is a superset of C, so every line of fast code that you can write in C can be written in C++ too.

The fact that it might be easier to write slow programs in C++ than in C might be under discussion, but its a problem of the usage of the programming language and not a problem of the language itself.

my 2 cents ..

Guenter

On Sun, 23 Nov 2003, Jerome Etienne wrote:

nevertheless your argument doesnt hold in its formulation, c++ has more overhead at running time that C, an overhead which reduce its speed. if you write the 20% of code which use 80% of the time in C, and the 80% of your code which use 20% of the time in c++, your code *IS* slower, simply in a negigeable way. if you write all your code in C, your c++ code is as fast as C code, it is pure c, no more c++ even if it is embedded in a .cpp file.

Dude, almost all C++-specific features have been designed with no overhead in mind, beyond the one at compile time.

The most common "runtime overhead" there is is method-lookup, when you use the "virtual" keyword. But still, reproducing the concept of virtual methods in C using function pointers is unlikely to be faster than C++'s built-in support for them.

I'd be extremely curious to know what are those slower parts of C++ that you are talking about. I mean, identify specific features that are slow...

it is a rather pedantic arguement which doesnt intend to start any flame war,

If it really were "pedantic" it would come with more details and more research.

And even though you say you don't want to start any disputes, if your claims are considered very disputable (or even plain wrong) then they are likely to attract rebuttals anyway.

Mathieu Bouchard http://artengine.ca/matju

This is an argument that is utterly ridiculous in this day and age.

I used to have it with the box coders (the guys that wrote emebeded and onboard code) when I worked for a racing car firm many years ago. Then, they had a point. On a modern PC loaded with a busy operating system (linux suffers less here perhaps than windows but there is still a lot going on) I defy ANYONE to detect a difference between what is essentially a few extra pointer de-references.

There is still a noticable difference between GUI's written in cross platform languaues - replete with garbage collection etc. and native applications accessing the graphical API directly but that is because there is a huge amount of translation going on.

yes - C++ is marginally slower than C but unless you are working in a tiny amount of memory on low power processor I doubt it will effect you at all. Even the box coders would win their arguments based on memory usage against speed more often than not

cheers

mark

-----Original Message----- From: pd-list-admin@iem.at [mailto:pd-list-admin@iem.at] On Behalf Of Thomas Grill Sent: 23 November 2003 20:03 To: Jerome Etienne; guenter geiger Cc: pd-list@iem.at Subject: Re: [PD] [offtopic] Re: That C++ is slower thing again

...

nevertheless your argument doesnt hold in its formulation, c++ has more overhead at running time that C, an overhead which reduce its speed. if you write the 20% of code which use 80% of the time in C, and the 80% of your code which use 20% of the time in c++,

your code

...

*IS* slower, simply in a negigeable way.

I would be very interested in an example depicting what you mean (e.g. what kind of overhead etc.). It seems i can't follow your argumentation.

greetings, Thomas

---

PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list

"Strange. "Many years ago" I coded for EPROM as well, and weirdly, it was the corss-compiler vendors that were slow to offer C++, while I was constantly bugging them about it. This is kind of interesting, since you apparently knew embedded systems programmers that didn't want C++. Perhaps they were really hardware engineers who soft of evolved into doing software, and even the concept of using C and not assembler was very experimental in their minds."

Ha Ha - spot on! I learned a lot from working with them though. Very bizarre to meet people who can do mental arithmetic in hex as well. Racing car engineers are a strange bunch at the best of times and all a bit obsessed - you should see the things they did to their casings - drilling away all material they considered excess. Great place to work though.

"Even though stuff like dynamic allocation was irrelevant at the time, I sure could have used the syntactical, organizational help that C++ offers, when doing those 128KB - 512KB ROMs. I think that paradoxically, it was because I was so size and speed conscious, that I was in tune with what the compilers were generating, that I realized that using C++ would have been a great design-time convenience, whithout imposing run-time cost. "

And this was indeed my argument too :-)

"No, I disagree with you here. C++ is not "marginally slower than C;". But that statement is of course quite vague "

I was simply making a concesion to the fact that C++ occasionally has the odd extra pointer de-reference which in some peoples minds that slows it down. You are indeed correct though - by the time its been optimised etc. it makes no difference at all.

"But for most practical purposes, C++ is the same as C as far as run-time performance is concerned. At least, from a theoretical point of view, this _must_ be true - both C and C++ are compiled, statically typed, languages. Maybe some computer science graduate could verify or refute this conjecture."

Not sure how you would go about proving it but my (many) years of experience

bears this out.

cheers

mark

On Mon, Nov 24, 2003 at 10:34:32AM -0500, Jerome Etienne wrote:

if i had to set requirements about the gui, they would be:

• to be as readable as possible
• to be portable among all pd's plateform
• to be extendable (plugins to easily add new gui object without modifying the core)
• to able not to interfere with the realtime of pd
• to work (aka no bug)

ps: this is my last email on the gui subject as it seems to generate too much flame for me.

Your mail are very constructive, and you should not consider other mails on this subject as flames. I hope people will continue to debate about the specific tools required to achieve those spefific goals. -- Marc

Yes it might be nicer for a how-to or a mini how-to on using C++ to make your own external.

I would love that.

Pat

On Sun, Nov 23, 2003 at 05:57:09AM -0500, Larry Troxler wrote:

I don't agree that for an equivalent program, it is slower than C. I was actually optimistic that you would actually provide some examples (I don't mind at all being proved wrong).

Maybe we should move this discussion to the dev list, but it might be interesting to some other people.

Here's a very simple exercise; it doesn't prove that C is necessarely better than C++, but it shows that code compiled with g++ produces bigger executable code than gcc, and that C++ code produces even bigger code than C code compiled with g++.

A simple program in C (hello.c): #include <stdio.h> int main() { puts( "Bonjour le monde!\n" ); }

The same program in C++ (hello.cpp): #include <iostream> int main() { std::cout << "Bonjour le monde!\n"; }

Compilation of the C program with gcc: $ gcc -o hello_c-gcc hello.c

Compilation of the C program with g++: $ g++ -o hello_c-g++ hello.c

Compilation of the C++ program with g++: $ g++ -o hello_cpp hello.cpp

Stripping the binaries: $ strip --strip-unneeded hello_c-gcc hello_c-g++ hello_cpp

Size of the binaries: $ ls -l hello_c-gcc hello_c-g++ hello_cpp -rwxr-xr-x 1 marc marc 2836 nov 23 12:35 hello_c-gcc -rwxr-xr-x 1 marc marc 2940 nov 23 12:35 hello_c-g++ -rwxr-xr-x 1 marc marc 3840 nov 23 12:35 hello_cpp

Size of the machine code (disassembled with objdump): $ objdump -d hello_c-gcc | wc 222 1080 9827 $ objdump -d hello_c-g++ | wc 222 1080 9827 $ objdump -d hello_cpp | wc 268 1393 12053

Once dissambled, binaries of the C code compiled with gcc and g++ are exactly the same, so they probably run at the same speed. The C++ code produces mode machine instructions than the C code, so it probably takes more time to run than its C equivalent.

I'm not an expert, and this exercice is probably bogus.

Googling around, I found this page about C vs C++ performance: http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance.... The analysis basically says that C++ add some overhead that can be reduced.

-- Marc

On Sun, Nov 23, 2003 at 09:45:53PM +0100, Olaf Matthes wrote:

Bigger binaries do _not_ necessarily mean slower execution speeds...

I noticed: the same C example compiled with gcc and g++ produces binaries with different sizes, but disassembling shows they are executing exactly the same instructions. -- Marc

On Sunday 23 November 2003 13:22, Marc Lavallée wrote:

On Sun, Nov 23, 2003 at 05:57:09AM -0500, Larry Troxler wrote:

...

I don't agree that for an equivalent program, it is slower than C. I was actually optimistic that you would actually provide some examples (I don't mind at all being proved wrong).

Maybe we should move this discussion to the dev list, but it might be interesting to some other people.

Here's a very simple exercise; it doesn't prove that C is necessarely better than C++, but it shows that code compiled with g++ produces bigger executable code than gcc, and that C++ code produces even bigger code than C code compiled with g++.

<snip stdout example>

Ok, to nitpick, you're comparing the standard libraries here, and not the performance of the language itself.

Googling around, I found this page about C vs C++ performance: http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance .htm The analysis basically says that C++ add some overhead that can be reduced.

Really? It says that for you? To me, it says that C++ adds some overhead (not quite the right word) which, if you were coding in C, you would have to add anyway.

Larry

On Sunday 23 November 2003 17:29, Marc Lavallée wrote:

On Sun, Nov 23, 2003 at 04:52:14PM -0500, Larry Troxler wrote:

...

Really? It says that for you? To me, it says that C++ adds some overhead (not quite the right word) which, if you were coding in C, you would have to add anyway.

It says that to do the same in C than in C++, it's necessary to add what's missing in C. But it also says that C++ always call destructors even when not necessary, and that there's ways to reduce this overhead.

Argg, lost the url already - sorry. You're interpretation certainly sounds bogus to me though - if you don't define a destructor, then surely one won't be called. Possibly in some implementations, there's overhead if you declare a do-nothing virtual destructor in the base class. But if so, I wonder how the equivalent C implementation would do any better. Either a destructor is needed, or it is not. Yes, granted, if you have a base class like: " class C { int x; public: virtual ~C {} }", then true, the base destructor will always be called even rhough it is empty (I suppose this depends on how smart the compiler is). But if you're using this class polymorphically, I don't really see how you could get better perforrmance overall by doing the equivalent thing in C (probably using function pointers). What am I missing here?

C++ can certainly be as effective, fast, etc, than C, if programs are carefully coded. We're not disagreeing. Peace and joy to C++ coders of the universe.

And likewise, may all the C coders enjoy profound joy and peace.

Larry

On Sunday 23 November 2003 22:02, Marc Lavallée wrote:

On Sun, Nov 23, 2003 at 07:44:55PM -0500, Larry Troxler wrote:

...

Either a destructor is needed, or it is not.

Sometimes it is not necessary to call a destructor each time an object is deleted; this is where an inline destructor can supposedly help (I'm not a C++ programmer, and never read a C++ book). I found this paper on C++ performance issues: http://www.cs.wustl.edu/~schmidt/PDF/perf4.pdf Inlining destructors seems tricky and dangerous.

That url is timeing out for me. In any case, we are evidently talking past eachother.

...

What am I missing here?

Nothing. I now have the impression that well written and optimised C++ code can be as fast as C, although there must a lot of poorly written C++ code used to produce bloated softwares, because object oriented programming is popular for big projects.

I think you're confusing cause and effect here, and also perhaps confusing object oriented programming with the choice of programming language.

Certainly, large projects are more likely to be poorly written and bloated.

And likewise, C++ is probably more likely too be used for larger projects.

And remember, whether someone is using object-oriented design has little to do with what programming language they are using - it is very easy to do object oriented programming in C. C++ really only adds a bit of syntactic niceties to help things out.

Larry

On Sat, Nov 22, 2003 at 02:37:31PM +0100, Frank Barknecht wrote:

I'm also thinking of another approach: The jMax folks are in the process of porting the GUI part to wxPython, and they already made some interesting progress in this area. How about joining forces with them and try to reuse the relevant parts of pyMax as GUI for Pd?

I thought the same. One advantage of a common gui is that some users might stop complaining about PD's gui and choose PD or pyMax for their intrinsic qualities, not their look. Of course, the vast majority will still evaluate the quality of PD with criterias like the number of visible and colorful icons, the font antialisiang, the dropshadow's transparency, the very reassuring segmented patch cords, and the almighty splash screen...

What is required to try the CVS version of pymax? "testPyMaxClient.py" wants a python module named "ircam.fts.client". -- Marc