Slashdot Mirror
The Fastest Web Language On The 'Net?
"Basically, we are not experts in any one language, but have quite a bit C/C++/Perl experience. The target platform will be Apache on *nix, but a portable solution would be good. At the moment we have the engine coded in C for CGI which then interfaces with MySQL to store game data. We are thinking of hacking in FastCGI support for a good boost in speed, but we feel a complete recode will be neccesary, as the amount of players in the game will soon be hitting 5 figures."
"At this point we pretty much know CGI alone is out of the question from a speed standpoint, so we are looking for something a bit more robust. We have heard that mod_perl may be a good solution, but have also heard the same for Python, PHP, C++, etc, so if anyone has experience with dynamic content like this, and has some suggestions and comments as to the merits of your choice, we would appreciate it."
Meanwhile, on the other side of the galaxy, slartiblartfast asks of his improbability computator, a similar question: "I have been wondering for a while if anyone has some really good metrics on the relative performance capabilities of the different scripting languages. By scripting languages I mean Perl, PHP, JSP, ColdFusion, ASP etc and by performance I mean how many pages can each one serve per second for the same hardware and load test? Every benchmark I have seen was commissioned by the creators of the technology that eventually won the test. i.e. The guys implementing the technology that won just happened to be on the core development team for the product. Now I just can't swallow that sort of thing, so I thought I'd ask here. Has a truly independent test been done that didn't favour one technology over another, or that at least invited the best from each area to build and optimize the site to be tested?"
Careful. There are lies, damned lies, statistics...and then there's benchmarks. It's a quote that's been seen often enough, here on Slashdot, but it still has its own bit of wisdom to impart.
* ALL YOUR BASE ARE BELONG TO US: Annoying fad or rallying cry of the internet generation?
(Please god, don't let Jon Katz see this)
FWIW, PHP seems to be the most stable all around. I don't know about 10000+ users, but it does well on just about everything else
Hell, you could submit it as a lacking feature in Mozilla, and if you're lucky they'll code it in _for_you_ in their .9 milestone.
PHP runs circles around other languages, especially when you download the ZendOptimizer (a free download from zend.com). We host a site that gets in the neighborhood of 10 Million hits a month, with just about every page on the site hitting the MySQL backend with large amounts of data and it runs as fast as if you were the only one browsing the site.
If the application has to serve dynamic content to a browser, I would recommend to use Java Servlets. This may appear to be a slow solution on first look (Java is 10-20 times slower than C in most cases), but there are some considerable advantages to this approach:
There is also a way to achieve this in C: Write an Apache module. This will almost certainly provide the maximum speed. However, the development effort will also be considerably higher.
Sebastian
I should have the Velocigen vs. mod_perl tests soon enough, which I'm kind of anxious to see. I predict a similar stomping.
Granted, neither of these are free products, but then again - speed always comes at a price, unless you're talking about hookers. ;>
If you're into Perl, check out Velocigen - it's like mod_perl, but a much, much better/faster design. Depends on if you want a free solution, or a commercial one and how fast you want to go. Everything Solaris will be doing a "shoot out" between Apache w/mod_perl and Zeus w/Velocigen, among others like iPlanet and Roxen shortly.
Java servlets will beat c/c++/perl/[name your favorite language or scripting environment] in nearly all cases. The exceptions will be isapi/nsapi/apache modules written directly to the webserver api. The other benefit is the fact that you have access to the full java api, which provides extremely rich functionality - anything from sending email to building images on the fly is quite easily implemented.
regarding your sig: Inheritance, and luck. If you're so smart, how come *you* ain't rich yet? (I'm not rich either...) :>
no taxation without representation!
One other addition.
PHP, JSP, or any other language that you can embed into your web server would be fine. Although I wouldn't use anything other than mod_perl or C apache modules, as long as you aren't forking your CGI as a separate process you should be fine.
Thx for the clarification.
This is a really good point.
As an example, our local university is doing research in quantum computing, and is using a large beowulf cluster for simulations. All the libraries they use are written in C/Assembler, but the tasks they write are all in Python. This combination gives them fast execution, but the programs are fast and easy to code.
Fair enough, but this is one reason Apache was designed with an API and is released Open Source.
Investigate mod_perl, etc., before casting aside Apache.
--
Breakfast served all day!
What, you mean a stack trace? What's so hard about that?
Since you can add multiple web servers running the same application in parallell and another one dedicated to serving images, you have to worry no more about the programming language you choose; any one will work just fine with enough machines.
The main problem is that all your web servers will be connecting to the same database server so you need a database wich allows you to have a very large number of concurrent connections (in the order of hundreds or even thousands, 100+ connections per web server) without a big performance hit.
Depending on the nature of your application you should also be thinking about the possibility of mirroring (for more selects than inserts/deletes/updates) or distributing (for the opposite) your database.
I am thinking about Postgres 7 or Oracle because I've worked with them and they've proved (with enough memory) to handle the load of busy and complex web pages, but you can ask slashdot about the fastest and most scalable database for web serving.
--
Claim your namespace.
--
We're a training company, and there is a list of available courses (in static HTML that I update by hand). Then, there is an Apply link. When you click the Apply link, a window pops up with a form to fill out. Some fields in the form have to be pre-filled.
Guess how those fields end up being pre-filled? There is a separate HTML file for every instance of the class. New class, new date, new HTML file.
A few days ago, I was given the task of changing a few fields in this form...
--
I've been coding in EJB's for six months (using WebLogic 5.1) and ran into the following problems (with entity beans).
1) excessive database traffic. A single SQL query using bare JDBC turns into N+1 queries if you use entity beans. There's one query for the finder method, plus one query to load each row found by the finder method. This is a stupid way to query a database.
2) excessive locking. Entities are locked (using exclusive locks) until the transaction completes. This can lead to lots of threads waiting on the same lock, or possibly even deadlocks. All that nice concurrency you get from using a database with row-level locking, shared locks, or read-only queries gets thrown out the window.
3) gets in the way of SQL optimization. To get good performance you need well-tuned SQL. Container-managed persistence makes people think they don't need to learn SQL.
4) reduced caching. The only thing WebLogic gives you for caching is read-only beans. On your own you can probably come up with much better caching strategies.
We started out all EJB's and will continue to use them for our intranet since they're good enough for a low-traffic application, but will not use them for our Internet site. If I had to do it again I wouldn't use EJB's. (Although, to be fair, I suppose you could do okay if you used Session beans only and wrote all your own SQL.)
JBoss is an excellent Open Source EJB server, plus all the other J2EE goodies. Some say better than WebLogic.
-Hunter
RateVegas.com - Vegas Reviews
You people are making the problem MUCH harder than it has to be! Look around: I'll just bet that there are several networked computers with dedicated, HARDWARE interpreters, for the most powerful language of them all:
PostScript
C'mon! What's with all the unnecessary complexity? And as an added bonus, we can all start leveraging our huge investment in OpenStep (GNUStep for the FSF-inclined.)
(jfb)
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
"I hand-filed gears, sprockets, cogs and pistons for my own Babbage Difference Engine, arranged for shipping for thirteen metric tonnes of high-grade coal from China, ..."
What kind of wuss won't even mine his own coal?
or you could use the TUX kernel patch and write a c based cgi called from tux for anything dynamic
meridian at tha.net
The other thing to consider when deciding between compiled code and assembly on modern processors (both CISC and RISC) is that the chips themselves do so many pre-execution optimizations in hardware that your assembly is probably being rewritten anyway. Probably better to compile and examine the compiled code for critical sections to make sure the compiler didn't do something really stupid and be done with it.
It all comes down to design. Eliminating the overhead of CGI is good. Persistance is good. Keeping as much as you can in memory is good. Re-use of allocated resources is good. Using memory wisely is good. Eliminating dependancies so you can distibute the load over losts of machines is good. Taking advantage of the strong price-performance of x86 machines for CPU intensive stuff is good.
Raw execution performance is important, but there are a million ways to slow your application down.
http://java.sun.com/j2ee
Justen Stepka
It's even easier to build a great OO design (using the Model-View-Controller pattern) if you dump JSP and use a template package like FreeMarker, Velocity or WebMacro. JSP lets you embed Java code in your webpage, so business logic gradually creeps out of your servlets and into your HTML, making maintenance more difficult. Template packages help you keep your business logic and page design separate by keeping the code in the Java servlets and the HTML in the webpage templates.
I agree pretty much completely. I would add an extra step in there to figure out if the straight line speed of a C++ Apache module was worth the portability and difficulty of distributed processing penalty.
My instincts would say sacrifice the straight line speed for something in Java that can be easily distributed, but I have absolutely nothing to base that on. Either way, I think you nailed it.
(When I mention statistics, I'm referring to the question I've asked about how many people it took to be talking about the all your base phenomenon for it to really take off. I expect that there's an exponential curve to be identified: people saying all your base are belong to us at every chance they get over time.
But how is that sort of thing identified and tracked? To track it, does some net sociologist have to recognise the next all your base before it takes off? Can it be deduced from mail logs?
Nobody I know has been able to answer these questions yet, but they all want to know the answers.)
--
You're a suburbanite.
Assuming the ASM is done rationally, most of the ASM code will be slower than the equivalent C code, but the ASM subprogram will be faster because the optimizations will be done where it matters.
I'm sorry, is that a rhetorical question?
Given, coding in Magyar is difficult, but then you do get Hungarian notation for free.
"If I am such a genius, how come that I am drunk and lost in the desert with a bullet in my ass?" --Otto (Malcom ITM)
Not necessarily. Modern CPU architectures make writing assembly a bitch due to pipeline stalls, resource conflicts on the CPU, etc. A really good optimizing C compiler can do much better than the average human can with hand-coded assembly. Assembly still has its uses for small, embedded and low-level things, but it's no longer necessarily the fastest, especially if you have a good compiler.
For equivalent purposes, the difference is minimal, and not worth the effort, since it's presentation code anyway. You shouldn't be mixing your presentation layer with your business logic.
:-)) Your statement is mostly a myth in this day and age, anyway. A decent C compiler can produce faster code than hand-written assembly on most modern platforms, for anything greater than a microscopic example.
As for the difference between C++ vs. assembly, C vs. asm is probably a better analogy, as it is a one-step difference. (C is basically just a really nice macro assembler
php, optimized with zend's optimizer will outperform jsp by about 15%
Be careful with that kind of generalization, unless you're going to post references. There's a huge variation in jsp engine performance. This is a vendor benchmark site (so take it with a grain of salt, especially where their product is concerned), but you can see how wide the range of performance can be between JSP/Servlet engines.
I'd be inclined to go the other way - run Apache for dynamic content (my personal preference would be PHP btw - it's very fast, easily scalable and rock-solid, all things I wish ColdFusion, which I have to work with, were). Then run a lightweight high-performance web server like thttpd, boa or khttpd to serve static content. It's fairly easy to set up khttpd so that it'll serve any requests for static files itself and transfer any dynamic requests on to an Apache server running on a different port. thttpd has some PHP support as well - that might be worth looking into too.
I'd have to agree. MySQL is pretty fast for basic stuff, but try to do anything more than a 3-way join on a decent-sized table, and you can go get yourself a cup of coffee while you wait for the results...*sigh*...I know this from experience.
PostgreSQL 7.1 is supposed to be all that, though. Anyone know if it has seperate tablespaces yet?
"Primary bottleneck" and "all the other bottlenecks"? How does that work?
--
Patrick Doyle
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Aren't ad hominem arguments cool?
I know Java is but what am I?
Anyway, I refer you to the February 2001 issue of Java Report, specifically to an article entitled "High Performance Java Software Development". One of the timing comparisons presented in the article mentions that it can take Java (HotSpot JIT) as much as 115 seconds to run a 1 million point quicksort. It takes C++ 0.88 seconds to do the same.
The universe is bad enough without people poking it. -Mustrum Ridcully
Wouldn't it be more like the "disease vector"s that the NIH refers to? I'm think graph theory and linear alg. as much as stat.s
do I need to say more?
--
It has to work - rfc1925
A free alternative for Zend is APC.
Check it out at http://apc.communityconnect.com/
;)
Choose a fast web server that allows you to embed scripts inside the server process. Apache gives you lots of choices in this area: mod_perl, mod_python (and mod_snake), PHP or even C. But Apache isn't exactly the fastest web server on the face of the earth (but it should be fast enough). AOLServer is very fast and lets you use Tcl or C (PHP works too, I believe).
The point is that you should use the language you're familiar with and spend more time worrying about the environment the software will execute in. That's where you're going to get the most performance improvements.
// TODO: Insert Cool Sig
Screw Ed. Emacs is the best editor!!!
// TODO: Insert Cool Sig
a retard? C is hands-down the fastest mostly-cross-platform language on the block. What CS school did you go to?
"First rule of government spending: Why build one when you can build two at twice the price?" -- Mr. Haddon, Contact
Would it be possible to take the Apache source, and dumb it down to cut all overhead but the processing of a specific module, run it as a seperate server, and get the same effect?
I think it helps to compile Apache with the smallest possible set of modules - i.e. the bare necessities. Some configuration directives can make a difference also.
--
This thread has had it. I mean, it's like a bunch of old guys comparing willies to see whose has the most wrinkles in it. Then, after the fun is done, nobody can even remember what got them started...
Python on its own is not a speed demon by any means. What it is fast at is development. And it is extremely fast.
I've found that whenever I need my Python to go faster coding up a simple C module for python is as fast as I'll ever need. I've gotten a 100x speed improvement by writing a simple text manipulation function in C.
However, more to the point of your web-based interface question, I don't think that language selection will really have much bearing on your actualy real world performance. I mean, look at Slashdot! It is written in Perl and not even the most optimised perl, and yet they are handling extremely large amounts of traffic.
I'd let slashdot be your model and use what they use: hardware. While perl is faster than Python the development time you save should let you afford more hardware if you need it. But I don't think you'll need it.
I can't spell or type, but that doesn't mean I'm unusually stupid.
Was this with servlets in mind? It seems that the nature of servlets would lend itself to JIT particularly well.
I suppose I'm not too threatening, presently, but wait till I start Nautilus
You can get almost any major RDMBS (like oracle or DB2) for development purposes for free. You other point is pointless too, if you want speed you need the information ready at all times, why would you wait for your box to load it into memory? I would assume the machine should be dedicated to the task at hand, no worring about trying to find life in outer space with its "free cycles"
PHP is what I use strickly because it was designed from the ground up to work on the web, and to be extreamly fast. The Zend engine, for those that dont' know, it's the component that watches the behavior of the php scripts and then optimises the apache server accordingly. I liken the functionality to the code-morphing tech in the Transmeta chips in that Zend looks for more efficient ways to run your scripts. This is unlike other technologies such as mod_perl, for example, that dont' use any realtime optimization. I cannot comment on CFM, JSP, or ASP cuz I dont' know enough about them, but I do know that most folks say PHP is faster than them, but again it might be the jaded remarks of PHP enthusist. I think that C/C++ would be fast, but please, its not a fast process to develop in, and will take more time than a scripting language to implement. If you think c/c++ will take a long to to implement, the Assembally with take twice as long. These compiled solutions are not RAD (rapid application development). Unfourtunatly I hear ASP is good for RAD, but do you really want to support a proprietary system that doesn't work so good on Unix w/Apache?
It isn't a lie if you belive it.
* time to change jobs ?
Not quite. C++ is pretty efficient but when you get down to it, it is still quicker to use assembly.
Assembly wrapped in some minimal supporting C is probably the best.
It's all about joe. WordStar, baby!
Also, if you are using PHP, use a cacher (such as the Zend cache or one of the free cachers), as well as the extra Zend optimizer binary. The cacher keeps compiled PHP code so that it doesn't have to be parsed, lexed, etc. every time the page is loaded.
PHP also has a smaller memory footprint than perl, but IMO the solution to this is to use whichever language suits you better and buy more RAM as needed.
The point is if you're running a server app, the amount of time to start to program is insignificant compared to the amount of time the program will be running. Consequently, the speed once it's started up and going is what's important. So it's not a gimmick. JITC is less significant to the average user who starts up a Java program every once and awhile since the loading and translating overhead is incurred each time.
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Higher Logics: where programming meets science.
And using them will make you want to go gcj@#$!@#
Talk about a nightmarish java compiler.
I would be very hesitant to base any enterprise solution on any of the current templating languages. There's just too much String manipulation happening at runtime.
Also, last time I checked (approx three months ago), these language were missing some very important features. For example, WebMacro has no for loop, only a foreach loop. This means that during runtime, you must recurse through the entire collection, not just the desired sub-collection.
There really isn't one good answer out there that seperates out view logic from application logic, but the eventual solution *will* be JSP (read: taglibs...struts is headed in the right direction, just down the wrong path)...JSP's are only messy if you have java code in them.
</$0.02>
"Don't blame me, I voted for Kodos!"
I saw an experimental option on 2.4.2, an httpd on the kernel that servers the static pages, and leaves all the other requests for the normal httpd.
I've never tryed it, but sounds nice.
--
--
Stay tuned for some shock and awe coming right up after this messages!
...and the other half are from ZDNet, so they could be made up as well.
The real reason they stop arguing is because they know that ed shines in very few places and that you probably aren't serious suggesting it over everything else.
blessings,
"Only in their dreams can men truly be free 'twas always thus, and always thus will be."
--Tom Schulman
In fact, you can emulate a lot of the features of stuff compiled into a module by using very small compiled CGI that do very little, and pass off the work to server processes/SQL/whatever. By avoiding linking to libraries you can avoid, and reducing code/memory size you reduce overhead. Also, try having only a few executables with lots of features, and hardlinks to them with different names for different purposes (think shell commands for root floppy disks, where cat, ls, and more are all the same proggy)
On a completely unrelated note, I've had good experience using Makefiles to keep the state of the CGI scripts up to date when making modifications, if that is another concern.
Black holes are where the Matrix raised SIGFPE
I have had great experience with using C and C libraries for developing websites. They are incredibly fast. To reduce overhead, consider using FastCGI (it's really cool too, but I haven't tried using it. I only know what it can do from other people where I work). Or you can do what I do, and make your cgi apps REALLY small (<100K) so they don't ever leave memory when they get called. And make them handle only the work associated with formatting/displaying the HTML and relaying requests: put all the heavy processing in backend server and communicate via sockets or better yet, IPC shared memory.
Black holes are where the Matrix raised SIGFPE
I really can't help myself. It's POLL, not POOL. Sorry
As long as we are posting language performance comparison sites, The Great Computer Language Shootout should be mentioned. You can specify your own weightings for the various tests in the shootout, and the page's author is always looking for ways to improve his tests.
The .tgz file that contains the Indy Demos that ships with Kylix has some distribution problems. Some files were omitted in Borland's .tgz and other files had their case changed which has caused nearly all the demos not to compile.
Donate free food to the hungry at The Hunger site.
From PostgreSQL To Do List:
Under the title "EXOTIC FEATURES":
Add the concept of dataspaces/tablespaces
...it is not planned for 7.1
Donate free food to the hungry at The Hunger site.
Don't laugh -- Interstelen is a similar game to what's being discussed here (though not as massively multiplayer presumably), and has an Esperanto name. (It's being written in Python, though.)
max
But still, the question is valid. MySQL has all sorts of different performance modes depending on the table type you use and the numer of connections you form to it. If you only have one connection passed around to all of your script executions, that's one thing. If you have a new connection for each script execution, that's another.
The particular language you use won't really save you there. Anyhow... My $0.02.
Notice: Your mouse has been moved. Windows will now restart so this change can take effect.
Basically, it sounds like you need a dedicated game server, not an HTTP server tied into a game backend.
I'd create a custom HTTP server, that has the game logic built right in. Thanks to open source, getting a fast efficient HTTP handling mechanism is easy (strip down Apache, or look at some other, smaller open source servers). Then just add your game logic, either as statically linked code, or even better, as loadable modules of C or C++ code. You get the best of all worlds; HTTP support, blinding speed (no CGI interface overhead, no JVM, no script interpreters, etc), all in a tightly integrated package.
An abacus?
;)
Back in my day we had to use our fingers. Each finger representing a bit, giving us a whole byte. (we didn't use our thumbs) But we knew how to optimize code back then so it was a non-issue. One byte ought to be enough for anyone right?
0100 0010 was comonly used while debugging!
Actually, that's not true. You must be thinking of some system built on top of mod_perl, like Embperl or Mason. By itself, mod_perl is exactly like writing an Apache module, but in Perl. It's a lot closer to Java servlets than to PHP or ASP.
When used with mod_perl, Perl is fast enough for just about any web site. In fact, so is PHP, or Java.
Python is getting closer, but it's still not the fastest.
In most of the benchmarks I've seen, it's the slowest. Even so, it's probably fast enough.
you're right, it would be a cool nightmare to code a software like that in assembly
Anyway, Oracle just released migration tools for MySQL so they must know that SOMETHING is up
Could it be that lots of people have found that MySQL is not up to the task, so they are switching to Oracle?
Well, I agree about the C++ and the optimized compiler.
Even if they did code in assembly, it doesn't mean that the code will run any faster than the C++ unless they have some seriously hard core assembly programmers.
Most programmers just won't know all of the little tricks that the compiler writers will have used to optimize the output, and the compiler will be tweaked over time with improvements, where the assembly programmer will still be using the same techniques and macros that he has always known.
It's easy to use, even for the web people who often don't have a lot of programming experience.
It has a great C API, so that you can write the really speed critical components in C, and call them from your Tcl code.
http://www.welton.it/davidw/
Actually, I'm writing an application right now in Java. We're delivering content via JSP, with a distributed Java backend (using RMI). We're only going to have a couple hundred operators hitting this app so performance isn't a huge issue.
However, our developement/testing/production environments are NT+Sun/Sun/HP. Java's portability saves us more headaches than everything else combined causes.
Considering the poster probably has a bit more control over his environments and he's talking a two orders of magnitude larger user base, I wouldn't bother with Java at all.
Stick with the HTTP protocol so you don't have to develop a client and go with C or C++ for the server.
You're right about tag libraries they really do make the whole JSP thing worthwhile. There is a good introduction in the Wrox JSP book available here.
Are you using this with swing or awt? cgi stuff would not use any of these classes and i suspect/hope that using it with text only stuff would be less buggy.
love is just extroverted narcissism
C/C++ would probably be the best for overall speed, just because it is fully compiled and could run like lightning, provided that there weren't any memory leaks or the like. Perl would also be a good choice, just because of it's extremely large abilities. ASP/ColdFusion/PerlScript is always bad because they are so damned slow. We use ASP at work, but I would much rather use Perl/PHP to do the same thing.
Glen
Track your fuel economy
note: I'm hardly a 31337 h8x0r, so I may well be missing something... I'm only asking that the more 31337 enlighten me, and anyone else who may be reading ;)
[Man, what a bitch it would be to try to code in Magyar...]
Man, at first you said "Marglar" - now THAT would be a bitch!!
#!/usr/bin/marglar ;
$marglar = "Marglar!";
marglar "Hello there. What is your marglar?\n";
$you =
marglar($you);
marglar "Hello, $you. Marglar to $marglar.\n";
(Slightly obscure South Park reference...)
(sorry, someone pointed a gun to my head and made me repost this for you... on second though, maybe that wasn't really a gun... ewwwww!)
---
There is much cruelty in the universe, John.
Yeah, we seem to have the tour map.
Yep, agree 100% that the site sucks... we're working on it and I can definitely assure you that the new site is free from flash and other stuff like that... The site is being re-done from scratch and will be up in a week or two.
You should try to chose a development environment and platform that will enable you to scale up to your required user population, and then if higher performance is required then invest more $$ in hardware/bandwidth.
For example, if your chosen backend server can swamp a T1 without breaking into a sweat then the obvious is to buy more bandwidth. On the other hand if you become CPU bound, you should be able to add more CPU power and your environment should simply extend to take advantage of it.
In my experience, if you architect the server-side correctly the network will always be the limiting factor to performance.
<shameless plug> The company I work for has benchmarked very large user systems and have quite a bit of experience with this... </shameless plug>
goddammit.
Sean
Um, not to be biased or anything, but I should trust the benchmarking results on the _vendor's_ site?
If that's true, Microsloth has benchmarks that says that ASP is the fastest language and they have a bridge to sell for only 2 dollars.
Ever lovable and always scrappy,
Ever lovable and always scrappy,
kawaii
LOL...
Carousel is a lie!
Carousel is a lie!
Better yet, design your own microprocessor for the game and write the entire thing in microcode.
-----
Oh absolutely...the development, as all good microcode/microprocessor programmers/designers know, should be done with a wire wrap kit, or better yet, wires and vacuum tubes. But once the product is developed and debugged it would be entirely inefficient to wirewrap every unit sold. For this the industry standard production techniques should be used (probably not circuit board etching, though, since we are producing chips). Of course, maybe this is what you meant. If so, my apologies.
-----
First off, I just to need to reiterated that RISC stands for (Reduced Instruction) set not (Reduced Instruction set).
Reduced Instruction Set Computer, oops?
With CISC complex instruction, often 1 long to execute instructive can get into the chip, and halt everything until it finishes. I believe this is why overclockers get burned. But with RISC commands, the chip is able to quickly handle each one, and on most modern achitectures it is able to handle 3-4 RISC commands at the same time.
1 CISC instruction functions as several RISC instructions, so that's not relevant. As for handling several instructions at the same time, the same applies for CISC (thats a cpu specific thing). With MMX and SSE in the Pentium family, you can do multiple mathematical operations simulatenously. Also, it's not like x86 has only one pipeline, like you're making it out to be.
I believe the chip dymanically assumes and tries to optimize the best use of those 40 from 8 by looking ahead, but it *might* occur in the compiler, but that seems less likely. Either way, the coder is only able to access the 8(AIX, BIX... etc...)
It's the compilers job to make optimal use of the reigisters... Anyway, AIX is a register? Could have sworn it was something else and that you really meant EAX, EBX, etc...
If the same register is being used for many commands, but the output of one command is not needed for a future command that uses the same register, the chip will switch the future command to use a different register. So mastery of assembly does not guarentee more faster programs, one also needs to know what chip they are working on, and how it will attempt to optimize the code.
The compiler does such optimizations, it decides what the registers are going to be used for, unless you have some super intelligent chip with a built in optimizing compiler. Mastery of assembly DOES guarantee faster programs, if one doesn't know how to optimize for the chip well they are working on, obviously they don't have mastery of it. You speak as if the chip as if it were an optmizing compiler, it's not. It does try to do things to speed things up, like with branch prediction, but not to the extent you're implying. Anyway, someone with mastery of assembly will write code so that the optimizations the chip can do, will work out well (i.e. write it so the branch prediction part of it does predict correctly [no miss!])..
pico (walk away slowly)
Java crap is slow as hell just hit any jsp site to see how bad. even poorly written perl or python could hands down smoke jsp. Hell I bet even cold fusion can beat that junk
Got Code?
--
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Based on what I've learned working with databases the rough ranking for performance impact is something like:
The last two are probably interchangable.
If you have your application on a separate box from your database then it might be a good investment to have a second network card in each to hook them directly together, maybe even go for a fiber link if you've got the money. If your database supports stored procedures it would probably be worth moving some of the processing within the database to minimise the amount of data being sent over the network.
Disk speed is particularly important in databases. If you're doing a lot more lookups than inserts/updates then you'll probably want to have lots of indexes, if you're doing more inserts/updates then you want to keep the number of indexes to a minimum. If possible you want to have indexes on a separate disk (separate disk controller if possible) to your tables. If performance is important avoid RAID 5, go for RAID0+1 (Striping and Mirroring). Loads of memory can help with disk speed bottle necks as it means that you can avoid swapping and paging and that you can have big database and disk caches so avoiding unnecessary disk reads and allowing writes to be scheduled for lulls. If your OS support asynchronous writes consider enabling that. If disk speed is your problem then choosing a language that lets you avoid dynamically loaded modules can be helpful (ideally you want to load each module once then leave it pinned in memory).
Processor speed is really the only one that links the language itself. Obviously anything that needs to be interpreted will take more cycles than something that will run native. C/C++ can be remarkably portable so long as you avoid implementation specific calls. Try to keep such calls to a minimum (only use them when you have to or where there is a significant performance advantage) and when you do use them try to keep them to isolated functions. Hopefully when you come to move to a different platform you'll just have to make some minor edits then recompile.
Not a lot you can do about Memory or Bus speed other than move to a different architecture.
Stephen
"Don't write down to your readers, the only people less intelligent than you can't read" - Sign on Newspaper Office Wall
As with everything though, it's a trade-off. Keeping the database workload down is no good if that means the database has to return you 10000 rows instead of 2. That's a lot of data to shift around (between processes and possibly across a network) and it's not fast to move it around. With a couple of indexes and a join, the database can avoid looking through the data at all except for the couple of rows you want.
Answering the poster's question is impossible, although my piece of anecdotal evidence is that a database-heavy web application performs around 2-3 times faster implemented with JSP for presentation and standard Java classes for business logic and database lookup than it did with page-centric PHP. Cacheing the results of slow-changing database queries is a very useful speed-up too.
Dude, please get a fucking clue before you post drivel.
RDBMS are almost like mini-operating systems by themselves. Oracle, Informix, Sybase, etc all manage disks themselves and allow the tuning of various threads and data structures for performance.
MySQL is great for some limited applications, it gives a fast, convienient interface to large amounts of data with minimal training or operational costs. MySQL is especially useful for databases with a low read/write ratio.
The big commercial databases have alot of advantages, mainly in the area of data integrity. No 'free' database is able to guarantee the integrity of your data. MySQL and Postgre (as of the last time i used it) are not capable of performing online backup or parallel online-backups.
A large multi-user system requires a 'real' database. Period.
Conformity is the jailer of freedom and enemy of growth. -JFK
We've got loads of them running, and didn't need to pay a dime in licensing fees.
wow...that's just like our copies of Visual Studio and Office!!!
First, read this slash about 4 Web Scripting Languages compared. It refers to a ZDNET article which benchmarked and came up with the following results:
PHP: 47pps
ASP: 43pps
CF: 29pps
JSP: 13pps
(pps = pages per second).
The JSP was done with Tomcat, which is apparently not the fastest implementation.
The real interesting thing is, the test was done before the advent of caching technology for PHP. Since then, the Zend Cache and the APC Cache have been released. Now, sit back for a second.
I played around with these babies. Generally, the APC cache doubled my pps, and the Zend Cache QUADRUPLED my pps. Other benchmarks posted on mailing lists showed comparable results. (Note that the tests were done on the same server with the same apps using ab - and of course the results weren't so good for particlulary db intensive pages). I am not shitting you about those results. The stuff flies as the cache stores the compiled object code and doesn't need to recompile on every pageview.
So, lets look at those results again and hypothetically extend them (just for shits and grins):
PHP+ZendCache: 198 pps
PHP+APC: 94 pps
PHP: 47pps
ASP: 43pps
CF: 29pps
JSP: 13pps
Not sure where mod_perl, C, or native servlets fit in there, but that's a pretty impressive showing by PHP.
g
Check out the Resin JSP/servlet engine - the authors claim it's faster than mod_perl and mod_php. If you're targeting Apache and you believe them, it might be worth looking at.
I've installed it (painlessly) on IIS and Apache and played with it, no real performance measurements but it seemed pretty fast.
Read my keyboard review.
Just a small comment about RISC: in the lower-end RISC computers, there is no hardware to resolve resource collisions or perform memory timing -- that's done by the compiler at code generation time. If you are stupid enough to try to use a register before it's been filled, that's your tough luck. Ditto if you do a memory access and you access the data register too soon, or get "out of sync" with the memory clock.
CISC machines hide these details.
JSP is inherently slow, and taxing on a system (read you need an expensive system). ASP on Linux, I am very wary about because most people automatically associate ASP with M$ IIS/SQL Server. Perl has good speed on any system, and it is easily integrated into an Apache MySQL system. Then again if you are doing Apache/MySQL why not PHP?
...see you auntie
If you want speed....You can pretty much eliminate any interpreted language (e.g. Tcl) and web script (e.g. PHP, ASP, ColdFusion).
Note that the version after Coldfusion 5 (Coldfusion NEO) will actually deliver compiled java code. The c-engine is completely being rewritten in java at the moment.
I finally apprecciated how wide spread the all your base meme is today. I was reading everyone's favorite right-wing rag "The New American" at school when I saw it on a fictitious placqard(I know i didn't spell that right) in a picture for an article about the McCain-Feingold campaign finance reform bill!
Numbers 31:17,18 Now kill all the boys. And kill every woman who has slept with a man,but save for yourselves every virg
Yeah but ASP-Javascript is really cool. Every Micrsoft basher always forgets that you can use Javascript with ASP. And if you code your modules correctly, it makes fo ran easy conversion to C/C++/Java at a later date.
I don't know about the internet, but the rule of thumb for TV is: if >20% of a group (a school class, an office...) has seen the first part of a series the eiever mass will increase else it will decrease (I said rule of thumb).
...
With the internet and everyone having email the equivalece would probably be something about how many % will forward it to friends
-chs
Ahem...
When I started all we had was one abacus for the entire crew.
FYI, Anything that mysql currently "lacks" will probably show up at some point. Until then, I can get a mysql server up and running in under 5 minutes. Anybody out there set up and configure Oracle in that amount of time lately? If you want RAD, mysql/PHP/apache is the way to go. Anyway, Oracle just released migration tools for MySQL so they must know that SOMETHING is up.
I have not seen a scripting language run faster than php. The functionality "out of the tarball" with this language is almost ludicrous. On the fly PDF and image creation, XML capabilities, tons more (check out http://www.php.net). PHP can spawn ANY non-interactive process written in whatever language you like and get the output from a redirected file (or have the process dump it to the DB).
PHP is one badass swiss army knife.
# face411 # # writing the bash script to suck your soul #
But for web scenarios it is UNPARALELLED because of it's speed IMO. Sure, you don't have row-locking, but you can at least develop your app without paying $$ for a commercial DB license. It seems the common definition of "mature" is that for something to be mature, it needs to suck up 90% of your machine's resources even when there is nobody connected to the DB. It's about as hard as changing a light bulb to connect PHP to another DB when the time comes. If you develop using MySQL, you won't even have to change your SQL much (if at all).
# face411 # # writing the bash script to suck your soul #
On that note: Is there anybody alive that can actually decipher a Java Run Time Error?
# face411 # # writing the bash script to suck your soul #
Um... Two words
Forked Processes!
# face411 # # writing the bash script to suck your soul #
Actually, Tcl might be just the ticket -- when it's embedded in the server itself and not run as CGI or fast-CGI.
These poor fellows need to look at jettisoning Apache altogether in favor of aolserver (www.aolserver.com), which provides speed, scalability, choice of language (C and Tcl), and choice of database backends.
Sorry, I just hate these "my language is better than your language" arguments. Anything can be coded for speed and anything can be coded to suck.
It's not Perl that makes Perl based sites suck -- it's the fact that CGI scripts spawn a new process every time they are called. More advanced server side scripting languages use a single process to handle requests. I'd personally like to see a Perl CGI gateway that doesn't have to spawn a new interpreter everytime.
Frankly, I think ASM will have the same problems that you'd see with Perl -- the overhead is not execution of the script, it's the initial setup time for each request.
Remember, if high performance was just a matter of switching to a faster language, we'd all be using that faster language. Usually it's something else that makes it fast or slow.
--brian
Ha!
Here is a typical letter, .
3#15#2001
intmain Barat,
Intmain baratom++ [hung. for !--helps against lameness filter also] Hogy vagy+?+?+? En jol; [hungarian for
" is hungarian for a comma, >> and <<, as in French, for quotations]. En nagyon jol vagyok "koszonom" de nem ertek egy dolgot a leveledbol; Hiszen "irod" >>nem ertem a leveledet<< "holott en nem kuldtem egyaltalan neked levelet; e-mellet "ha kuldtem volna" meg vagyok gyozve hogy ertheto lett volna++;
Egyelore ennyit; haliho+
This letter, copied literally, does not illustrate the hungarian use of { and } for paranthesis before large clauses and longer paragraphs.
Other aspects of Hungarian orthography are not of interst.
Have you seen any benchmarks for VP? I didn't see any at www.amiga.com, just an interview and a tutorial on it with fairly vague speed claims.
"Be thankful you are not my student. You would not get a high grade for such a design
"Homo sum: humani nil a me alienum puto"
(I am a man: nothing human is alien to me)
My only political goal is to see to it that no political party achieves its goals.
Oh, and did I mention that it's interpreted (yes I know it is also compiled too, that's not the point here.) Interpreted languages are slow. Think BASIC.
"Any connection between your reality and mine is purely coincidental." -Slashdot
Elgon
PICO FOREVER!!! (hehehe)
it is the slowest
The surest way to make a monkey of a man is to quote him. --Robert Benchley
Seriously, I have been very happy with PHP. It has proven easy to maintain and code as well as a stellar performer where dynamic content is concerned. Read more at http://www.php.net.
LedgerSMB: Open source Accounting/ERP
Tim
Tim
I think we all know that assembly is the fastest. Unfortunately that is probably not the answer you were looking for, so you must have gotten the question wrong. Either that or you're just a troll.
When VPNs are outlawed, only outlaws have VPNs.
Somebody mod up the post I am replying to. He's got links to tests and actual numbers and his own testing as well. This is good. I would love to see this study re-done using JRun for the Java implementation and Zend for PHP. I think both technologies would come out better. But clearly, this disproves some other posts here saying that PHP isn't so fast. Surprising.
My Greasemonkey scripts for Digg &
By adding "EJB" to the mix, you're limiting them to paid software (unless someone can tell me about an Open Source EJB container?). As far as Servlet environments go, if you're looking for speed, make sure you use Apache/JServ, not Jakarta Tomcat. Tomcat supports newer specs, but JServ is a tried and true fast servlet environment. Despite Java's general sluggishness, on good hardware it will get the job done.
reech bee-yond ur clip-0n
Sure it can (in PHP, anyway). Just use a memory-based session handler (rather than the default disk-based one) and keep all the user-specific information there.
As an added bonus, you'll have the entire application developed while the Java people are still waiting for all the floating windows on their IDE to come up.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
Basically, I agree with everything. Two comments here:
- If you REALLY need speed, don't even use a database. Use plain files with your own format optimized for the queries you will make.
- If you are going to implement your own web server (this will probably be my choice), try SGI's State Threads Library.
http://oss.sgi.com/projects/state-threads/
It's really fast and easy to use.
Hope that helps.
I've taken a look at the WebLogic .java file output from JSPs, and there really isn't anything in there which is glaringly inefficient, except for the fact that every output gets run through some munging method.
But, your point stands that if you are coding for performance, you better fully understand what the JSP engine is doing.
I would like to add my two cents... At my last place of work, we had a very nice alpha (6 64bit 700 mhz processors, 4 GB ram, 4tb of disk space) - it hauled. It ran True64 (Compaq's unix). The only VM available for it was FastVM (also written by Compaq). They claimed it to be the fastest around. Compaq claimed it compiled the code down to machine code before running it. I can't tell you how slow this thing was. I was embaressed for java, until I realized it was just the FastVM. The same programs would run three times as fast on my 450mhz PC (running hotspot). Now, you have to take this with a grain of salt. I didn't do any valid testing. I just ran our programs on both machines, and my PC smoked the alpha. I understand Compaq was porting hotspot for the True64 os. So this shouldn't be a problem anymore.
Strange idea of heaven. JSPs are possibly the *slowest* platform I have ever seen. Development is slow, deployment is slow, and execution is slow. I've been developing JSPs and servlets for 2 years using VisualAge and WebSphere, and you do not want to use these products on anything that needs to be fast. Sure, they might be scalable, but only because they start out so slow that they can't get much slower under heavy load. Look elsewhere for speed.
-- Give me ambiguity or give me something else!
He's got 2 good links.
spambait e-mail
my web site artistcorner.tv hip-hop news
please help me make it better
if you see me, smile and say hello.
what i can suggest, from playing around with multiple languages (jsp, perl, python, php) on FreeBSD/apache, is to use php optimized with zend's optimizer.... the speed boost is about 15%, and if apache is configured correctly, or even patched for speed, php will outperform any other similarly prepared language.
--
Darn right. I have done just that, and it is far better solution than ASP+VB.
Truthly Mysql does not scale. Mysql fails under heavy load using large tables (600k to 1M+ rows).
What is pirate software? Software for inventory of stolen treasure?
Amiga's virtual processor language is portable and usally faster than native apps. I know you won't believe me, so check it out for yourself - http://www.amiga.com.
Great article... I think Java has probably improved with 1.3, but hey, this is on Solaris, after all... so, I guess its fair.. I'd tend to think that Perl 5.6 is slightly faster than 5.005xx as well... no reason really.. just 'feel' like its running faster ;o)
but on the whole, a very interesting article.. but this won't make the Java language purists budge, even after they see it... :o)
i was going to suggest postgre - i agree that mysql isn't really mature as far as dbms go.
A: None. The Universe spins the bulb, and the Zen master merely stays out of the way.
Ok, well, let me use a better example then. I began using java with powerj. It will drop a lot of code in for you and the code is very inefficient, for instance it uses strings instead of string buffers in an append to create a string situation. Since a string re-creates every time, the overhead is significantly different. I assume ( note: i have not looked at compiled JSP's) that some of the things that JSP's do are equally as inefficient. (and i have read a confirmation of that somewhere too, but that was 2 years or so ago, and i dont rem the source:)
-CrackElf
"Blake is an idealist, Jenna. He cannot afford to think." - Kerr Avon, Star One, Blakes 7
Yes, that is true, but, because of the 'compiling' in which some canned code is used, rather than instance specific code, you get a product that is marginally less efficient. Of course it is possible to prog a servlet badly, and create more overhead.
Like, when you compile c++ into machine language, the compiler is replacing your commands with a series of machine language commands. The series of commands is not as efficient and fast as programming in assembly even though they are all technically 'machine language' once compiled.
-CrackElf
"Blake is an idealist, Jenna. He cannot afford to think." - Kerr Avon, Star One, Blakes 7
a jit compiler is just a gimmick, i saw benchmarks in the computer shopper (confirmed by someone doing a thesis related to efficiency / speed in java) that showed that if you take the benchmark from the begriming of the jit compiler's run, not from the begriming of the program's execution after the jit compiler has ended, the times are about the same in your average program (not iterative intensive programs)
-CrackElf
"Blake is an idealist, Jenna. He cannot afford to think." - Kerr Avon, Star One, Blakes 7
Point. I conceed. :)
-CrackElf
"Blake is an idealist, Jenna. He cannot afford to think." - Kerr Avon, Star One, Blakes 7
On a hunch ... I would guess that your DB server is the bottleneck. If you've already coded in C, you're not going to get much faster than that (certainly not an interpreted language like perl, php or JAVA)
Consider (if possible) ditching the DB server altogether and going with some other type of shared storage. Also, look through your C code and consider optimizing it.
I've actually been working on a game that's similar to what you describe, using php as the UI, MySQL as the data server and C for the event processing routines. The major bottleneck is the MySQL server, and I've been toying with writing some sort of daemon to serve out the data to the other programs to replace MySQL. SQL is very fast and it's great (the flexibility and rapid development can't be beat) but it's just not fast enough for a game like that under heavy load.
Developing your own data engine will be time consuming, but if you MUST have the speed, that's the only way you'll get it.
Unless, of course, you just buy tremendiously powerful servers. Try moving the DB server onto it's own machine with REALLY FAST raid drives and tons of RAM. That might speed things up enough.
Check out This page for some benchmarks on web languages. The results are not what you'd expect from a perl page...
Where's my lobbyist? Right here.
I would reccoment doing it in C or C++ because they're both fast and much easier to maintain than assembly. (which will always be faster) Some other languages would be easier to program in but if you just looking for speed go with C/C++.
one thing i can tell you is you got to be free
A regular fireman has a building in flames, then he called the super-math-man...
The super-math-man did his math things and told the fireman that he would need exactly 1569 liters of water to stop the flames.
Then he called the Cmdr-physics...
The Cmdr-physics did his physics and math things and told the fireman that he wolud need aproxim. 1600 liters of water to stop flames.
Then he called the Captain-enginneer...
The Captain-engineer took a flight all over the place and told the fireman that 8000 liter will be enough.
Then he called the All-mighty-statistic...
The All-mighty-statistic asked him: "How much Water do you want to spend?"
So, be carefull with statistics. And keep using C/C++!
-=-=-=-=
I know life isn't fair, but why can't it ever be un-fair in MY favor!?
I have been using orion server since it was beta 0.52, and trust me, the benchmarks are real, if not a bit conservative. Most of the benchmarks he has gotten over the years are from users that hae tested and then compared to his own. When working for ELN(the isp) we did a ton of benchmarks between orion using servlet/JSP and half a dozen other servers including AOL server + TCL, Apache + CGI/Perl/JSP/Servlet through Jrun, IIS with ASP and orion with Jsp/Servlet. Orion consistently beat them hands down, and it is *cheap* for what you get. Ok, so that must sound like a sales pitch but it's very true.
I get the impression most /. users have used Java.
I think it's the best language to program in, and it isn't slow.
check out http://www.aceshardware.com/Spades/read.php?articl e_id=153
for some fast 3D java fun, check out http://leaf3.com/3d/RealSpriteApplet.html
I obviously meant to say "most /. users *haven't* used java" ;-)
I know, how fast it runs. I wrote an HTTP server, and in its early versions file-sender was a constantly restarting CGI-like process, like in FTP. Performance significantly increased when I have switched to process pool model, so I have added module interface that allows modules to have their own process pools when necessary, isolating modules from each other.
Contrary to the popular belief, there indeed is no God.
As a module, of course -- either Apache (native or through or fastcgi) or my fhttpd (that I wrote with protocol that looks a bit similar to fastcgi, but allows more complex processing models).
Contrary to the popular belief, there indeed is no God.
May I suggest using a shell interpreter of some type? I like bash, but csh may be your calling since you guys have some C/C++ background. Forget the PHP/Perl/Python thing. Just use the URL and/or cookies to store variables! No need for a database, either! I say make the client do all the work. :-D
-----
If Bill Gates had a nickel for every time Windows crashed...
ed is the standard text editor, after all.
Out of curiousity, were you trying to write monolithic applications using thousands of line of VBScript within ASP?
Or were you doing the intelligent thing, writing all your logic into compiled VB/VC components configured within MTS and then called by a few dozen lines of ASP code?
There's more to it than that, but...
Can you say DUH?
Actually, both mod_perl (available from ActiveState) and mod_php (as of PGP version 4+) are available for Win32 now.
Check out ActiveState's web site for the perl module, and php.net for the Win32 binary download.
Of course, it's been my experience that both run much better in a Unix environement.
Topher
Some people that call themselves the esperanto group use JSP and Corba.
Since we are joining database languages and Esperanto, I'll mention Visionyze's Esperant, a tool for generating database queries, but there are no promises of speed.
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
Yes, Java can be very fast, especially with some of the latest Hotspot JVMs. In fact Java can be faster than C++.
C is generally much faster than Java. C++ can be just as fast, providing you don't use certain constructs, such as virtual functions. If you do then you will be slower than Java on Hotspot.
Of course Assembler is the fastest if you concentrate on the coding (as others have pointed out). However, this becomes quickly infeasible if a group of programmers are working on the project. A good compiler is MUCH better to use. Hence you should just use assembler for bottlenecks (meaning that you're pretty much stuck with C/C++. Let's not get into JNI).
As for the framework, others have pointed out the cost of CGI. mod_almostanything will probably be faster than the tightest assembler (depending on the ratio of hits to the complexity of the task). For sheer invocation speed, you can't go past modules. That usually means Java or a scripting language, but there's nothing to prevent you from writing the program as a binary module.
So it's an engineering decision between trade-offs.
If speed outweighs everything, including complexity, development time, cross-platform issues, and cost, then I recommend building your own Apache module in C and optimising bottlenecks in assembler. If complexity, development time, corss-platform, etc, are still important, then I'd probably go with Java with a fast module, but I'd do some performance tests first.
All of these languages are great (including the scripting languages I haven't mentioned), but they need to be used where they are most appropriate.
Just my 2 bits worth.
http://openejb.exolab.org/ is an opensource EJB2.0 container.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
All told, if you pick a decent JSP/Servlet engine (JRun or Resin perform about 3x better than Tomcat), you'll find the JSPs run just a hair (about 10%) slower than the fastest dynamic page systems, mod_perl & mod_php. With the object oriented benefits of Java, and the ability to separate presentation logic from business logic using JSP tag libraries, JSP/Servlet engines are an excellent choice.
By the way, I wouldn't discount ASP+, either. While ASP has a lot of problems, ASP+ has learned from a lot of previous mistakes, as well as from all the benefits achieved from JSP/Servlets. Of course, it will tie you in to MS solutions (bad! bad!), but it's a very good piece of technology, none the less.
--Be human.
So you compile your app server with gcj? OK. So I suppose you need an open-source app server. Try JBoss, or Enhydra. Ooops. They both depend upon libraries that gcj doesn't support.
.so libraries. Hmmm. Why you're at it, why don't you simply rewrite an HTTP server that loads these mythical .so servlets? Your suggestion is ridiculous.
OK. Let's say you get past that hurdle. So now you want to rework the servlet framework so that they are compatible with
Apps can't tell if they're running natively vs. running in a VM. But the servlet spec depends upon a dynamic class loader. And, lo and behold! gcj doesn't support that (a dynamic class loader is different than a shared archive, I'm afraid).
--Be human.
The link: JBoss.
Whoops.
-Hunter
RateVegas.com - Vegas Reviews
Excellent post, thank you. It's Insightful, Interesting, Informative, and Underrated!
Even assuming developers can even agree what a "reasonably intelligent" program is, I don't think most applications are reasonably intelligent, if for no other reason than design goals change.
For example, what they have right now may have been a great design if it was intended for a small audience. Small, simple and fast. But if the goal shifts, all of the sudden the current design is no longer right, even though it's still "reasonably intelligent".
Even assuming two similar designs, the language doesn't make that big of a difference. Even going from the slowest to the fastest is only a factor of two or three. And if it's only a factor of two or three generally the effort is better spend on hardware, which speeds up everything and not just one application.
We live in an age of where orders of magnitude growth is common. This will change, but until then we have to plan for incredible growth and a simple language change alone isn't going to cut it.
To make up for my transgression, and horrible editing in my post, I'll add my few:
* We're running a site with a few million hits per day, and we're considering switching from Apache to IIS because we heard it was faster. Thoughts?
* Should be move from BSD to Linux because we can by CDs at our local drug store?
* Bruce Perens or Natalie Portman?
* What's the better breakfast cereal: Hot grits or Glorious MEEEPT?
put the database and web server on different machines. then monitor which one get's more load.
You will also wan't to monitor the amount of traffic
between database and web server, in case you are
"selecting too much" and prosessing too much in the cgi.
signatures pending - ansa@kos.to - (dont mail there)
Umm, I think you're missing Sheldon's point. He's not really saying "use good design", he's saying "know your design first". This is vital when determining what language to code your program in.
Chapter 3 of The Practice of Programming by Brain W. Kernighan and Rob Pike is devouted to exactly this kind of situation. Knowing how your project is/will be structured can help you choose the right language. This can also lead to shorter, crisper programs and more understandable code. Why write a simple one-line regexp in Perl when you can write the same thing in a few hundred lines of C?
A program designed well but written in the wrong language can run horribly slowly. The same is true if you're using a language that you're not very familiar with. Use a language you know, and use a language which fits the design of your program. Taking these two things into account, I feel, yields the best results.
So, I think the best solution comes when you add your comment with Sheldon's. Given two reasonably designed programs, the choice of the language makes a huge difference in the speed of the resulting application.
---
---
"Of course, that's just my opinion. I could be wrong." --Dennis Miller
JSP's are pretty robust, but slower than pure servlets (which are also robust)
????
JSPs are compiled into servlets. Admittedly, they may be slower than intentionally-coded servlets, but after the first call, they are servlets.
We have an application constructed in a similar fashion: JSP/Servlet in the presentation tier, custom appserver for object persistence and business logic at the backend, talking to Oracle. Under load, the cpu profile was 70%/25%/5%.
Apparently, all the string manipulation in the presentation layer (parsing requests and generating responses) had a much higher resource requirement than the pure-object or database components. Oracle wasn't even sweating, but we've worked hard not to make it do so, given the expense of JDBC.
The only problem with this is that you need to deploy at least two maybe more languages. For the ASP pages you need to write jscript or vbscript and for you com objects you need to write them in C/C++ and then deploy them on MTS. You are most likely going to need two teams to do this project.
Using Java or Mod_PERL you could do it all in one language and save the cost of the other team.
War is necrophilia.
I just wanted to point out that..
You can write loadable modules for php in C. this gives you tremendous advantage of native C speed while using a scriptable interface with a very rapid developement cycle. The functions you write in C will be visible to the scripter like any other PHP native function. Combine this with the built in database pooling and you got a killer solution.
If the PHP scenario is not scenario is not scalable go to webobjects. It's also a very roubust well tested easy to develop environment that handles scalibility for you. By using objective C you get compiled speed with a framework where all the hard work has been done for you.
As long as you are thinking outside the box consider Klyx or Delphi. Go talk to the astatech folks and they will sell you the middleware from hell for a dirt cheap price. This thing truly rocks (I am not associated with them in any way just a happy customer). You get RAD developement, native compilation, great database support, ability to write apache modules, a killer IDE and debugger. Really now what else could you ask for.
War is necrophilia.
"With CISC complex instruction, often 1 long to execute instructive can get into the chip, and halt everything until it finishes."
There are CISC machines with ILP. Pentiums have 2 pipes, and Athlons have (IIRC) 5.
"Either way, the coder is only able to access the 8(AIX,BIX... etc...)"
That's EAX, EBX, etc. But, there are more available: mm0-mm7 (which are really the floating point registers), and xmm0-xmm7, which are 128-bit registers for SSE and SSE2.
Become a FSF associate member before the low #s are used
So if everyone really knows what they're doing (cross fingers), go with Perl, because you cannot get that much expressiveness in any other language. If you think your development skills would benefit from additional structure, go with C++.
Generally good advice. But this is a special case.
The questioner already has working code, and wants to recode it in another language to speed it up and perhaps "iron" it into cleaner form for future enhancements.
In such a situation you can inherit much of the organization and concentrate on speed. Porting to a language that's enough different than the original to bring your attention to things as you port (rather than making a mechanical translation) but not so different that you have to totally reorganize or implement a LOT of of replacements for language builtins will probably give you the cleanest result. Or if you're already in the likely fastest target language, sit back and look over the existing organization to see what can be improved.
C/C++ tends to be the fastest in those enviornments where it's appropriate, and IF you can find the right stuff in the standard libraries/class libraries you probably won't have to implement a lot of replacements. Let's assume for the moment it would be a good choice. Since this is a port for speed, it would be a good time to come to a real understanding of the underpinnings of the language, so you can squeeze the most out of it.
But before you dig in, try instrumenting the existing system and find out where its bottlenecks are. You may find the real problem isn't the language, but some other aspect (like API delays or database time). If that's where your time consumption or latencies are, you'll have to fix or replace them to get your improvement anyhow. If the bottlenecks aren't inherent in the existing language (neither the language itself or its API requirements), you might find you can fix them and leave the bulk of the code just as it is.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Were you lucky enough that when you were finished you got to dump it to one of those comically large 8" floppy disks? Or did you have to output your results to paper tape?
_____________
I don't want free as in beer. I just want free beer.
I have a question: how do you test the speed of the script vs the database vs the web server?
The main problem I have is knowing what the load looks like. Should I just pull back pages as fast as possible and measure CPU use?
To "ed" simply reply "ex"
;-)
That way you get all the vi people on your side by default as well.
"I may not have morals, but I have standards."
"I may not have morals, but I have standards."
mod_perl and mod_php are most likely going to be your optimal solutions. They are very well optimized for large performances and the retain the code in memory for faster execution. In terms of perl, mod_perl is MUCH faster then FastCGI but there is a larger memory requirement. mod_php is IMHO the better way of going but then again, mod_php is only available on the unix platforms which defeat your cross-platform desires (I'm not sure if mod_perl is on win32 boxes or not). PHP alone is not capable of handling the demands that you are talking about but because of the way that mod_php caches and retains in memory the php scripts it is also a faster solution and you are having to make less requests to the harddrive which cause the minimal but neccessary speed increases. However, your overall best bet is to do some kind of content distributing and pushing the contents closer to the users regionally and/or server clustering is probably a must.
dont forget that zend costs in a commercial environment. that is where the speed lies with php. i would say write the whole thing in c and set it up as an apache mod. a good book is 'writing apache modules in perl and c', stein & maceachern, published by o'reilly. good luck.
The question though is analogous to a boxer wanting to know what gloves to use to win boxing matches. Maybe there's an advantage to lighter (or heavier) gloves, or a specific stitching, or the leather used or whatever, but the fact that the boxer asked the question suggests that maybe they don't know they should be landing more punches.
So, the advice "use good design" is excellent. It's a tactful way of suggesting that the code they're using isn't all that crucial. Moving to a 5 figure user base (and congratulations to the article author) requires a better design, of which a production plan (of which language choice is just a part) is just a part. I think the best part of the advice given is that it doesn't sound as much like chiding a fledgling as it probably should.
IP is just rude.
Is there any torture so subl
OK, maybe an exaggeration. Programming in straight machine code will give you the fastest and tightest code...when you finish in 2007!
C is probably the best compromise, but design is crucial--go read "Mastering Algorithms with Perl" or something similar to remind you how important GOOD coding for the situation is, rather than concentrating on the language.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Probably the highest performance architecture for an all-dynamic-content site is a very small, simple, single-process httpd (say based on thttpd), which connects (via sockets, shared memory, or fd-passing) to one or more persistant server process(es) dedicated to your task (probably written in C).
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
In the last 6 months or so, eweek had a shootout between scripting languages...php spit out 61 pages per second, i believe, putting it on top in the speed category, above asp and jsp. can't seem to find the article on their site tho...
More matters than just language. If you were running on an NT/2000 machine you would be best off using either ASP/COM or ASP.Net. (crippleware anyone?) But being on a *nix platform, you would probably be best off going with a Java servlet solution.t ml
Java and the J2EE not inherently any faster than any other technology, but has a huge advantage because of vendor support. Everyone's scrambling over eachother to provide the best and fastest implementation of the J2EE platform, and the results are trickling down to free servers.
A good example would be the Orion J2EE server, which if benchmarks are to be believed is far and away the fastest solution. Find it at: www.orionserver.com
I use it myself, and can vouch for ease of use and speed, though I haven't done any benchmarking.
Check out some amazing benchmarking figures for it at: http://www.orionserver.com/benchmarks/benchmark.h
I feel so in awe of your grasp of logic!
You'd have to be stupid, then. Perhaps you aren't stupid enough!
First off, I just to need to reiterated that RISC stands for (Reduced Instruction) set not (Reduced Instruction set). The instructions are quick to execute. With CISC complex instruction, often 1 long to execute instructive can get into the chip, and halt everything until it finishes. I believe this is why overclockers get burned. But with RISC commands, the chip is able to quickly handle each one, and on most modern achitectures it is able to handle 3-4 RISC commands at the same time. It is able to re-order some of the assembly commands during runtime to maximize the number of things going on at once. Additionally, it is also able to optimize register allocation.
I was recently told that the PII chip has 40 registers not 8. I believe the chip dymanically assumes and tries to optimize the best use of those 40 from 8 by looking ahead, but it *might* occur in the compiler, but that seems less likely. Either way, the coder is only able to access the 8(AIX, BIX... etc...)
If the same register is being used for many commands, but the output of one command is not needed for a future command that uses the same register, the chip will switch the future command to use a different register. So mastery of assembly does not guarentee more faster programs, one also needs to know what chip they are working on, and how it will attempt to optimize the code.
Yes, I'm offtopic but compilers are cool. Now for a lil on topic stuff. I come from the school that when hitting web pages the database hit tends to be the thing that slows things down. The solution I have used to solve this problem is to load the database in memory as much as possible. Max max max out the ram on yer server cluster, and fill up those javabeans. Naturally, with a large game you can't keep everything in memory, but just by keeping the most frequently used things in memory you should be able to increase performs. Once somebody logs in, store their relevant info in a Bean. I have been brainwashed into using Java as the solution, but I'm sure you could do it in another language like C++ or Perl. But I don't think it can be done in a scripting language such as PHP, ASP or Python.
Worst episode ever.
I could not agree more. I just spent 18 months developing high-speed online database access using binary CGI (not a script, but an executable). There are so many varieties of options available out there. After my first dev cycle I was very distracted by trying to find something faster. Spent a total of about four months trying to find better language/system/drag-n-drop solution. I found that they all have strengths and weeknesses. In the process I wound up completely redesigning my original CGI in it's original C and the end result came out way better than the other options could have done. It's way more than ten times faster after a good redesign. My only regret is that I wasted four months chasing a red herring. Also, as a result of redesigning it, I am intimately familiar with the entire system now. I also designed it so it scales easily. Just get another box and another IP. It even registers itself with the DNS. I haven't even turned on compiler optimizations yet. I'll save that for a rainy day. And then I'll hand roll assembly if I have to panic. Which won't happen because of the scalability. Which brings me to a point that I'd like to contribute. I find that it makes me a lot more comfortable to know that my code has room to improve so I can get it when I need it. As opposed to,"there's no way I can make the system go any faster. I already have it optimized as much as it can be".
the speed solution is not to recode as a script, but to move the app from cgi to a loadable module.
-I like my women like I like my tea: green-
Here is a link to a pdf that has real performance comparisons between scripting languages and c/c++. It has productivity figures as well.
love is just extroverted narcissism
You can pretty much eliminate any interpreted language (e.g. Tcl) and web script (e.g. PHP, ASP, ColdFusion).
I wouldn't rule out interpreted languages, because you're not going to be doing any "heavy lifting" in them anyway.
For example, with ASP, the goal is to use ASP *only* for formatting and user-interface. All the "heavy lifting" (ie, computationally expensive stuff) should be done in another tier, written in precompiled COM components written in C/C++ or some other language. Sure, ASP is slow, but if it's only doing 1% of the total work you're okay. Also, it's a good way to separate interface and design from the game logic.
A similar strategy could be used with any interpreted language that generates web pages... Java, Cold Fusion, etc.
http://www.bootyproject.org
OtakuBooty.com: Smart, funny, sexy nerds.
[Man, what a bitch it would be to try to code in Magyar...]
<P>
Man, at first you said "Marglar" - now THAT would be a bitch!!<P>
<TT>
#!/usr/bin/marglar<BR>
$marglar = "Marglar!";<BR>
marglar "Hello there. What is your marglar?\n";<BR>
$you = <STDMARGLAR>;<BR>
marglar($you);<BR>
marglar "Hello, $you. Marglar to $marglar.\n";<BR>
</TT><P>(Slightly obscure South Park reference...)
Sean
I'm neither an expert on web development nor objective (I work for Borland). But this point needs to be amplified.
TheCorporal wants RAD, as long as it doesn't affect speed. Delphi is the Windows RAD tool, and it generates tiny, fast native executables. Its Linux sibling, Kylix, is also fast and has a particular emphasis on Apache support. Both products suport apps-as-shared-libraries, so you get the extra oomph of an in-process server.
Both have first rate database support, but plenty of Delphi programmers write non-database apps. I expect Kylix to be the same.
Oh yeah, and if you want fast web apps, you want Internet Direct, AKA Winshoes. Now open source, works with Delphi and Kylix. Naturally, it's on the Kylix CD.
You also get a fast change-and-test cycle. Both Delphi and Kylix use Pascal, a language that only takes one pass to compile. Plus the Borland Pascal compiler is the fastest on the block, being the current incarnation of the venerable Turbo Pascal compiler. So a Delphi/Kylix build is shockingly fast -- so fast that new users often think the compiler is simply broken.
If you can't live without mulitple inheritance and operator overloading, Borland C++Builder is the way to go. Same technology, but of course compiling C++ takes a lot more work! No, I can't tell you when the Linux version will be out.
I hear someone saying, "Yeah, but Borland won't be around in six months." I've been hearing that for 10 years! Enough already.
__________________
Compile it into apache if you want to break speed records. Create a apache module to run your stuff and compile it right in. It is not goig to run any faster than that.
Got Code?
heh.. when circumstances forced me to code on a windows box (not my choice), i used notepad.exe long enough to write my own primitive editor. then i used my new editor to make itself better. now i have a nice multi-document graphical editor with cut/copy/paste and find/replace with regexps.
---
What do you mean zend costs in a commercial environment? The underlying zend engine used by PHP is free! The zend cache product costs money, but is definitely not needed by PHP, and there are free open source alternatives to boot. PHP/Zend is most definitely free in commercial settings. We've got loads of them running, and didn't need to pay a dime in licensing fees.
creation science book
Having said that, it sounds like several languages would support your application, and different ones would be best implemented in different languages. A glue language with calling ability to other languages (C, C++) may be good for the central parts, and farm database work out to a database language (MySQL). This way, you can take advantage of speed gains in either domain (C++ speed optimizations for low-level execution, MySQL for quantum database improvements).
This will also force you to think about the design a little more, as well as the interfaces. With good interfaces, the implementation can thrash around a bit, but everyone can still be doing their work, and you can prototype a lot faster.
Of course, I haven't experienced your situation. Why don't you write the developers at Utopia, see what they use, and if they would change anything about their language of choice?
Lets not forget about fortran!.. Oh, you said for the web.. right.. *cough*.. Oh look, here comes my bus..
--------------------------------------
--------------------------------------
Vices - what I lack in originality, I make up for in volume.
I generally come up with a more efficient overall representation of the algorithm, and can do other optimisations based on extra knowledge, and the compiler comes up with a better way to use registers, etc.
The combined code is usually about 15% faster than either of the originals.
I agree, Java has to be a serious contender for your short list, the portability/platform independence will be a serious advantage longer term.
When you consider the convergence between STB's,Consoles and Web-Pad; Java is the only realistice platform for these, and medium term you'll get support for plenty of other client devices, for very-little or even no effort.
The ability to use the same language across the development, on the server side and a range of clients, will make resourcing the various elements of the system easier. All your Coders can work equally well on any of your tiers, Server, middle or Client.
Some will disagree claiming Java is too slow, however this is not really true, ( I use Java to implement an Interactive Digital TV service).
This is especially the case when compared with the realistic alternatives, particularly server side.
The very light-weight nature of Java threads make it highly responsive (low latency) compared to CGI processes. Add a decent JIT and this means it can even out-perform C/CGI.
Java skills are pretty common and increasing, (and look good for your CV :)
hell, do it in 0's and 1's....
REAL SOFTWARE NEEDS TO BE TESTED!!!
most software shops can't realistically develope in assembly. it's simply to difficult to trace bugs in the code, and there are too many ways for bad developers to shoot themselves in the foot. odds are that the percentage gain they'd get in performance from coding in assembly would be offset by the time/cost of writing the software.
Whatever it's written in, good design is most important anyway.
All being said and done, it sounds like you should write it in c++ with an optimized compiler for the best performance, although java servlets or a java server would be the easiest to write, and quicker to develop without losing too much performance.
A: None. The Universe spins the bulb, and the Zen master merely stays out of the way.
Errr, I have been coding in java for the last 2.5 yrs, and I have to say, java has some advantages, but it has some pretty serious drawbacks as well:
anytime use java, you loose speed. JSP's are pretty robust, but slower than pure servlets (which are also robust), applets (over the net) tend to be slow, because it takes an age and then some to download a medium sized applet, and EJB's (the last time I used them) were less than reliable.
the advantages of the design, implementation, deployment, and reusability / consistency are all valid.
-CrackElf
"Blake is an idealist, Jenna. He cannot afford to think." - Kerr Avon, Star One, Blakes 7
Bollicks. Java GUI runs like a 3 legged lame pig in mud, but java sever side code (which obviously does not need GUI in it) runs comparable in speed (if not fast in some cases) to c++ server side code. Plus it is easier/faster to code and maintain.
------------------------------------ There is no magic, only Onions Pug conDoin ----------------------
As of win32 I thought C++ was just as fast as Assembly.
OK, let me try again!
Java vs C
Java 3D applet
I hand-filed gears, sprockets, cogs and pistons for my own Babbage Difference Engine, arranged for shipping for thirteen metric tonnes of high-grade coal from China, and blew my own glass cooling jackets from Nova Scotia beach sand. The result is the fastest goddamned shopping cart program on the net.
Wheels and gears? Bah! I have ancient texts filled with speels and incantations to do my problems. Other answers can be found in tea leaves, wax, reading sticks tossed on the ground, or in tarot cards.
I concur. But you should point out that developer efficiency is a good thing as well. For rapid application development, he should seriously consider using a wire-wrap kit, rather than etching the circuit boards himself.
--
Breakfast served all day!
Assembly? Geez, kids these days. Back in my day, we entered machine code directly, entered in octal by toggling address and data switches on the front panel and hitting DEPOSIT NEXT.
Schwab
(Better mod this down; "Can You Top This?" cascades can get out of hand...)
(And no, I'm not kidding, I really did fiddle with IMSAI and Altair boxes...)
Editor, A1-AAA AmeriCaptions
See:
"An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl"
Kernighan and Pike's The Practice of Programming (reviewed here), especially chapter 7 on performance
This comparison (just popped up from a Google search).
Obvious advice: Measure your current system, find out where it's really spending it's time.
If programmer productivity is irrelevant, you'll be hard pressed to beat well-written C. (And if wishes were horses, beggars would fly.-)
Stupid job ads, weird spam, occasional insight at
And the people who do realize don't realize they are not addressing any performance bottlenecks by using it. Get over it, native compilation does not solve many Java performance problems. There's a reason for native compilers such as towerJ and gcj not being used that often: the performance gain is not that big and sometimes not even there!
Jilles
PHP is fast and runs on just about any platform. With the use of the ADODB abstraction layer, you can easily switch databases if needed instead of changing a ton of code. It has built in session management, but you can easily store your session data in your database, then you can just add identical servers as your load goes up, and you don't have to worry about connection persistence across servers, so it's extremely scalable.
If you add the Zend optimization engine, it's even faster if you're doing alot of loops and such.
Need Free Juniper/NetScreen Support? JuniperForum
There's a language called Moto that compiles directly into Apache C modules. If you cache your database calls properly, you can get supposedly get 1000's of hits per second. Probably not for everybody, but if you need extreme speed... you need it!
Well, it certainly makes for fast software development time when the entire program is:
But the firmware development and maintenance will take some time.Having spent 10 years developing software, let me assure you that your greatest speed gains come from the algorithm design, not the language used.
The best example I have is from 2 years ago when I worked for Motorola. I wrote a simulator that performed a large file with a real device on the other side. The simulator was also responisible for multithreading other tasks from the real device at the same time (although the program only used one unix thread to do this). We wrote our simulator in Perl and the actual device ran compiled C code.
It turned out that our interpretted Perl code sent packets to the C program so fast that the hardware running the C code crashed. We literally had to cripple our Perl code so it sent the data at a slower rate.
That said, I firmly believe that it's far more important to choose a language that best suits your development abilities and choose language speed second. C++ and Java are great languages if you want to be forced into object oriented development, and sometimes that's what you need. Personally I love perl, but learning how to write clean perl code is extremely difficult (though rewarding).
So if everyone really knows what they're doing (cross fingers), go with Perl, because you cannot get that much expressiveness in any other language. If you think your development skills would benefit from additional structure, go with C++.
-Ted
There was an article here on slashdot that compared four different scripting languages. From the standpoint of speed PHP came in first. PHP has a reputation of being the fastest web scripting language and, to be honest, is a joy to program in as well. If this is not enough speed Zend sells a PHP cache that will precompile all your pages to speed things up even more. I believe there is a free version of the PHP cache out there but I don't know it by name.
And before you use MySQL please read this. MySQL has a reputation of being the fastest open source database but it really can't scale like Postgres can.
If your tables are *huge* MySQL may not be :) Might be cheaper.
the best solution, not sure on performance
but it is something to check. Your language
is not the only thing you need to consider. You should also consider the DB engine and the server platform. Why recode when you can purchase more hardware?
Servlets are quick, well supported and popular.
-Moondog
* Is there any kind of text-mode visual editor on unix ?
Must resist... must resist... Ahh, to heck with it, the obvious answer is
vi, of course. :-)
FLAME ON! Ducks, runs...
People say java is slow. I can write really fast Java code :-)
It really depends on how well you know the language and environment you are working with. If you pick up java and go to town it might be slow, same with perl, or C. As an example you are trying to change your C execution environment by using FastCGI. Has nothing to do with the language C but, the way that the client comunicates with that C code.
You need to come up with a good plan from front to back and then pick the language or languages that will make it happen.
And I would definitely consider upgrading the database to something more robust than MySQL.
- tokengeekgrrl
PERL is multipurpose, but won't win many road races for much of anything. PHP has ease of use, but its database support (even with pconnect) and performance in general is not the quickest unless you're hacking the Zend optimizer by hand. Python is getting closer, but it's still not the fastest. ASP isn't either.
You're identifying the right problem, but IMHO, asking the question wrong. I'd identify and measure the speed of your underlying technology first. Depending on what you're doing, the script may not even be the bottleneck! (Though it's hard to say with the amount of info provided.)
Either way, good luck!
Notice: Your mouse has been moved. Windows will now restart so this change can take effect.
My experience with Java is limited to some (very minor) work on a very large data-acquisition system (and I really do mean large, both in terms of code and in terms of data. Sure we had some performance problems, most of them due to programmer faults, some of them due to scale of the project (the previous version was written in C++, and had performance problems as well, and here we experienced the all too typical second system effect), and some few extremely annoying problems with the java implementation. Mostly related to garbage collection.
Well, to be true, we didn't really use java for the data-intensive stuff, but it was pretty amazing what we found orselves doing in java. Often prototype implementations turned out to be good enough, and never needed a rewrite in C++. The main realization was that java is certainly not as slow as some people would have it. A rule of thumb would probably be 2-3 times slower at worst (unless we are talking about swing, which really is a hog), but this was two years ago, and the situation might have improved even more.
I am not a big java bigot. But that's not because of performance. I'm perfectly happy with java's performance (although such extreme cases as you pointed out definitely needs fixing). What I don't like about java is mostly syntactical (it's too much like C/C++, and it doesn't allow you to use macros for abbreviating common constructs). I also miss complex numbers, generics, and easier interfacing with code written in C, C++, assembly, or Fortran. What I do like about Java is that it usually results in readable code (surprisingly often, don't really know why...), relatively ok performance, garbage collection, and javadoc. Which basically means that java probably would be one of my favourite choices for a language when working as part of a large team, or taking over someone else's code, but not for my personal hacking pleasure. Hmmm, come to think of it, that's a pretty good recommendation, but I think I still prefer Ocaml, Beta, Common Lisp, Smalltalk, Mercury, Haskell, C, Python, or Ruby for hacking pleasure...
Put it in the kernel. Writing it in assembly would be a plus too.
Okay, this is a stupid answer, but the question was stupid already:
> we feel it is time for a recode
The pool:
"Everything is running like crap. You've got a cold feeling". What is it?
* time for a recode ?
* time for an ask slashdot ?
* time for an upgrade ?
* time to check that the 'turbo' button is pressed ?
* time for hiring good engineers ?
* time for a profiling session [<- hint] ?
* CowboyNeal ?
Cheers,
--fred
1 reply beneath your current threshold.
I hand-filed gears, sprockets, cogs and pistons for my own Babbage Difference Engine, arranged for shipping for thirteen metric tonnes of high-grade coal from China, and blew my own glass cooling jackets from Nova Scotia beach sand. The result is the fastest goddamned shopping cart program on the net.
Carousel is a lie!
For a really large application, with dozens/hundreds of developers, hundreds of thousands of users, and millions of transactions being processed regularly, the over-engineering of the J2EE framework can pay off. For anything that totals less than about 50,000 lines of code, or that doesn't need a lot of built-in industrial-strength transaction processing and legacy system integration, though, it's just overkill. And every time your JSP wants a single variable from an EJB, something like the following happens on the backend:
And yes, in theory J2EE apps are portable between application and web servers, as well as underlying operating system. However, that assumes that every vendor supports the full spec, (which almost no one does) that they use the same version, (which they certainly don't) and that the developers can resist using any of the oh-so-tempting add-ons, native libraries, and convenience methods that each of the app server vendors dangle in front of them.
Finally, JSPs are just about the biggest letdown of any dynamic web tech I've used. They actually discourage the seperation of static content, dynamically-updated portions, and application logic. You get an equal amount of support for OO design in ePerl, and have to jump through far fewer hoops. If you want compiled "add-on" components, use the Apache module APIs (in C, Perl, Python, etc.). Both the development process and the finished application will be faster and easier to maintain, and won't require a wall of brand-new Sun Enterprise boxes to run.
And yes, I know of which I speak. My last major programming project was a J2EE-based web application that, though fairly well optimized (with a lot of quick shortcut code, PL/SQL procedures handling much of the business logic, and Apache providing all of the static content) could bring a brand-new four-processor Sun to its knees when all ten people in the office tried to "load test" it.
My advice to those who want a high-performance web application toolkit is to do what developers have been doing for a long time: find a starting point that already does some of what you need, and build on it. Don't drop $50k on a license for WebLogic if 85% of its functionality is going to go wasted.
Seriously, what kind of advice is 'use good design'? I've heard so many people spout this pretty obvious goal as wisdom, and then go on to point out that stupid solutions run slowly now matter what language you use. Given two reasonably intelligent programs, the choice of language makes a huge difference in the speed of an application.
while cgi is fine and dandy, the absolute quickest solution would be to generate a collection of static html pages for every possible combination of variables... granted this could take some time ;)
-- "Flying is the art of falling and missing the ground"
Writing your own Apache module will get rid of 2 of those three, and the third if you stick with C/C++ for your module. Note that you should still follow good design principles; the mod_whatever should just be a mechanism for getting data into and out of apache and the code that implements your application. The module is not the application; its the means to get apache to exchange data with your application.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
it is the fastest
--
Je t'aime Stéphanie
Well if you want top speed you can only get that from a compiled development platform. Most web environments have grown up as an interpreted solution in order to make changes easier (good old internet time). So if you care most about speed you want to look at a couple options, first is creating your own ISAPI if you're looking at NT, or your own DSO if your looking at apache. You can code either of these in C, if your also looking at using a traditional database behind the scenes then take a good look at Delphi / Kylix. Delphi creates the fastest web apps while still allowing applications to be developed quickly. There are tradeoffs if you look at a compiled approach. (Like you have to restart the web server if you make a code change). There are many inbetweener type solutions you may want to look at like ASP, or FastCGI.
Without real tests, your changes are likely to have little or no effect on overall performance.
Texas: all your electricity are belong to us
Although it's nice to speed up your program execution with changes like cgi to fast-cgi, good design will benefit you the most.
What's a good design? Write your code in a way that you can run it on multiple servers with a web redirector in front of it. Try not to depend too much on fancy SQL logic as it is diffucult to scale your databases. Instead, try to stay out of the database as much as possible, and when you do have to use the database, split up your schema such that it wouldn't be that hard to run multiple database servers. Another good thing to keep in mind in MySQL is not to do too complex of queries. MySQL flies with simple selects on indexed fields. Extremely complex updates can really tie up your database.
Now that you understand good design, how do you code your cgi end? For ultimate speed, you could do apache modules written in C, but mod_perl is only trivially slower and much easier to develop. One stipulation is that if you are getting deep into the guts of apache with things like internal redirects or many layered handlers I'd advise using C, but it doesn't look like you'll be doing that.
Many "web languages" are page-centric. PHP, and ASP are like this. Other "web languages" take application languages and tie them to a page-centric mode. Mod-perl does with as does ASP+COM. For a lot applications, this isn't really a problem because the application flow maps nicely to the page flow. When the application does things which can be presented on a web page, but whose behavior is not easily modelled in a page-view manner, then you start to see kludgy implementations.
Java allows you to code in a manner appropriate to the part of the problem you are solving. If you have, for example, a game-play engine that runs in the background, you can easily spawn a Thread for it that will run just like any other Java Thread without any limitations due to being a "web program."
This allows a design where the game engine is nicely abstracted and isolated from the front end. This also makes it easier to have a team of people in charge of making the game cool for users and another team making the gameplay itself cool.
On a side note, EJB's can impose a lot of infrastructure and programming overhead that's unecessary if you don't need the services of a full-blown Component Transaction Monitor. You can frequently do what you want by using regular Java classes or Java RMI.
But if everything you do is going through the equiv of "CGI", then forget Apache. HTTP is far too easy a protocol to implement (hell, its the protocol used for lots of "embedded" servers in stuff like Napster and Shoutcast). Implement your own HTTP server where you automatically can have all requests go to an engine for processing directly, and take Apache and all that configuration out of the loop. You'd effectively have two servers running -- an apache server to handle throwing images and static pages around, and a second home-grown server that directly serves up the application data. Doing this won't change that your database engine is your primary bottleneck, but it will reduce all other bottlenecks by quite a bit.
Apache is a general purpose system, and does it pretty damn fast, but for a true special-purpose system, its best to implement your own special-purpose server.
The "embedded server" for Java follows the same principle. Maybe W3C has some implementation code in C that may prove useful.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
I don't know about speed numbers (everything I've done server side has been extremely fast) but development time is great with JSP/Servlet/EJB. It's easy to build a great OO design, implement it, and deploy it on gobs of web/app servers. It's really a shame Sun is giving Java such a bad name around hard core GNU/Linux peeps. It's such a pretty, robust, fun environment to code in. Try it. You'll like it. Or you'll vomit.
In reality, language choice has much less of an impact on the speed of an application than the design. but Even a language that's twice as fast can be ten times as slow with a bad design. Some languages make certain designs easier to express, just pick a language that lets you design the way you want.
The *first* thing you need to do is make the design is right. No matter how fast the language is, the number of new users and new features will outstrip any incremental improvements. Even if you make it three times as fast eventually there will be three times as many users.
The only lasting solution is to design it so it scales. If you don't, you'll be chasing the increasing loads by praying incremental optimization and faster new hardware will keep you ahead of the curve. If you build a successful site, it probably won't.
Consider Slashdot a classic case to study.
It's a common misconception that Assembler is faster than C. Good compilers know how to group instructions together so that they execute faster on the given processor. It's quite hard to do by hand.
In fact it's research to that effect, a few years ago, that led to the development of RISC machines.
A good assembly programmer could still outdo a compiler when he really focussed. But the compilers knew MOST of the tricks, and applied them consistently everywhere. In competition with assembly programmers - even good ones - the program that had been through the compiler normally came out significantly ahead.
Given this, and the greater portability of things like Unix (which was mostly in C with some minimal assembly where needed), assembly code was mostly dropped except where it was unavoidable (like OS routines to get the stack arranged after an interrupt so you could get back into C).
But given that the compiler was generating essentially all the code anyhow, it made sense to design computers with simplified ("reduced") instruction sets, rather than extended ("complex") sets of feature-prone instructions. Sometimes it would take several RISC instructions to do the work of a CISC instruction. But the compiler could generate it, so it was no skin off the programmer's nose.
With the compiler to do the work, a RISC computer could be very simple internally. This meant it could be very small. That meant the parts could be close together, so it could run faster with a given technology, and that it could be moved to a faster technology sooner, when the production yeild for a BIG chip was still too low but the yeild on a SMALL one was adequate.
The extra instruction fetches were a problem. But instruction cacheing kept the inner loops in the machine, so there was still a big net gain.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Design is a major issue when talking performance, but there's more to it than that. The poster mentioned using MySQL on the backend. That means there's quite a bit of work to do before we even start mentioning design.
... NOW you can start your design.
Someone with a fair understanding of data analysis needs to go through and figure out what the data storage needs are. Now pick your database: MySQL is reasonably fast for small databases on small machines. But it reaches its breaking point relatively quickly. My experience indicates that PostGreSQL is the next step up the ladder. With a user base in the 5 figure range, I would run Postgres on it's own machine and watch it closely. If it seems to have problems keeping up (and you're not on too small a machine) you'll have to start looking at a big database (e.g. Oracle).
Also, the other hardware you're running on has some performance implications. Do you have a large amount of physical memory? The more information you can keep in memory, the faster your system. How are your disk file systems layed out (NFS? RAID?). The when you do have to go to the file system, these having resolved these questions will affect performance.
Now we can talk about languages and delivery mechanisms.
You mentioned keeping an eye towards portability. Unfortunately, there are trade offs there as well. If you want speed, portability is your enemy. Java and Perl are great languages (I use them and recommend them often), but they are relatively poor performers. You can pretty much eliminate any interpreted language (e.g. Tcl) and web script (e.g. PHP, ASP, ColdFusion).
The heavy lifters are still C and C++. But even if you write your CGI in C, you're still incurring the CGI penalty (which is very expensive).
If you insist on using Apache, then start by writing an Apache module in C or C++. Even faster than that is to skip Apache altogether and write the entire server yourself. You want this to be web delivered still, which is fine as the HTTP protocol isn't too difficult to implement.
Once you've figured all this out
Esperanto--the universal language!
Oh, you meant programming language.
[Man, what a bitch it would be to try to code in Magyar...]
--
-- Geof F. Morris
Server side script rarely consumes a lot of processor cycles. I beleive the database server and other libraries that you call out to make a much larger impact in speed.
It's all a matter of optimizing the slowest part for the largest gain. Optimizing the script will result in much less improvement than say, switching to a faster database server.
Also next in line would be the web server that is hosting the application. Some scripting languages are possible more efficient than others but that only matters if you're doing a lot of processor intensive things within the script (mathematical calculations, etc) which is rarely the case.