"And you're claiming that it's not, simply because you like it. I'd say that my criteria are at *least* as valid."
That's not true. What I said was the microbenchmark you mentioned doesn't bear any significance for the many real-life projects' performance. Dismissing the language as slow just because some implementation of it performs poorly on some microbenchmark is valid? Be it Java or any other language. Take a look at the SEDA link I gave you. Or just google for 'SEDA' and 'Haboob'.
"Except that isn't usually the case. It simply isn't reasonable for a human to know all the timings for the various chips they're targeting and write perfect code any more, and even if they could, CPUs are too complex, and compilers too good. Rasterman, who writes a good deal of low-level code to do graphics stuff very quickly (and hence knows x86 assembly better than most), recently wrote how he spent a huge amount of time rewriting a C library in x86 assembly, and got no real speedups in his hand-tweaked one. Even tiny embedded systems are leaving assembly in droves, because compilers are *good* these days. " I thought you wanted to trade features and convenience for speed. Or is it some features and convenience?
"Your statement is simply nonsensical. Feel free to show Slashdot a place in the Java spec where it says "implemented JVMs shall utilize the pthreads library".
I don't think I was talking about the language specs at that point. Rather implementations.
"Fine, let me clarify it. Scalability, the sort of way Sun is selling is (which translates to "you can add more hardware to get some reasonable amount of performance increase" is totally fucking irrelevant to almost every software package in the world. Yes, perhaps erlang is useful for 80 node setups (I'm not saying it is, just that I don't care enough to try to find out). I (and the overwhelming majority of other people) are not working with 80 node setups, and the interesting factor is whether performance sucks on a single node system."
That's not the kind of scalability I was talking about. I was talking about application scalability. And it certainly is possible to write Java progs which scale better than equivalent C programs. On the same hardware. It has been done. The difference is the kinds of applications. Labeling a language "just slow" for any kinds of applications make a lot of sense?
"Have you ever actually *seen* or *used* fputs()? I'd love to hear what "buffer overflow" you're thinking of, because I don't think you have the faintest idea what you're talking about."
I admit, I was thinking of gets(), and wrote 'fputs'. And no, I've never used either (and never will). There are great libraries for dynamically-allocated strings in C, but it would have been better if these were part of C in the first place (the standard).
"It doesn't add keywords -- it *is* extending the evironment that I'm writing in, however. This is also completely irrelevant, because the semantics don't matter -- only whether the missing functionality is present. Which it is."
This is relevant to our discussion, since you wrote speed is almost everything in a language. While I wrote that speed is secondary to other goals. If you trade those goals in a language design for speed, you would very unlikely find fixing these issues in the future easy. While performance issues can be dealt in the implementation far easier than breaking language standards. We both agree JVMs have become better performance-wise.
"[laughing my ass off] Okay, "orders of magnitude", eh? Before making a damn fool of yourself any more, run out and find yourself a benchmark where your C compiler produces code that is a *hundred* times slower than your hand-coded assembly. This should be entertaining. Find me...oh, a matrix multiplication benchmark, say, where assembly is 100 times faster than a C compiler can generate. I'd love to see what flaws *in the C language* you can find that would ever make C 100 times slower than assembly. The flaws I pointed out in Java were *in the language itself*."
Maybe not orders, maybe just one order. This is pure speculation anyway. The point is, these are all trade offs, Java and Erlang are higher-level languages than both C and assembly, and raw speed is definitely a trade-off for convenience, portability, etc., etc.
"Look, I don't have a problem with Erlang as a language. There are, I'm sure, lots of good applications for it."
You said it was one of the slowest languages, because some microbenchmark says so.
"The problem is that I'm looking for a language that focuses on speed, which there is a decided paucity of recently. Despite all the compiler improvements and optimization techniques developed, the fastest choice around is generally *still* C and C++, the first of which is *decades* old, and the second of which has a lot of old baggage."
Nah, your best bet are zeros and ones.
"I want modern functionality with even *better* speed. That's all. Erlang is not what I'm looking for, but that doesn't mean it's not good for some people."
Great, we both agree on this.
"I wouldn't call Java's support bolted on. It's language level as well."
Ah, ah, ah, it still depends on pthreads. pthreads isn't native.
"That's nice (I was quite impressed with CML, which has similar capabilities), but it doesn't really help me unless I'm dead set on writing a program with thousands of preemptive threads."
Non-preemtive threads.
"Your link (well, what should have been a link) is dead. And scalability is mostly irrelevant."
Righhhht, scalability is mostly irrelevant. Not for everybody.
"Saying "Java is slow" has some quite obviously understood implications by both you and me, so don't play stupid. That doesn't win any arguments. Java may well be faster at...oh, I don't know, closing. For the vast majority of cases, if I want to sit down and write something that a user interacts with, a Java program is much more sluggish than a C++ program. This is not something that I'm the only one trumpeting -- anyone that's used Java has run into this. And don't give me the "you're using a slow JVM" bullshit that Java advocates love to spout -- I've been developing exclusively with IBM's JDK. There isn't a faster JVM out there for Linux."
Your problem seems to be Swing, not Java. Furthermore, JVM isn't the only way to implement Java.
I still think your complaint should be about Swing, and not Java.
"As for your claim that they can always be dealt with later in the implementation, I have an excellent counterexample -- the JVMs that you're so staunchly supporting. When Java was released, it ran like a dog. Sun promised that better compilers would improve things. Optimization got a little better. JITs helped. And you know what? Java is, indeed, faster than it once was. It is *still* sluggish, however. And it's not going to improve much more. And the *language* has limited this -- the lack of typed container objects, the required bounds checking, the almost-impossible-to-avoid reliance on heavy heap-based dynamic allocation of memory. No implementation can fix this."
So if they've improved performance over the years, it can't be done anymore for some imaginative reason? Garbage.
"Java as a *language* is terminally limited to never run faster than at a certain clip. Now, it's still quite useful for many things, but not for performance-critical stuff, which happens to matter to me."
Right, like some end-user GUI stuff. Performance critical indeed.
"And I won't agree with you there."
'fputs' isn't broken? Can you say buffer overflow by design?
"Really, really easy. Look at glib for C or any one of many, many good string classes for C++."
Wrong. This isn't language extention. This is a library written by someone.
"How do you think someone is going to "prematurely optimize" a language spec? Do you want to wait until a language is widely used and *then* run out and make lots of changes to it? Heck, that isn't even relevant."
Reread my last response.
"And one day, *you* will realize that having a speedy language does not entail *losing* other functionality."
C is definitely slower than assembly on micro-benchmarks, and even otherwise. Orders of magnitudes slower. Your point?
So you're one of those from the "broad generalization" camps. Just because a language is slow at particular micro-benchmarks such as the link you provided, doesn't mean it's "the slowest major language out there". Statements like these are broad generalizations, religious nonsense.
Erlang's threading doesn't depend on an OS library - pthreads. An Erlang thread looks like a process to an Erlang programmer - which makes thread programming look like multi-process programming with inter-process-communication - easy. Java doesn't even come close. In Erlang, concurrency is a language _feature_. In Java it's an alien invader _bolt-on_ with all the resulting inconveniences and OS-dependence. Same goes for Ada - concurrency is a language feature, not a bolt-on. Also an Erlang process is said to be orders of magnitutde lighter than Java thread. Read the site, would you. Erlang applications scale well with thousands of threads without the overhead of programming pthreads. Erlang was designed such that each concurrent process in a given problem can be mapped to a concurrent process in Erlang language. It's a feature, not a bolt-on.
"Modern *fast* languages are almost nonexistent" - another broad generalization. How fast and how fast for solving which problems? Java has been used to write a scalable application framework which has been used to write a web server which scales better than an equivalent C-based server. See http://www.cs.berkeley.edu/~mdw/proj/seda/. Your broad generalization that Java is slow in any case, any kind of application, anywhere (just because you have this idea in your head), falls flat on its face. "Profile, don't speculate".
I am not a big Java fan, but your broad generalizations cannot be further from the truth. The rest, are even more ridiculous.
"But those can be added later" - you have it backwards. Don't confuse language with a langugage implementation. If you sacrificed language features to speed - like it has been done with C, chances are they will never be added to a langugage later. And with C they weren't. Be it in standard or an extention form. On the other hand, if a language _implementation_ suffers from performance problems, they can always be dealt with later; changing a language standard would be much more painful and inconvenient for everyone. Case in point C's string functions are not only ugly but broken. Buffer overflows. If language designers wanted to extend the language with new string functions that allocated memory - how easy of a change would that be? If on the other hand, one of the C implementations - GCC per se was suffering from performance probelms in the string functions (if were designed correctly in the language in the first place), they can be fixed without changing language standards.
Premature optimizations in language design, or application design are equally evil. Unfortunately, you have your "fast" blinders on and can't see it. You're already prematurely optimizing your imaginative, "nonexistent" languages in your head. It's okay. There will be time when you'll realize it's all about trade-offs, and speed is secondary to other goals of language design. Otherwise we'd all be writing machine code now. Furthermore, the resulting product written in "slower" language may very well be just as good performance-wise when it's done compared to an equivalent written in your "faster" lanaguage. Except your faster language will probably result in more bugs, more time-to-market, more complexity, and more people overhead because it wasn't suitable for solving the problem at hand in the first place. Best tool for the job, not fastest tool for the job. "Profile, don't speculate" comes to mind again.
That being said, your first alternative to Java is may still be Erlang for many types of problems. Such as distributed applications, scalable Internet servers, and of course soft-real-time telecom software. Erlang has concurrency, fault-resiliency and distribution built-in as language features, not bolt-ons. Java has far less to offer _for the same types of applications_. Same is true of C. C is a much better language for compression than Java for example for obvious reasons, and vice/versa. To summarize: there are applications in which any of these languages are more suitable than others. Broad generalizations such as "it's slow for any application" do not apply.
DJB's stralloc library, and a bunch of others already exist and very nice. Yet people are not aware of them, or don't care/wish to conform rather than avoid overflows.
Because DJB is smart enough not to rely on idiotic libraries like stdio and str*. He uses his own replacements for these. His stralloc library automatically allocates memory for strings - no buffer overflows possible.
Erlang has evolved into a _general purpose_ language. There's even a great 3D modeler and a load balancer written in Erlang. The standard libraries which ship with Erlang aren't just tailored to telecom applications anymore.
There's more than one kind of threads, but pthreads programming can result in a major PITA. Furthermore, it may not even offer any performance improvement if the design was incorrect. Don't think of threads as panacea.
Then, there's also the issue of legality of licensing. Does the law say anything about EULAs being a binding legal contract? No. AFAIK the law is only concerned with copyright. Therefore, as long as copyright is not violated, anything else the license disallows can be ignored.
iMATIX has an interesting system called Libero. Libero is used to build a state machine. Similar to a flow chart. After you're done, it generates everything but the code used in states. You then write state code. According to iMATIX, it saves you from writing spaghetti code, and is great for large/complex problems.
"* I know for a fact that real-world performance on NTFS (at least in the NT 4 era) is significantly slower than on ext2. I have a strong suspicion that a fair bit of that stems from the ACL security system MS uses in their filesystems. In terms of performance, ACLs are not a good choice."
This may also be because people expect the 'async' performance out of other FS'. I doubt NTFS is using asynchronous updates by default. On the other hand, W2K professional uses write cache on disks by default.
AFAIK in ReiserFS inodes are not used the way they're in traditional FS'. You certainly need to present the inode layer to the OS, but. They use Balanced trees for block allocation. AFAIK you do not end up with a fixed number of "inodes" after ReiserFS is created.
When people say slower, they forget these can be dealt with a RAID controller with battery-backed write-back cache. These have been getting cheaper and cheaper. It's like mounting your FS async with all the performance advantages and no fear of losing data at the time of a crash.
Package management solves the newbie problem, and breakes the core OS. OS itself must not be shipped in packages to avoid dependency problems. People would be much happier using CVS to update the OS, and packages for the add-on software.
User land libraries like state threads do not suffer from POSIX compliance, do not require intra-process, inter-thread synchronization (if design is correct, though some people on Slashdot make themselves believe otherwise), and are specifically designed for writing servers. And since it's the same library on all platforms it supports without a standards body, portability isn't much of an issue either, if at all.
Apache Accelerating Project used ST library when they were actively involved with the project, and according to the benchmarks project authors have done, at least on Linux the State Thread MPM module performed better (even though some people on Slashdot will hate me for saying this, accuse me of non sequitur, ad hominem, or some other such crap after switching to AC mode, etc.).
Slashdot Mirror
How about keeping email at the ISP in the first place?
http://cr.yp.to/im2000.html
Not everybody runs big SMP servers though.
NUMA is more scalable and less bottlenecked than SMP for big servers.
Soy is actually unfit for consumption unless fermented. See www.westonaprice.org.
"And you're claiming that it's not, simply because you like it. I'd say that my criteria are at *least* as valid."
That's not true. What I said was the microbenchmark you mentioned doesn't bear any significance for the many real-life projects' performance. Dismissing the language as slow just because some implementation of it performs poorly on some microbenchmark is valid? Be it Java or any other language. Take a look at the SEDA link I gave you. Or just google for 'SEDA' and 'Haboob'.
"Except that isn't usually the case. It simply isn't reasonable for a human to know all the timings for the various chips they're targeting and write perfect code any more, and even if they could, CPUs are too complex, and compilers too good. Rasterman, who writes a good deal of low-level code to do graphics stuff very quickly (and hence knows x86 assembly better than most), recently wrote how he spent a huge amount of time rewriting a C library in x86 assembly, and got no real speedups in his hand-tweaked one. Even tiny embedded systems are leaving assembly in droves, because compilers are *good* these days.
"
I thought you wanted to trade features and convenience for speed. Or is it some features and convenience?
"Your statement is simply nonsensical. Feel free to show Slashdot a place in the Java spec where it says "implemented JVMs shall utilize the pthreads library".
I don't think I was talking about the language specs at that point. Rather implementations.
"Fine, let me clarify it. Scalability, the sort of way Sun is selling is (which translates to "you can add more hardware to get some reasonable amount of performance increase" is totally fucking irrelevant to almost every software package in the world. Yes, perhaps erlang is useful for 80 node setups (I'm not saying it is, just that I don't care enough to try to find out). I (and the overwhelming majority of other people) are not working with 80 node setups, and the interesting factor is whether performance sucks on a single node system."
That's not the kind of scalability I was talking about. I was talking about application scalability. And it certainly is possible to write Java progs which scale better than equivalent C programs. On the same hardware. It has been done.
The difference is the kinds of applications. Labeling a language "just slow" for any kinds of applications make a lot of sense?
"Have you ever actually *seen* or *used* fputs()? I'd love to hear what "buffer overflow" you're thinking of, because I don't think you have the faintest idea what you're talking about."
I admit, I was thinking of gets(), and wrote 'fputs'. And no, I've never used either (and never will). There are great libraries for dynamically-allocated strings in C, but it would have been better if these were part of C in the first place (the standard).
"It doesn't add keywords -- it *is* extending the evironment that I'm writing in, however. This is also completely irrelevant, because the semantics don't matter -- only whether the missing functionality is present. Which it is."
This is relevant to our discussion, since you wrote speed is almost everything in a language. While I wrote that speed is secondary to other goals. If you trade those goals in a language design for speed, you would very unlikely find fixing these issues in the future easy. While performance issues can be dealt in the implementation far easier than breaking language standards. We both agree JVMs have become better performance-wise.
"[laughing my ass off] Okay, "orders of magnitude", eh? Before making a damn fool of yourself any more, run out and find yourself a benchmark where your C compiler produces code that is a *hundred* times slower than your hand-coded assembly. This should be entertaining. Find me...oh, a matrix multiplication benchmark, say, where assembly is 100 times faster than a C compiler can generate. I'd love to see what flaws *in the C language* you can find that would ever make C 100 times slower than assembly. The flaws I pointed out in Java were *in the language itself*."
Maybe not orders, maybe just one order. This is pure speculation anyway. The point is, these are all trade offs, Java and Erlang are higher-level languages than both C and assembly, and raw speed is definitely a trade-off for convenience, portability, etc., etc.
"Oh, stereotype me, will you. :-)"
That's okay, I was one of them.
"Look, I don't have a problem with Erlang as a language. There are, I'm sure, lots of good applications for it."
You said it was one of the slowest languages, because some microbenchmark says so.
"The problem is that I'm looking for a language that focuses on speed, which there is a decided paucity of recently. Despite all the compiler improvements and optimization techniques developed, the fastest choice around is generally *still* C and C++, the first of which is *decades* old, and the second of which has a lot of old baggage."
Nah, your best bet are zeros and ones.
"I want modern functionality with even *better* speed. That's all. Erlang is not what I'm looking for, but that doesn't mean it's not good for some people."
Great, we both agree on this.
"I wouldn't call Java's support bolted on. It's language level as well."
Ah, ah, ah, it still depends on pthreads. pthreads isn't native.
"That's nice (I was quite impressed with CML, which has similar capabilities), but it doesn't really help me unless I'm dead set on writing a program with thousands of preemptive threads."
Non-preemtive threads.
"Your link (well, what should have been a link) is dead. And scalability is mostly irrelevant."
Righhhht, scalability is mostly irrelevant. Not for everybody.
"Saying "Java is slow" has some quite obviously understood implications by both you and me, so don't play stupid. That doesn't win any arguments. Java may well be faster at...oh, I don't know, closing. For the vast majority of cases, if I want to sit down and write something that a user interacts with, a Java program is much more sluggish than a C++ program. This is not something that I'm the only one trumpeting -- anyone that's used Java has run into this. And don't give me the "you're using a slow JVM" bullshit that Java advocates love to spout -- I've been developing exclusively with IBM's JDK. There isn't a faster JVM out there for Linux."
Your problem seems to be Swing, not Java. Furthermore, JVM isn't the only way to implement Java.
I still think your complaint should be about Swing, and not Java.
"As for your claim that they can always be dealt with later in the implementation, I have an excellent counterexample -- the JVMs that you're so staunchly supporting. When Java was released, it ran like a dog. Sun promised that better compilers would improve things. Optimization got a little better. JITs helped. And you know what? Java is, indeed, faster than it once was. It is *still* sluggish, however. And it's not going to improve much more. And the *language* has limited this -- the lack of typed container objects, the required bounds checking, the almost-impossible-to-avoid reliance on heavy heap-based dynamic allocation of memory. No implementation can fix this."
So if they've improved performance over the years, it can't be done anymore for some imaginative reason? Garbage.
"Java as a *language* is terminally limited to never run faster than at a certain clip. Now, it's still quite useful for many things, but not for performance-critical stuff, which happens to matter to me."
Right, like some end-user GUI stuff. Performance critical indeed.
"And I won't agree with you there."
'fputs' isn't broken? Can you say buffer overflow by design?
"Really, really easy. Look at glib for C or any one of many, many good string classes for C++."
Wrong. This isn't language extention. This is a library written by someone.
"How do you think someone is going to "prematurely optimize" a language spec? Do you want to wait until a language is widely used and *then* run out and make lots of changes to it? Heck, that isn't even relevant."
Reread my last response.
"And one day, *you* will realize that having a speedy language does not entail *losing* other functionality."
C is definitely slower than assembly on micro-benchmarks, and even otherwise. Orders of magnitudes slower. Your point?
So you're one of those from the "broad generalization" camps. Just because a language is slow at particular micro-benchmarks such as the link you provided, doesn't mean it's "the slowest major language out there". Statements like these are broad generalizations, religious nonsense.
Erlang's threading doesn't depend on an OS library - pthreads. An Erlang thread looks like a process to an Erlang programmer - which makes thread programming look like multi-process programming with inter-process-communication - easy. Java doesn't even come close. In Erlang, concurrency is a language _feature_. In Java it's an alien invader _bolt-on_ with all the resulting inconveniences and OS-dependence. Same goes for Ada - concurrency is a language feature, not a bolt-on. Also an Erlang process is said to be orders of magnitutde lighter than Java thread. Read the site, would you. Erlang applications scale well with thousands of threads without the overhead of programming pthreads. Erlang was designed such that each concurrent process in a given problem can be mapped to a concurrent process in Erlang language. It's a feature, not a bolt-on.
"Modern *fast* languages are almost nonexistent" -
another broad generalization. How fast and how fast for solving which problems? Java has been used to write a scalable application framework which has been used to write a web server which scales better than an equivalent C-based server. See http://www.cs.berkeley.edu/~mdw/proj/seda/. Your broad generalization that Java is slow in any case, any kind of application, anywhere (just because you have this idea in your head), falls flat on its face. "Profile, don't speculate".
I am not a big Java fan, but your broad generalizations cannot be further from the truth. The rest, are even more ridiculous.
"But those can be added later" - you have it backwards. Don't confuse language with a langugage implementation. If you sacrificed language features to speed - like it has been done with C, chances are they will never be added to a langugage later. And with C they weren't. Be it in standard or an extention form. On the other hand, if a language _implementation_ suffers from performance problems, they can always be dealt with later; changing a language standard would be much more painful and inconvenient for everyone.
Case in point C's string functions are not only ugly but broken. Buffer overflows. If language designers wanted to extend the language with new string functions that allocated memory - how easy of a change would that be? If on the other hand, one of the C implementations - GCC per se was suffering from performance probelms in the string functions (if were designed correctly in the language in the first place), they can be fixed without changing language standards.
Premature optimizations in language design, or application design are equally evil. Unfortunately, you have your "fast" blinders on and can't see it. You're already prematurely optimizing your imaginative, "nonexistent" languages in your head. It's okay. There will be time when you'll realize it's all about trade-offs, and speed is secondary to other goals of language design. Otherwise we'd all be writing machine code now. Furthermore, the resulting product written in "slower" language may very well be just as good performance-wise when it's done compared to an equivalent written in your "faster" lanaguage. Except your faster language will probably result in more bugs, more time-to-market, more complexity, and more people overhead because it wasn't suitable for solving the problem at hand in the first place. Best tool for the job, not fastest tool for the job. "Profile, don't speculate" comes to mind again.
That being said, your first alternative to Java is may still be Erlang for many types of problems. Such as distributed applications, scalable Internet servers, and of course soft-real-time telecom software. Erlang has concurrency, fault-resiliency and distribution built-in as language features, not bolt-ons. Java has far less to offer _for the same types of applications_. Same is true of C. C is a much better language for compression than Java for example for obvious reasons, and vice/versa. To summarize: there are applications in which any of these languages are more suitable than others. Broad generalizations such as "it's slow for any application" do not apply.
DJB's stralloc library, and a bunch of others already exist and very nice. Yet people are not aware of them, or don't care/wish to conform rather than avoid overflows.
Because DJB is smart enough not to rely on idiotic libraries like stdio and str*. He uses his own replacements for these. His stralloc library automatically allocates memory for strings - no buffer overflows possible.
Erlang has evolved into a _general purpose_ language. There's even a great 3D modeler and a load balancer written in Erlang. The standard libraries which ship with Erlang aren't just tailored to telecom applications anymore.
There's more than one kind of threads, but pthreads programming can result in a major PITA. Furthermore, it may not even offer any performance improvement if the design was incorrect. Don't think of threads as panacea.
Then, there's also the issue of legality of licensing. Does the law say anything about EULAs being a binding legal contract? No. AFAIK the law is only concerned with copyright. Therefore, as long as copyright is not violated, anything else the license disallows can be ignored.
Why not simply use automatically rotated and sized logs, such as provided with "multilog"?
iMATIX has an interesting system called Libero. Libero is used to build a state machine. Similar to a flow chart. After you're done, it generates everything but the code used in states. You then write state code. According to iMATIX, it saves you from writing spaghetti code, and is great for large/complex problems.
http://www.imatix.com/html/libero/
"* I know for a fact that real-world performance on NTFS (at least in the NT 4 era) is significantly slower than on ext2. I have a strong suspicion that a fair bit of that stems from the ACL security system MS uses in their filesystems. In terms of performance, ACLs are not a good choice."
This may also be because people expect the 'async' performance out of other FS'. I doubt NTFS is using asynchronous updates by default. On the other hand, W2K professional uses write cache on disks by default.
AFAIK in ReiserFS inodes are not used the way they're in traditional FS'. You certainly need to present the inode layer to the OS, but. They use Balanced trees for block allocation. AFAIK you do not end up with a fixed number of "inodes" after ReiserFS is created.
Just to note: ReiserFS is also inodeless. This means you can't run out of them, as far as I can imagine.
When people say slower, they forget these can be dealt with a RAID controller with battery-backed write-back cache. These have been getting cheaper and cheaper. It's like mounting your FS async with all the performance advantages and no fear of losing data at the time of a crash.
Package management solves the newbie problem, and breakes the core OS. OS itself must not be shipped in packages to avoid dependency problems. People would be much happier using CVS to update the OS, and packages for the add-on software.
Where is the 700% figure from?
The author does not state whether QSC was used in testing. But this is definitely worth finding out.
And why are YOU replying as an AC?
Okay, then why are you replying as AC?
"and was almost entirely due to parts of AAP other than the ST MPM."
Where is it stated? Show me, before you go acusing me of lying.
P.S. Is this "Salamander" If so, then why are you hiding behind AC?
User land libraries like state threads do not suffer from POSIX compliance, do not require intra-process, inter-thread synchronization (if design is correct, though some people on Slashdot make themselves believe otherwise), and are specifically designed for writing servers. And since it's the same library on all platforms it supports without a standards body, portability isn't much of an issue either, if at all.
Apache Accelerating Project used ST library when they were actively involved with the project, and according to the benchmarks project authors have done, at least on Linux the State Thread MPM module performed better (even though some people on Slashdot will hate me for saying this, accuse me of non sequitur, ad hominem, or some other such crap after switching to AC mode, etc.).
I wasn't the one speculating FreeBSD threads suck.
Talk about Ad Hominem indeed.