The poor economy forces everyone to think about the performance of applications on 4 year old hardware. Companies are not replacing computers every two years as they once did. Also, XML can be parsed quite decently on older hardware so I don't see what your point is in relation to Swing's slowness on new hardware. This is solely a Swing problem. Swing is a very poorly designed Java graphics toolkit that creates 10 times more temporary objects than it should. Sun would be well advised to abandon Swing altogether in favour of a Gtk wrapper.
One of Sun's biggest concerns (or any OS vendor for that matter) in shipping shared system libraries is that the API/ABI remain backwards compatible. Just as all applications depend on libc remaining backwards compatible, I imagine many future Solaris applications will depend on GNOME/Gtk. Does GNOME 2/Gtk+ 2.x offer this ABI guarantee? Yes, you could ship many versions of shared libraries each tailored to a specific Gtk version, but you lose the advantage of older applications automatically gaining new features.
The GCC 3.2 C++ compiler is known to have some ABI conformance issues that prevent it from claiming 100% IA32 ABI compability. So the question is: does ICC 7.0 match GCC 3.2's C++ ABI exactly (bug for bug) or does it match the offical IA32 C++ ABI standard (thus rendering it incompatible with GCC 3.2)?
Will NPTL (the scalable and efficient 1:1 thread library replacement + kernel patch) make it in to the 2.6 or 3.0 kernel? Because LinuxThreads don't cut it.
Any other Fresco themes besides Motif?
on
Fresco M1 Released
·
· Score: 1
That Motif look is really quite dated.
Does Fresco offer other themes?
LINE project - run Linux apps under Cygwin/Windows
on
Fun With Wine
·
· Score: 5, Informative
The LINE Project also falls into this ubercool camp.
(Is Sourceforge down? Here's the cached version).
It allows you to run staticly (statically?) linked Linux applications under Windows/Cygwin - including advanced X11 applications. I've tried it and it actually works surprisingly well.
The problem is that LINE emulator is not actively maintained any longer and it broke with the recent Cygwin DLL and/or the upgrade to the recent GCC 3.2.x compiler for Cygwin. When I get a chance I'm going to take a look at it to see if there's an easy fix. If anyone here has a clue as to what the problem might be, please reply to this post. thanks.
When's the last time a customer told you on day 1 exactly what the program should do, how it should work, what features it should have -- and then never changed their minds once?
It sounds like you are not managing your customer's expectations very well. I find that a formal legally binding contract with a customer (complete with a product specification) highlights the importance of advance planning and gets the customer involved with the process at an earlier stage to avoid these last minute 'oversights'. When the customer knows there will be a financial penalty imposed when changing the plan (and breaking the contract) they will make damn sure that it is spec'ed out well to begin with. Projects without plans are doomed to fail or cost several times what they were budgetted for. Advance planning helps both you and your customer in the long run. Nevermind the fact that in the absence of a formal plan your customer never feels like the product is completed.
Nothing beats a well orchestrated and well executed plan - i.e., a written and documented plan. If software specifications are not worth formalizing on paper - it isn't worth creating. You can keep your extreme voodoo. It just formalizes the lazy practices of programmers. 50% to 90% of software projects fail because of embracing fly-by-night "technologies" like this. I thought Extreme Programming was buried for good with the dot bomb implosion.
The term "cluster" has been used in so many contexts that it no longer has any meaning. OpenMOSIX cluster. MPI cluster. Disk cluster. Web server cluster. Is the definition of cluster simply any group of computers either on a LAN or the internet performing vaguely related tasks?
Debugging multithreaded programs in Linux is a complete bitch. As the article mentioned, the core dump only has the stack of the thread that caused the fault. Yes, I know any competant multithreaded programmer uses log files extensively in debugging such code but any additional tool helps. Either of these LinuxThreads replacements would be a major improvement. I just hope the major distros roll in either package in their next release. I bet the 1:1 package would have finer-grained context switching, though. M:N models tend to switch thread contexts only during I/O or blocking system calls. With finer-grained thread switching you tend to expose more bugs in multithreaded code, which is a very good thing. But I suppose even in an M:N model you could always set M=N to acheive similar results.
Have you read the SOAP 1.2specification lately? Nevermind the XML Schema and HTTP 1.1 specifications which SOAP also uses. These specs are far from "simple". SOAP seems to be slowly turning into an XML version of CORBA. XMLRPC, on the other hand, is simple. The Jabber protocol is even simpler yet - no HTTP transport. Something that starts off simple is usually transformed into something quite different after committees of software development firms get a hold of it. It's in their interest to keep the barrier to entry high.
The article was written by AdAge. They hate such PVR devices. It's bad for the advertising business. TiVo allows you to fast forward over ads, although legal pressure prevented TiVo from skipping ads altogether.
The vendors are more conservative than Linus? Hah. Yah. Right.
Yes, right. The big Linux vendors are generally more conservative than Linus. What about changing the VM in the middle of the 2.4 (supposedly stable) kernel series? This is the exact opposite of what "stable" means. Linus admitted he did this so he could get it more thoroughly tested.
Linus was sitting on the fence about the insanely low value of HZ=100 for x86 for years. He ultimately changed it due to pressure from vendors.
All GUI programs - X11, Qt, KDE, GNOME, whatever - are ultimately driven by select() or poll() for their input which is directly influenced by HZ. How can you be more event driven than using these two system calls? This is the definition of event driven computing.
That's so tacky. Watch your cache miss rate go way up from all those unnecessary context switches.
Yes, more 1% more CPU is used on average - who cares? That's what CPUs are for. I would rather have a more responsive desktop running a dozen GUI/music applications rather than my CPU sit idle in a "more efficient state". Bump up HZ from 100 to 500 and see for yourself - it is plainly obvious how much snappier GUI applications are with a higher HZ value. Why do you think RedHat increased the value? Just for kicks?
As for the Netscape programming errors, that's a different matter entirely. Such bugs are easily fixed.
I've always thought of Linus' tree as more of a kernel testing ground - even for the "stable" releases. The big Linux vendors are usually much more conservative about what goes into their trees. But the vendors also react to customer critisism to add very useful features to their kernels - features that Linus often ignores because he doesn't have much interest some particular area. The Linux vendors have to innovate to stay in business, afterall. Like RedHat bumping up HZ to give a much smoother desktop experience. Redhat is also doing pioneering work on highly efficient kernel threads that will likely show up in their kernel before Linus'. RedHat's kernel tree resembles the -ac tree moreso than Linus' tree (gee, might that have to do with the fact that Alan Cox works for RedHat?) Linus' tree is not as relevant as it once was.
Hint: Unique Java Strings were constructed and returned by the JNI native function which was in part based on the loop index as a parameter. Factor that out your asshole.
Hint: "Your" is actually spelled "You're" - short for "You are", jackass.
Transmeta to create "profit morphing" technology to turn an unprofitable business plan into to a profitable one. They will roll out newly patented "micro profit opcodes" to soak up Microsoft money at the molecular level.
I found that JNI (java to C to java) runtime type conversion overhead was so prohibitive that it was much better/faster just to write all the code in java. It depends on how fine-grained your work is. I had to call native functions repeatedly in tight loops. JNI performance sucked at this. Coarse-grained APIs where you do a lot of work in the C native method are much better suited to JNI. Benchmark small samples programs before you invest a lot of time/money in this approach.
Cross platform STL/string/iostream is quite easy, actually: STLPort I don't trust compiler vendors' implementations being threadsafe. Just curious - is GCC's std::string threadsafe across all platforms yet? It used to have some serious problems.
For the record, the use of the -fno-implicit-templates g++ compile flag did not improve Qt C++ compile times at all in my tests. I guess Qt does not use as many templates as I had previously thought.
The void* class encapsulation technique you describe for header files is indeed a good one. Now can someone please convince TrollTech to implement this same compile-time optimization technique with their hundreds of Qt header files?
The simplest way to address this is to avoid using too many different instances.
It's not me that's the problem - the Qt headers themselves are the cause of the problem - they pull in the entire world. You have no choice but to include these files in most circumstances. I'm trying to forward declare classes and include the minimum number of headers wherever possible.
If you're concerned about the compile load of template instantiations, you can always compile with -fno-implicit-templates. Sure it's a bit of a pain, but it can shave a lot off your compile times.
A pain to put it mildly. I am guessing that Qt itself generates hundreds of implicit templates in the most simplest of programs. I would consider using -fno-implicit-templates if I had some sort of script that could generate a.cpp file that declared all the explicit template instantiations. It is impossible to track by hand due to templates instantiating other templates and so on.
I have heard that TAO (ACE CORBA ORB) uses -fno-implicit-templates. I wonder how they track the hundreds of implicit instantiations?
...and it does not look like gcc will support the C++ 'export' functionality for a long long time, unfortunately. It would require a complete redesign of the link system to make it smarter. The C++ compiler would also have to defer code generation for all code referencing the exported templates by value to the link phase because it would not necessarily know the size of classes/structs until link time. I agree this 'export' would be good, but I don't see widespread support for it in the next ten years (from GCC, at least). It changes all the assumptions that C++ compilers have made in the last 10 years.
Slashdot Mirror
The poor economy forces everyone to think about the performance of applications on 4 year old hardware.
Companies are not replacing computers every two years as they once did.
Also, XML can be parsed quite decently on older hardware so I don't see what your point is in relation to Swing's slowness on new hardware. This is solely a Swing problem. Swing is a very poorly designed Java graphics toolkit that creates 10 times more temporary objects than it should. Sun would be well advised to abandon Swing altogether in favour of a Gtk wrapper.
One of Sun's biggest concerns (or any OS vendor for that matter) in shipping shared system libraries is that the API/ABI remain backwards compatible. Just as all applications depend on libc remaining backwards compatible, I imagine many future Solaris applications will depend on GNOME/Gtk. Does GNOME 2/Gtk+ 2.x offer this ABI guarantee?
Yes, you could ship many versions of shared libraries each tailored to a specific Gtk version, but you lose the advantage of older applications automatically gaining new features.
The GCC 3.2 C++ compiler is known to have some ABI conformance issues that prevent it from claiming 100% IA32 ABI compability. So the question is: does ICC 7.0 match GCC 3.2's C++ ABI exactly (bug for bug) or does it match the offical IA32 C++ ABI standard (thus rendering it incompatible with GCC 3.2)?
Will NPTL (the scalable and efficient 1:1 thread library replacement + kernel patch) make it in to the 2.6 or 3.0 kernel? Because LinuxThreads don't cut it.
That Motif look is really quite dated. Does Fresco offer other themes?
The LINE Project also falls into this ubercool camp. (Is Sourceforge down? Here's the cached version). It allows you to run staticly (statically?) linked Linux applications under Windows/Cygwin - including advanced X11 applications. I've tried it and it actually works surprisingly well. The problem is that LINE emulator is not actively maintained any longer and it broke with the recent Cygwin DLL and/or the upgrade to the recent GCC 3.2.x compiler for Cygwin. When I get a chance I'm going to take a look at it to see if there's an easy fix. If anyone here has a clue as to what the problem might be, please reply to this post. thanks.
When's the last time a customer told you on day 1 exactly what the program should do, how it should work, what features it should have -- and then never changed their minds once?
It sounds like you are not managing your customer's expectations very well. I find that a formal legally binding contract with a customer (complete with a product specification) highlights the importance of advance planning and gets the customer involved with the process at an earlier stage to avoid these last minute 'oversights'. When the customer knows there will be a financial penalty imposed when changing the plan (and breaking the contract) they will make damn sure that it is spec'ed out well to begin with. Projects without plans are doomed to fail or cost several times what they were budgetted for. Advance planning helps both you and your customer in the long run. Nevermind the fact that in the absence of a formal plan your customer never feels like the product is completed.
Nothing beats a well orchestrated and well executed plan - i.e., a written and documented plan. If software specifications are not worth formalizing on paper - it isn't worth creating. You can keep your extreme voodoo. It just formalizes the lazy practices of programmers. 50% to 90% of software projects fail because of embracing fly-by-night "technologies" like this. I thought Extreme Programming was buried for good with the dot bomb implosion.
The term "cluster" has been used in so many contexts that it no longer has any meaning. OpenMOSIX cluster. MPI cluster. Disk cluster. Web server cluster. Is the definition of cluster simply any group of computers either on a LAN or the internet performing vaguely related tasks?
This is a fucking ecological disaster waiting to happen. Oil floats and does not degrade as readily in the cold.
Debugging multithreaded programs in Linux is a complete bitch. As the article mentioned, the core dump only has the stack of the thread that caused the fault. Yes, I know any competant multithreaded programmer uses log files extensively in debugging such code but any additional tool helps. Either of these LinuxThreads replacements would be a major improvement. I just hope the major distros roll in either package in their next release.
I bet the 1:1 package would have finer-grained context switching, though. M:N models tend to switch thread contexts only during I/O or blocking system calls. With finer-grained thread switching you tend to expose more bugs in multithreaded code, which is a very good thing. But I suppose even in an M:N model you could always set M=N to acheive similar results.
Have you read the SOAP 1.2 specification lately? Nevermind the XML Schema and HTTP 1.1 specifications which SOAP also uses. These specs are far from "simple". SOAP seems to be slowly turning into an XML version of CORBA. XMLRPC, on the other hand, is simple. The Jabber protocol is even simpler yet - no HTTP transport. Something that starts off simple is usually transformed into something quite different after committees of software development firms get a hold of it. It's in their interest to keep the barrier to entry high.
The article was written by AdAge. They hate such PVR devices. It's bad for the advertising business.
TiVo allows you to fast forward over ads, although legal pressure prevented TiVo from skipping ads altogether.
The vendors are more conservative than Linus? Hah. Yah. Right.
Yes, right. The big Linux vendors are generally more conservative than Linus. What about changing the VM in the middle of the 2.4 (supposedly stable) kernel series? This is the exact opposite of what "stable" means. Linus admitted he did this so he could get it more thoroughly tested.
Linus was sitting on the fence about the insanely low value of HZ=100 for x86 for years. He ultimately changed it due to pressure from vendors.
Nonsense.
All GUI programs - X11, Qt, KDE, GNOME, whatever - are ultimately driven by select() or poll() for their input which is directly influenced by HZ.
How can you be more event driven than using these two system calls? This is the definition of event driven computing.
That's so tacky. Watch your cache miss rate go way up from all those unnecessary context switches.
Yes, more 1% more CPU is used on average - who cares? That's what CPUs are for. I would rather have a more responsive desktop running a dozen GUI/music applications rather than my CPU sit idle in a "more efficient state". Bump up HZ from 100 to 500 and see for yourself - it is plainly obvious how much snappier GUI applications are with a higher HZ value. Why do you think RedHat increased the value? Just for kicks?
As for the Netscape programming errors, that's a different matter entirely. Such bugs are easily fixed.
I've always thought of Linus' tree as more of a kernel testing ground - even for the "stable" releases.
The big Linux vendors are usually much more conservative about what goes into their trees. But the vendors also react to customer critisism to add very useful features to their kernels - features that Linus often ignores because he doesn't have much interest some particular area. The Linux vendors have to innovate to stay in business, afterall. Like RedHat bumping up HZ to give a much smoother desktop experience. Redhat is also doing pioneering work on highly efficient kernel threads that will likely show up in their kernel before Linus'.
RedHat's kernel tree resembles the -ac tree moreso than Linus' tree (gee, might that have to do with the fact that Alan Cox works for RedHat?)
Linus' tree is not as relevant as it once was.
Hint: Unique Java Strings were constructed and returned by the JNI native function which was in part based on the loop index as a parameter. Factor that out your asshole.
Hint: "Your" is actually spelled "You're" - short for "You are", jackass.
Transmeta to create "profit morphing" technology to turn an unprofitable business plan into to a profitable one.
They will roll out newly patented "micro profit opcodes" to soak up Microsoft money at the molecular level.
I found that JNI (java to C to java) runtime type conversion overhead was so prohibitive that it was much better/faster just to write all the code in java. It depends on how fine-grained your work is. I had to call native functions repeatedly in tight loops. JNI performance sucked at this. Coarse-grained APIs where you do a lot of work in the C native method are much better suited to JNI. Benchmark small samples programs before you invest a lot of time/money in this approach.
Cross platform STL/string/iostream is quite easy, actually: STLPort
I don't trust compiler vendors' implementations being threadsafe.
Just curious - is GCC's std::string threadsafe across all platforms yet? It used to have some serious problems.
I'm just sharing this information because it may be useful to others in a similar situation:
GCC 3.2 compiles Qt C++ code 20% to 30% faster on average than GCC 2.95 with the exact same compiler flags.
for example compile times for $QT_DIR/examples/table/statistics/main.cpp:
g++ 2.95: 11.59user 0.15system 0:11.74elapsed
g++ 3.2: 8.32user 0.10system 0:09.04elapsed
every little bit helps.
For the record, the use of the -fno-implicit-templates g++ compile flag did not improve Qt C++ compile times at all in my tests. I guess Qt does not use as many templates as I had previously thought.
The void* class encapsulation technique you describe for header files is indeed a good one.
Now can someone please convince TrollTech to implement this same compile-time optimization technique with their hundreds of Qt header files?
The simplest way to address this is to avoid using too many different instances.
.cpp file that declared all the explicit template instantiations. It is impossible to track by hand due to templates instantiating other templates and so on.
It's not me that's the problem - the Qt headers themselves are the cause of the problem - they pull in the entire world. You have no choice but to include these files in most circumstances. I'm trying to forward declare classes and include the minimum number of headers wherever possible.
If you're concerned about the compile load of template instantiations, you can always compile with -fno-implicit-templates. Sure it's a bit of a pain, but it can shave a lot off your compile times.
A pain to put it mildly. I am guessing that Qt itself generates hundreds of implicit templates in the most simplest of programs. I would consider using -fno-implicit-templates if I had some sort of script that could generate a
I have heard that TAO (ACE CORBA ORB) uses -fno-implicit-templates. I wonder how they track the hundreds of implicit instantiations?
(off topic: why is Slashdot so slow today?)
...and it does not look like gcc will support the C++ 'export' functionality for a long long time, unfortunately. It would require a complete redesign of the link system to make it smarter. The C++ compiler would also have to defer code generation for all code referencing the exported templates by value to the link phase because it would not necessarily know the size of classes/structs until link time. I agree this 'export' would be good, but I don't see widespread support for it in the next ten years (from GCC, at least). It changes all the assumptions that C++ compilers have made in the last 10 years.
Thanks - that's a great idea. I'll take a serious at Qt#. How do the KDE/Qt Java bindings compare?