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.
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.
Actually, the best would be in assembler as an Apache module. Apache modules are nice in that they don't have to be forked/execed - they just run right in the Apache process.
Engineering and the Ultimate
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.
Yep. I run Tomcat 3.2 (yes, that is the current version, and yes, Tomcat 3.1 was still about 1/3 as fast as JRun & Resin) on my website, where all pages are dynamically generated. Mainly because I'm too cheap to buy JRun or Resin (Resin, btw, is free for personal use).
But JRun & Resin both outperform Tomcat 3.1 & 3.2. But Tomcat 4.0 is supposedly a lot better. I simply can't rely upon it until the development is a little further along.
And, I can't say enough good things about JSP tags. They are the "right" way to do dynamic web authoring.
--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.
If you're dealing with a web application interfaced with Apache, and communicating with clients through the network, and data coming through a relational database, than it's almost definite that the speed difference of C or C++ simply won't make any difference.
You've got to focus on what causes the performance bottleneck, and address that.
In web based applications, there are generally three bottlenecks:
So the real advice is: choose a language that handles your bottlenecks best. If you are really doing something computation intensive that takes a long time in Perl, then it's worth writing in a highly efficient language, like C++, or OCaml.
But if your bottleneck isn't really computation, then you might be much better off using some else. If it's CGI load time killing you, than writing in Java (with Jakarta), or Perl (with mod_perl) or Python (with mod_python) will be significantly faster than a C++ program loaded through CGI. And any of the other languages will likely be easier to use than C++.
If it's database IO time, then leaving the language alone, and redesigning your tables to optimize database access may payoff much better than changing languages.
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.
Actually php 4.x has native session methods too. I use them and they work very well.
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.
If you add the Zend optimization engine, it's even faster if you're doing alot of loops and such.
Yeah, I like Zend too, but there are other PHP caches available as well, such as:
Haven't played with them myself, but I've heard plenty of good things about APC.
- passion
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!
It is a misconception that compilers are now so good that people can't beat them. If most programmers had spent as much time with assembler as they do with high-level languages, most programmers would easily beat an optimizing compiler.
But of course, writing anything substantial in assembler is just stupid. Almost as stupid as having this discussion, which also reduces (at leaast my) productivity...
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.
---
Assembler CGI scripts IMO are the fastest most efficient web scripts that you can write.
You can write them because I wouldn't want to write Assembler CGI scripts, but they would be efficient.
Keeping
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.
Compilers are not so dumb as in the times of 8088, and the processors are not so simple anymore.
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...
Bob wrote:
[snipped explanation about why java and OO is best solution there, and why it can't work on bsd due to kernel limitations]
You are clueless. OO is not a silver bullet for development. What fits you well may not be good for this guy. Hell, we don't even know what its problems are !
Anyway, stop this insanity about non-preemtiveness FreeBSD scheduler that lack the spinlock reference counting in its module destructor, as it have been solved months ago !
(And no, the myth that unix commands name have been choosed based on intestinal noises have already been debunked elsewhere. For instance, fsck was choosed for a different reason)
Maybe I just bited an ignorant troll, but I can't let you spread your bullshit all over slashdot.
Cheers,
--fred
1 reply beneath your current threshold.
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.