Theory vs. Practice
Diagnosis is not the end, but the beginning of practice.
› How do people pick a Language?
Whether this is in their family, at school or in the street, people usually adopt the language used to talk to the greatest number of persons they are exposed to.
This is how first-generation immigrants see their kids forget the ancestral culture to adopt a new one.
Like mere products, languages are heavily promoted. Music, Movies, News, Entertainment programs and even Business contacts will drive more and more persons to the language that offers more opportunities than others.
At the core of the eco-system, a language is considered by governments as a strategic asset because of the Network Effect.
It is not accidental that the same is true for Information Technology.
Let's have a look at the consequences.
The test below is exactely the same hello.js, but this time run by the G-WAN server, showing that node.js is a poor server, and certainly not the best way to use Javascript (or any other programming language as we will see below).
The endless promotion of private interests
In Computer Science, the same selection process happens at Schools (sponsorized by private interests to teach patented languages that will tie users to a given environment), or on the Internet for self-grown Web developers learning from Forums, Questions & Answers sites, venture capitalists and startup hives as well as head hunters (all of them also "sponsorized").
Once a person has learned a language, it will be difficult (lack of time, curiosity, and incentives) to switch to anything else – so only a tiny percentage will make the effort. That's all the value of locking people early.
This explains how some proprietary (patented) languages are taught in public schools – at the expense of a 41-year old public-domain language which is so technically relevant that it is still used to write all the other languages.
The point here is not to oppose any community, or to judge any action – the point is to make a diagnosis to understand how we have reached the current state of things by constantly eluding the good questions.
Do what I say, don't do what I do
The arguments behind JS, Java, C# or PHP are invariably the same:
- "C is difficult to learn – not for CS students" (actually C has fewer keywords and standard library functions than all others)
- "C is hazardous for pointers and memory management" [2020 update: all resolved by SLIMalloc making C "memory-safe"]
- "C is obsolete and a more modern language is needed." (all other languages and operating systems are written in... C)
In short: "programming languages, OS or big established vendors can use C but... not you the students, SMBs, consultants and hobbyist". This is not good for you. Stay away. Honest, we know better: we use C (to make the junk that you should use).
2020 update: this took a whole new dimension with the GAFAM collectively stating that,
Using C and C++ is bad for society, bad for your reputation, and it's bad for your customers.
To make sure that they had no contradictor, a U.S. DoD Cyber-security contractor, former DARPA employee, has censored SLIMalloc from Wikipedia... under the cover of several anonymous accounts (what a glorious way to claim to be right).
If you compare SLIMalloc to GOOGLE's ASAN and other "statistical" derivatives, you will see why: they all have been designed to fail, by rounding the allocated block sizes. Rounding up ignores gazillions of memory-violations (generating false-negatives) and rounding-down generates gazillions of fake memory-violations (generating false-positives).
This makes the GOOGLE "memory-protection" so ineffective that it is totally unusable – hence GOOGLE dominating the market for sales of memory-safety vulnerabilities with its Web browser Chrome and its OS Android (there are many more smartphones than desktop and server computers, so governments pay for these backdoors letting them spy, sabotage and kill people carrying smartphones on a 24/365 basis).
Securing programming languages cannot be done by ignoring that the operating system and compilers are written in C (like Java or Rust do, hence their by-design memory-safety flaws). The only way to resolve the problem is to make C/C++ memory-safe – like SLIMalloc did it in 2020.
At least, this sabotage of the "encyclopedia" (all the knowledge of mankind) has demonstrated my point.
The fact that these expressed views come from people who are both judge and party is never considered. If such a link is suggested then moderators swiftly remove any reference to a possible question.
I started coding in asm 33 years ago (I was 11 years old). I have seen more than 20 languages, many claiming to burry C. Many seem to be designed for the sole purpose of preventing you from doing the job properly, like C++ (here exposed to ACM award winners) and all its successors.
And that seems to be the case for all those languages designed for others (Cobol, Ada, C++) as opposed to the tools made for one's needs (C, Lisp, Smalltalk).
What I find unique in C is that it is the only portable programming language that gives you so much freedom (for example, without changing anything in the C language, SLIMalloc made C and C++ "memory-safe" in 2020).
While other languages strive to keep you quiet in a straightjacket with just enough air to let you push buttons, C is never ever limiting you: there are as many possible ways to build buttons as you have people. Like for painting or music, Art is made possible.
Keep away from people who try to belittle your ambitions. Small people always do that, but the really great make you feel that you, too, can become great.
I will not restart a debate about how C can wipe-out its modern alternatives on the three above points. C is obviously lacking genuine innovations like pointless code verbosity, useless complexity, huge runtime libraries, low performance and high usage of CPU and RAM resources. So, instead I will illustrate each solution's capabilities by merely using programs written in different languages.
Avoiding the "Apples" and "Oranges" pitfall, G-WAN supports both C and Java servlets so we can compare the reciprocal benefits of each solution when involved in the:
- same job (done with the same Web app. source code)
- same hardware
- same version of Linux
The goal is to let informed people decide what language is suitable for their needs – whether they want to write Web servers (like G-WAN) or its Web applications (loan.c, loan.cpp, loan.cs, loan.d, loan.m, loan.mm, loan.java, loan.scala, etc.).
We have seen earlier that G-WAN makes hello.java fly much higher than Apache Tomcat. But "hello world" is a test for AJAX or Comet Web applications, it does not involve the huge processing and memory amounts usually involved in typical server applications like online Games, CRMs, Big Data, HPC or Hight-Frequency Trading. We clearly need to use a more rich range of tests, including resource-demanding jobs.
Calculating Loans
A trend which peaked recently is to calculate the compound interests of growing government debt fueled by interest rate variations (surprisingly, the practice florishes in parallel to public deficits when interest rate fixation is left to private lenders).
To compare "Apples" to "Apples", these loan calculations have been made with Caucho Resin and G-WAN + Java (Caucho Resin is faster than Apache Tomcat because it uses C routines called from Java with JNI instead of using the Java NIO API):
Apache Tomcat
The total CPU usage is very high because Tomcat server uses the Java server API.
Performances are not quite good and scalability is decreasing rapidly.
As always with the JVM, the memory usage is remarkably high, and a large share of it is not correlated to the job in progress.
Keep in mind that this is for a mere "hello world" test: Java as a language is not dragging-down the tiny "hello World", it only has influence on the hard-working JVM-based server.
Caucho Resin
The total CPU usage is much lower than with Tomcat because Resin relies on a C interface called from Java.
Scott Ferguson, Caucho's President and Chief Architect explains: "Resin's core networking library is written in highly optimized C" before adding: "C is what allows Resin to be fast".
And this can be verified by this "hello world" test where performance and scalability are superior to Tomcat's.
But Resin is still using the JVM for the server core, hence a traditional slow start and high memory usage.
G-WAN + hello.java
Now, we are still running an hello.java servlet, but we are doing it from an application server written in C.
We can see that for small payloads (like Comet or AJAX Web applications) a C server does better than a Java server, even when an hybrid design is chosen like for Caucho Resin.
G-WAN processed 10x more requests in 3.7x less time.
The same job is done 37x faster.
G-WAN + hello.c
We are now comparing "Apples" to "Oranges", running an hello.c servlet from an application server written in C.
As compared to a G-WAN Java servlet, a C servlet works 50k RPS higher.
50k RPS may look like a modest gain, until you look above at Tomcat which peaked at 50k RPS for high concurrencies.
G-WAN processed 11x more requests in 4x less time.
The same job is done 44x faster.
This first comparison, and Caucho's design, demonstrate that the idea of not using Java everywhere has some value.
Now we have chosen a server, here is the 2.12 KB output of the loan.java and loan.jsp programs: (as calculated by loan.c)
Dear Eva, your loan goes as follows:
This page was generated in 0.01 ms. (on a 3GHz CPU 1 ms = 3,000,000 cycles) |
The loan servlet is an ideal test for an application server because it:
This allows to have a whole range of tests, varying with the loan parameters (such as term, amount, rate and name) and the result is stressing application servers until they can no longer cope with the load. Note: because of the IEEE 754 double-precision format (sign: 1 bit, exponent: 11 bits, precision: 52 bits) calculation rounding errors accumulate with large loan terms. And, beyond 800 years, these rounding errors go to the point of creating an infinite loop. Just don't go this far as it is then irrelevant. |
With loan(1).java, G-WAN served 75x more requests in 23x less time while using 4.6x less RAM and 13.2x less CPU resources than Caucho Resin loan(1).jsp: (Nginx and G-WAN serving a 100-byte static file are given as a reference)
Avg RPS Total Elapsed Time RAM user / kernel / total (CPU jiffies)
--------- ------------------------- ---------- -----------------------------------
G-WAN loan(1) 690,617 00:29:04 = 1,744 seconds 71.67 MB 218,929 632,777 851,706
Resin loan(1) 9,162 11:08:40 = 40,120 seconds 332.53 MB 10,089,553 1,150,179 11,239,732
Nginx 100.html 167,977 01:53:43 = 6,823 seconds 11.93 MB 1,000,270 1,910,443 2,910,713
G-WAN 100.html 826,821 00:25:16 = 1,516 seconds 9.21 MB 155,884 563,147 719,031
.jsp.png)
Resin loan(1 year).jsp
The user-mode CPU usage is so high (40-50k jiffies) that it is off the 6k scale.
The memory usage is growing rapidly, and staying at a high level (332 MB).
Despite the low-level C native API calls used to implement the server, this server running into the JVM is showing the limits of the platform for high performance and high concurrency jobs: 11k RPS.
Note that the source code is identical in loan.jsp and loan.java (a different form is used only to simplify the deployments in the Java server).
.java.png)
G-WAN loan(1 year).java
Running the same Java source code used by Caucho Resin, G-WAN has put far less pressure on the machine.
A lower and constant memory usage as well as a tiny CPU overhead make many resources available for other tasks, having the server make room for the JVM runtime instead of competing with it – and the results are quite substantial:
G-WAN processed 75x more requests than Resin – in 23x less time.
The same job is done 1725x faster.
Before you ask, yes, we have tried a loan(10 years).java test. And while G-WAN completed the whole test in 34 minutes, Caucho Resin took 1 hour for merely doing one single concurrency step of the [1-1,000] range.
So, with a relatively modest 10-year test, G-WAN serving a java servlet was 24,000x faster (requiring less network equipment and electricity) than Caucho Resin, one of the best Java servers.
Trying to process a 10x longer loan(100 years).java test, G-WAN and Resin have hit the wall of the JVM: with 100 years the loan.java application is now too slow to be usable on the [1-1,000] concurrency range so we had to interrupt an almost ∞ benchmark.
After those tests, we believe that one of the first bottlenecks is the data copy imposed by Java for the C server to access the output buffer. Having a way to generate UTF-8 strings and a direct access to the buffer generated by Java (the same goes for C#) would greatly reduce this overhead.
Now, comparing G-WAN to itself and "Apples to Oranges" for the servlets G-WAN + C served loan(1/10/100 years).c in 9, 11 and 25 minutes (vs 29, 34 and x hours for G-WAN + Java). Given the number of requests served by Java and C, that makes G-WAN:
4x faster for G-WAN loan(1).c as compared to G-WAN loan(1).java
5x faster for G-WAN loan(10).c as compared to G-WAN loan(10).java
25,000x faster for G-WAN loan(100).c as compared to G-WAN loan(100).java
600,000,000x faster for G-WAN loan(100).c as compared to Resin loan(10).java
Chose your tools wisely if you need to work on Big Data as fast as possible – or if you cannot waste fortunes in your Data Center.
In the light of these results, it looks like C is not the problem ("difficult, hazardous, obsolete") – the problem is rather for what kind of job a development platform can be used. Some languages can be used for peripheral portions of the code but not for the core engine of a server, while others support more pressure because they do not have to deal with an abstraction layer between the hardware and the application (like the JVM used above, or the virtual machines deployed everywhere to partition servers).
In additon to be so much efficient for infrastructure software like G-WAN, ANSI C can (1) provide easy-to-use interfaces and libraries, (2) secure pointer and "memory-safety" [done by us with SLIMalloc] but also serious file-system and syscalls sandboxing, and (3) be at least as concise as any more modern alternative... that is, when used properly.
All what was needed to compare servers rather than scripted languages was a decent Application server written in C able to run Java servlets. Too bad that we had to write our own to get those insights.
Religion and I.T. do not mix well – for a reason
With this in mind, the recruting wave of (proud-to-be) software evangelists may look less mysterious... especially if you correlate the scale of their humungus budget to the pathetic execution of their sponsor's product lines (by far, Java is not always the worse choice).
A recent trend goes as far as to shamelessly promote the least efficient (client-side) programming languages (Javascript, etc.) for Cloud jobs because this will push end-users to buy more 'virtual' server instances, artificially raising profits.
Seriously. Would you buy a particular car because someone calls an horrible thing "cool" and "breathtaking" on thousands of blogs appointed by the vendor?
Or would you have a look at the design, the engine, the handling and the running costs before buying?
It's time to do for software what everyone does for hardware: having a close look at what is sold before buying – because we have seen above that the cost of running bad software enlarges the hardware costs far more than a thousandfold.
And this is that same artificially inflated bill which is paying for evangelism – something that really "cool" and "breathtaking" solutions do not need to win the heart of users.