Occam's razor actually says (in the context of generating hypotheses) "one should not multiply entities beyond necessity." One interpretation of that maxim is "the simplest explanation is best." A good interpretation in some contexts, but not the only interpretation.
Anyway, a soul would be an entity whose existence is postulated unnecessarily if the brain itself can reasonably be postulated as the source of the phenomenon. So, what "simpler" means in this case is fewer entities (and types of entities, such as immaterial souls) that we have to invoke in order to explain something. Not that a soul is somehow more complex than the brain (how would we know?).
A major criticism for any mix of materialistic and spiritual entities having causal relations (such as the one above where someone questioned how we know there isn't a *real* out of body experience that just happens to coincide with a particular kind of cerbral stimulation) is the lack of any means to causally relate a material thing ( even a force) with something spritual. The reverse, having a spritual thing cause things in the material world, is just as problematic.
Dug up our performance white papers and benchmarks on this. Doesn't include Tomcat 4.0 or 3.3, but does include 3.2. For now you'll have to take my word on the relative performance of 3.3 and 4.0.
Tomcat 4.0 is incredibly slow, throughput-wise, and it's not scalable at all.
I've done internal benchmarks with Tomcats 3.2.3, 3.3 and 4.0. Tomcat 3.3 is around 7x faster than the other two. Tomcat 4.0 isn't meant for production (yet), but eventually they'll get around to making it faster now that it'll enjoy a wider distribution on the back of Sun's J2EE marketing.
Orion, Resin and JRun 3.x are all faster and more scalable than any version of Tomcat by a longshot. So is Weblogic 6.x, for that matter. Any app server that embeds Tomcat is as slow as Tomcat on the Web tier, and that includs Borland and iPlanet (though Borland, at least, makes up for it in EJB performance).
"The Java virtual machine does not assume any particular implementation technology, host hardware, or host operating system. It is not inherently interpreted, but can just as well be implemented by compiling its instruction set to that of a silicon CPU. It may also be implemented in microcode or directly in silicon." from Chapter 1, the Introduction.
Since the JVM is responsible for garbage collection, this implies that the concept of implementing memory management in the hardware is at least 4 years old.
I find it hard to believe no one's thought of this idea before for C, C++ (and so on) either.
I wouldn't knock it till they try it or, at least, someone publishes some calculations that prove or disprove the possibility of major speed-ups.
I have an AMD Athlon 700, 192 MB PC100 RAM, and 13 GB Ultra ATA 7200 RPM drive. These results are from my workstation system running RedHat 6.1.
Apache 1.3.9: less than 30 seconds (25-30 sec. on three different runs) to compile Apache 1.3.9 from source with DSO support the only configuration option.
Tomcat 3.0 42-47 seconds to build Tomcat 3.0 from source (three different runs for comparison). Compiler used was javac shipped with Blackdown 1.2.2rc3 JDK.
2.2.13 kernel Just under 2min 30 sec. to compile with a pretty standard config for my system (no sound, no SCSI suport) on two runs.
Here are some enlightening links on AMD Athlon performance and benchmarks:
These benchmarks will always yield spurious results until they can test the same software on different operating systems. The test really compares the speed of Apache on Linux versus the speed of IIS on NT (which is tied into the OS's kernel, which may make a large performance difference). Apparently they don't feel Apache on Linux versus Apache on NT is a valid comparison because the Apache Group warns that the Win32 version is beta software.
As a rule, the "tests" or "studies" done by Mindcraft favor the sponsor of the tests. The recent Apache versus iPlanet benchmark they did is another fine example. When you read the actual reports they write up, you can find several places where the the scientific value of the benchmarks is corrupted by time constraints imposed on the losing side. Even in this June 30th Apache/IIS showdown, the RedHat team had to fly home in the middle of Phase 3, and they didn't have (sc., weren't allowed) time to implement and tune the latest build of RedHat.
Until _Consumer Reports_ or a similarly disinterested, research- or consumer-oriented venture (boy, there's a niche waiting to be filled) starts doing benchmarks, we are not going to see truly scientific benchmarks.
Slashdot Mirror
Occam's razor actually says (in the context of generating hypotheses) "one should not multiply entities beyond necessity." One interpretation of that maxim is "the simplest explanation is best." A good interpretation in some contexts, but not the only interpretation.
Anyway, a soul would be an entity whose existence is postulated unnecessarily if the brain itself can reasonably be postulated as the source of the phenomenon. So, what "simpler" means in this case is fewer entities (and types of entities, such as immaterial souls) that we have to invoke in order to explain something. Not that a soul is somehow more complex than the brain (how would we know?).
A major criticism for any mix of materialistic and spiritual entities having causal relations (such as the one above where someone questioned how we know there isn't a *real* out of body experience that just happens to coincide with a particular kind of cerbral stimulation) is the lack of any means to causally relate a material thing ( even a force) with something spritual. The reverse, having a spritual thing cause things in the material world, is just as problematic.
Dug up our performance white papers and benchmarks on this. Doesn't include Tomcat 4.0 or 3.3, but does include 3.2. For now you'll have to take my word on the relative performance of 3.3 and 4.0.
JRun Server Performance Reports
Tomcat 4.0 is incredibly slow, throughput-wise, and it's not scalable at all.
I've done internal benchmarks with Tomcats 3.2.3, 3.3 and 4.0. Tomcat 3.3 is around 7x faster than the other two. Tomcat 4.0 isn't meant for production (yet), but eventually they'll get around to making it faster now that it'll enjoy a wider distribution on the back of Sun's J2EE marketing.
Orion, Resin and JRun 3.x are all faster and more scalable than any version of Tomcat by a longshot. So is Weblogic 6.x, for that matter. Any app server that embeds Tomcat is as slow as Tomcat on the Web tier, and that includs Borland and iPlanet (though Borland, at least, makes up for it in EJB performance).
"The Java virtual machine does not assume any particular implementation technology, host hardware, or host operating system. It is not inherently interpreted, but can just as well be implemented by compiling its instruction set to that of a silicon CPU. It may also be implemented in microcode or directly in silicon." from Chapter 1, the Introduction.
Since the JVM is responsible for garbage collection, this implies that the concept of implementing memory management in the hardware is at least 4 years old.
I find it hard to believe no one's thought of this idea before for C, C++ (and so on) either.
I wouldn't knock it till they try it or, at least, someone publishes some calculations that prove or disprove the possibility of major speed-ups.
I have an AMD Athlon 700, 192 MB PC100 RAM, and 13 GB Ultra ATA 7200 RPM drive. These results are from my workstation system running RedHat 6.1.
Apache 1.3.9:
less than 30 seconds (25-30 sec. on three different runs) to compile Apache 1.3.9 from source with DSO support the only configuration option.
Tomcat 3.0
42-47 seconds to build Tomcat 3.0 from source (three different runs for comparison). Compiler used was javac shipped with Blackdown 1.2.2rc3 JDK.
2.2.13 kernel
Just under 2min 30 sec. to compile with a pretty standard config for my system (no sound, no SCSI suport) on two runs.
Here are some enlightening links on AMD Athlon performance and benchmarks:
Note: none of the benchmarks I gave above used any custom compiler optimization settings.
These benchmarks will always yield spurious results until they can test the same software on different operating systems. The test really compares the speed of Apache on Linux versus the speed of IIS on NT (which is tied into the OS's kernel, which may make a large performance difference). Apparently they don't feel Apache on Linux versus Apache on NT is a valid comparison because the Apache Group warns that the Win32 version is beta software.
As a rule, the "tests" or "studies" done by Mindcraft favor the sponsor of the tests. The recent Apache versus iPlanet benchmark they did is another fine example. When you read the actual reports they write up, you can find several places where the the scientific value of the benchmarks is corrupted by time constraints imposed on the losing side. Even in this June 30th Apache/IIS showdown, the RedHat team had to fly home in the middle of Phase 3, and they didn't have (sc., weren't allowed) time to implement and tune the latest build of RedHat.
Until _Consumer Reports_ or a similarly disinterested, research- or consumer-oriented venture (boy, there's a niche waiting to be filled) starts doing benchmarks, we are not going to see truly scientific benchmarks.