
Faster than C? Parsing binary data in JavaScript. - tuxychandru
https://github.com/felixge/faster-than-c
======
tabbyjabby
I am _extremely_ doubtful that optimized C is going to be equally performant
as optimized JavaScript. There is innate overhead when using an interpreted
language, no matter how advanced the interpreter. JavaScript is also garbage
collected, while C is not, adding an additional level of overhead.

At no point in this article are we shown the code of this new parser. We are
also told that is incomplete. So we have a parser which we can't see and which
is not finished, but apparently dominates its C counterpart in performance.
This leads to me to believe one of two things:

1\. The parser isn't complete, and its unimplemented functionality is going to
be more expensive in terms of performance than the author anticipated, thus
rendering his preliminary results void.

2\. The implementation of the C extension he is comparing against is not very
well optimized. As said above, I find it _very_ hard to believe that well
optimized C is going to be beaten by well optimized JavaScript.

~~~
tptacek
It feels likely that the fundamental problem facing JS programs competing with
the entire solution space available to C programs --- apart from the nerd who
will implement an equivalently fast JIT compiler to run the JS on just to make
a point --- is that C code has much better control over the layout of data in
memory. You can work around the GC issues and modern compilers work around the
interpretation overhead, but a C program is going to tend to have the easiest
time ensuring that its working set fits into cache.

Of course, the real problem here is that he's comparing his JS code to a
random blob of C code that just happens to be part of the MySQL package. Is
the MySQL client library famously performant?

~~~
SoftwareMaven
I agree with you. If getting every bit of performance out of your hardware is
important to you, C (possibly with inlined assembly) is the way to go.

I am _so_ happy that I've never had to do that in my career.

~~~
DeepDuh
That being said, Fortran is being used equally often, if not more often, in
HPC applications. The reason being that modern Fortran both gives you bare
bone access to the memory structures and offers array slicing notation as well
as good multidimensional arrays for HPC. (C multidimensional arrays usually
don't offer optimal performance, leading to the pointer arithmetic notation).

It's still an ugly language though. I've yet to find a C language extension
that gives you the higher level features of Fortran however - and even then it
would have to be an industry standard to be supported by the wealth of HPC
compilers out there - remember it's not only x86, you also have GPUs, Itanium,
PPC.. Looking forward to a world where LLVM actually gives the performance
people need in that field, because architecture wise this could turn out to be
a silver bullet.

~~~
ams6110
Fortran is not exactly a general purpose language though, it's specifically
designed for the sorts of problems that scientific and HPC tends to deal with,
and it's probably rare especially nowadays to see it used anywhere else. I'm
guessing there aren't any web frameworks written in Fortran (though I'm sure
someone will now point one out....)

~~~
DeepDuh
Web development with Fortran. _Shudder_. (String handling is abysmal in
Fortran so I wouldn't wish that to my worst enemy).

No, but my parent was talking about deep code optimizations being almost
exclusively being done in C. I'd say HPC is a significant market for code
optimization, so I wanted to point out that Fortran is kind of the industry
standard there.

~~~
evoxed
If I'm trapped on a desert island with (somehow) my MacBook and a solar
charger, this will definitely be the first project I take one...

------
snprbob86
I love the "eval is awesome" section.

It's taken my _years_ of study, but I finally "get" Lisp. Let me summarize
pg's On Lisp:

"Lisp is a language for writing _programs fast_ "

1) Write a function

2) Write a function that does something similar to #1

3) Begin to write a function that does something similar to #1 and #2

4) Abstract out the commonalities between #1 through #3

5) Encounter all kinds of new use cases for your abstraction in #4

6) Wait for #5 to become unwieldy

7) Abstract #4 even further, until you have something that resembles an
interpreter

8) Wait for #7 to become a performance bottleneck

9) Write a compiler that takes inputs to #7 and turns them into #1 through #5

"Lisp is a language for writing _fast programs_ "

~~~
yairchu
Doesn't it cause a "Javascript eval injection" vulnerability?

I don't know Javascript so I may be wrong here, but:

* Suppose someone uses this library to create a "MariaSQL Explorer App", where you give the app connection credentials and it connects to the database and shows you the data etc.

* A malicious attacker tells a user "have a look at my database" and the user goes to the attacker's database.

* The attacker's database (or spoof of one) has a column called 'dummy": MALICIOUS_CODE(), "colname'. notice the '"' chars inside column name.

* The MALICIOUS_CODE() runs in the user's node.js app. Perhaps it sends the attacker the passwords to other databases from the app's keychain or something..

* Profit

~~~
Groxx
Which is why you sanitize input. Which _every_ sql-communicating system must
eventually do somewhere - this is no different.

Besides, that's just an example snippet.

~~~
Zr40
If you sanitize input, it implies you're inserting the input into an execution
environment. If possible, it's better to treat data as data.

In the Javascript eval case, it's definitely possible; just access the data
through a variable instead of inserting it into the eval'ed code.

------
mkaufmann
For me myself it is often very motivating (sometimes demotivating) if somebody
comes up and implements the same thing I want to do - but they accomplish 10x
faster performance (even better if it is written in a cleaner style). The
author seems also to rather enjoy those challenges ;)

In my interpretation the question "Faster than C?" is relevant because it is
very easy to think that certain problems (like parsing binary data) are just
not a good fit for language Y and thus the performance can't be good. Even if
C performance is not attainable sometimes one cat get closer than one would
think.

My last question is regarding his optmization example.I don't program
javascript and thus have difficulties understanding how the optimized variant
could every be faster than the original one. String concatenation and
evaluation should not be faster (from my laymans perspective) than setting an
indexed value to an array? (Ok actually it probably is not an array but a hash
map, but are those so inefficient in java script? Or is it rather behaving
like a sorted list where every value is inserted via binarcy search?).I would
be very happy to get some insight.

~~~
dbaupp
Regarding your last question: the string concatenation/evaluation happens once
while creating the parseRow function and from then parseRow is a
compiled/JIT'd function object, no string handling happening. The problem with
the original is not the hash map creation, but the fact that it requires all
sorts of extra loops, and array & property look-ups.

Also, I think that is possibly some missing information there, since in the
second version the column names are fixed (so the columns argument to parseRow
is ignored), while in the first they are not.

~~~
mkaufmann
Ah ok so this is probably the parser equivalent to precompiled queries. Given
a fixed query, a specific parse row function is created once and than reused.
Thanks!

While I think code generation is certainly the right approach in some
examples, I see one problem in this example: As the parser is basically
pregenerated using a certain column definition, why does the generated
function has an parameter columns? It is simply discarded. So I would say it
should rather be:

    
    
      var parseRow = new Function('parser', code);

~~~
dbaupp
I agree, and I don't know. (I even looked through the source to try to find if
parseRow is a function from node-mysql. It's not, as far as I could tell.)

------
PommeDeTerre
The excessive use of "fuck" and "shit" throughout the entire article really
takes away from its message. It just seems very immature. It's hard for me to
take it seriously when it sounds like it was written by an angsty teenager
who's trying to look tough in front of his friends, or something like that.

~~~
jlgreco
I would hardly call that excessive profanity. In a 2000+ word article there
are what, 10 instances of 'profanity'?

Honestly I think it speaks more to your maturity that you would find that _so_
bothering that it could detract from the _content_ of the article.

~~~
PommeDeTerre
I don't take offense to the words that were used. It's more akin to articles
that use absurd fonts or blatantly poor color schemes. Such things are
unnecessary, and make it more awkward to absorb the actual content.

When I see authors doing things that obviously make their work harder to read,
it does make me question their judgment, which in turn makes me question the
validity of what is being expressed.

~~~
mercurial
I pretty much agree with you, though it certainly depends on the context (I'm
more likely to not be bothered by it in a post on a mailing list). But for a
technical writeup? You want to be treated like a professional, write like one.

------
eric_bullington
This is an outstanding overview of how to build fast programs in JavaScript. I
really appreciate the fact that Felix took the time to write it. I learned a
lot, and will definitely integrate this into my work whenever performance-
critical code is involved. Particularly since I enjoy dataviz so much.

I'm a little surprised that someone so into JavaScript is using R and ggplot2
to visualize his data, and not d3 along with CoffeeScript for munging data (or
Python if you can't stand CoffeeScript). Don't get me wrong, R is a powerful
tool, but with d3 you can skip the whole ImageMagick/Skitch step since you're
making visualizations directly for the web. Plus, once you've grasped d3's
declarative approach (took me a while), it's so easy to quickly make powerful
visualizations with it. In fact, it was partially inspired by ggplot2, if I'm
not mistaken.

And to quickly munge/clean data, I've found CoffeeScript does very well here,
similar to how easy it is to use Python for this task. I wouldn't want to
write out JavaScript when rapidly trying to get data in the right format for
visualizations, but with CoffeeScript and a functionally-oriented library like
underscore, it's pretty easy.

That said, I'm sure once you've mastered such an intricate tool as R, it's
hard to give up that power. But if you're a node devotee and you're looking
for a good tool in JavaScript to visualize data, you can't get much better
than d3. I know a lot of dataviz folks are learning JavaScript just so they
can have access to d3.

~~~
rgbrgb
Really the nice thing about ggplot2 is that each of those figures were
probably like 1 line of code. Having a DSL designed for your data analysis is
awesome.

------
masklinn
> But, life is never this easy. Your code may not be very profilable. This was
> the case with my mysql 0.9.6 library. My parser was basically one big
> function with a huge switch statement. I thought this was a good idea
> because this is how Ryan's http parser for node looks like and being a user
> of node, I have a strong track record for joining cargo cults. Anyway, the
> big switch statement meant that the profiler output was useless for me,
> "Parser#parse" was all it told me about : (.

FWIW this is also a case of "get better tools". Line profilers exist, and they
can handle that kind of cases (though the instrumentation costs go up
likewise).

~~~
netghost
For Node and V8? I'm sure you're right, but when I was poking around I didn't
see much more than suggestions to use "node --prof".

Which tools have you found useful?

~~~
masklinn
> For Node and V8?

I don't know, I use neither. I'm just saying, there are profiling tools which
handle the "One Big Function" pattern.

------
kghose
I write code primarily to analyze data from my experiments, and I do it
primarily in Python. I have been told (and have read) repeatedly, that
optimizing is to be done right at the end and only to optimize the inner most
loop etc.

From my reading, this guy is advocating the exact opposte: optimize as you
code. It sounds sensible, but what to other people who have to optimize for a
living have to say?

~~~
simonw
I think the difference here is that the problem is completely understood from
the start: there's a MySQL protocol (which the author has already implemented
in the past) and his project needs to be able to handle that exact protocol as
quickly as possible.

~~~
mkaufmann
This. Also the applicability of the optimization rule depends a lot on the
context. It is typically stated for a complete project. Writing a library is
different from that.

Depending on the kind of library you write, it could be that it is called in a
hot inner loop of an outer project. So yes in that case it would make fully
sense to optimize the heck out of the complete library (like e.g. a mysql
client).

Another point is to see the reasoning behind the optimization rule.
Optimization always is associated with cost (cost of programming, additionaly
complexity in the code, maintance). This cost has to be recovered from the
effects of the optimization. As the number of users for a piece of code grows,
the benefit of optimization rises, but the costs should be more constant. Thus
at scale it also makes sense to look a smaller optimization potentials.

But this does probably apply to not even 1% of the typical projects.

------
latchkey
I really like the style of this writing. Thanks, I learned a bit. I just wish
the presenter dug deeper into the final mystery to round out the entire
presentation.

------
willvarfar
I think that the drivers can do a lot more to improve DB performance.
[http://williamedwardscoder.tumblr.com/post/16516763725/how-i...](http://williamedwardscoder.tumblr.com/post/16516763725/how-
i-got-massively-faster-db-with-async-batching)

At low load, the DB worker is idle when a request arrives and it can be
dispatched immediately. But under load, the DB worker is busy when requests
arrive and they build up as a backlog.

When a backlog builds, the DB worker can examine the pending requests and
combine those that it can to reduce the total number of requests.

Not all requests are combinable and there can be subtle rules and side-
effects. It is likely that a driver with just a modicum of combining ability
would be very conservative e.g. simply combining single-key selects that are
queued adjacently or such.

Even still, the gains can be massive and performance never worse.

(Oh, equally applicable to NoSQL too.)

------
faragon
No way. Even with equal-efficient code, there is an additional point that is
often ignored: Data structures are way more simple in C, with less overhead,
and with higher cache-hit ratio, because more data fits in CPU data cache.

As example, gcj is as fast as g++ for code generation (both generating machine
code, without virtual machine involved), however, in benchmarking appears to
be slower, just because the data structures. If you tweak the Java code for
use simpler data structures, e.g. integer or byte arrays, data overhead gets
reduced, so memory cache hit increases, thus keeping similar performance to
C/C++.

Other cases, like Java bytecode running on a VM, even with great JIT like
HotSpot, suffers also _a lot_ because of data structures, so even when
generated code is quite decent (runtime profiling, etc.), penalty is there, so
code will suffer great penalty unless running with huge L3 cache (e.g.
32-48MB), being noticeable anyway no matter how much cache you add when having
to do many memory indirections more.

And of course, when comparing, you have to compare equivalent things, e.g.
Java <-> C/C++ ports, and not completely different software with different
implementation (e.g. optimized built-in string handling vs non-optimized C
string handling -e.g. ASCIIz string handling is slow, because of stupid C
string function implementation, not because the C language itself, being the
reason of C strings not being used for high performance code, even when
writting in C-).

------
Groxx
_Excellent_ read. Written well, convincing examples of why it's good advice,
and doesn't waste space in making its point.

------
agentultra
I guess the hope of high-level languages is that you can build a more
interesting vocabulary from complex concepts.

[http://www.pvk.ca/Blog/2012/08/27/tabasco-sort-super-
optimal...](http://www.pvk.ca/Blog/2012/08/27/tabasco-sort-super-optimal-
merge-sort/)

It seems that there's a lot of effort going into making languages, "faster
than C." Perhaps we would all be better off working with languages that just
give us better abstractions -- user vocabularies. Layers on layers.

Don't get me wrong, C is the right language and a good tool for many
situations. It's just that if you're going to extend the vocabulary then why
do you have to change the implementation? If you want to optimize why optimize
the compiler at such a low level?

Either way I just want to say that it's an interesting conversation and I'm
looking forward to seeing more.

------
tantalor
My only problem with this article was that it didn't once mention parsing
binary data, except in the title.

------
sil3ntmac
Very worthwhile and well-designed writeup! I do wish that he had expanded the
last argument to show what/how he fixed the performance problem. Also, does
anyone know _why_ eval is faster than just defining the function? I mean wtf,
why doesn't v8 make this optimization?

~~~
mistercow
>Also, does anyone know why eval is faster than just defining the function? I
mean wtf, why doesn't v8 make this optimization?

There are three optimizations I see in the eval example:

1\. The object is created as a literal rather than by property assignment (see
<http://jsperf.com/object-literals-vs-object-properties>).

2\. The for loop loop is unrolled.

3\. The column names are cached in the function and do not have to be
retrieved each time.

The reason these can't be done by v8 on its own is that they make assumptions
that v8 can't guarantee. For the first two, you have to guarantee that the
columns array is always the same length. For the first and last, you have to
guarantee that the columns will always have the same names.

So even though you take a big hit on the initial eval of the function, you'll
likely make up for it by having a better-optimized function.

~~~
rb12345
I noticed a possible issue with the code generation, which may cause the
issues with excessive heap allocation that were reported:

    
    
      var code = 'return {\n';
      columns.forEach(function(column) {
        code += '"' + column.name + '":' + 'parser.readColumnValue(),\n';
      });
      code += '};\n';
      var parseRow = new Function('columns', 'parser', code);
    

Instead of performing so many appends to a single string, I would try using
map() and then join() the resulting strings:

    
    
      var code = ['return {\n',
        columns.map(function(column) {
          return '"' + column.name + '":' + 'parser.readColumnValue(),\n';
        }).join(''),
        '};\n'].join('');
    
      var parseRow = new Function('columns', 'parser', code);
    

Of course, this depends on how often the parseRow function is created...

~~~
mistercow
That might be an improvement, but you probably wouldn't want to use Array.map,
which generally has pretty terrible performance. See <http://jsperf.com/map-
vs-native-for-loop/5>

~~~
rb12345
Yes; the only reason for using Array.map() here is conciseness and similarity
to the original code.

------
pmiller2
I'll just leave this here: <http://c2.com/cgi/wiki?FasterThanCee>

------
username_taken
This is only part of the picture. This version of the driver is much slower
than the driver based on libmysqclient. See the benchmarks at the bottom. It's
a more real world test combining both reads and writes.

<https://github.com/mgutz/mapper>

------
overbroad
"Faster than C" seems to imply that the author is not seeing the true value of
C. It is more than just speed.

You can only build so much with Javascript.

With C, the possibilities are limitless.

For a specific task like parsing, use whatever language you want. But please
do not believe that by knowing Javascript you can both dismiss C as an optimal
language and that you can build anything. You can't, as to either. As it
stands, by relying on Javsacsript you're restricted to a browser or Node.js
and whoever controls the browser and Node.js effectively has final control
over your opportunitities. What's the browser written in? Javascript? What is
Node.js written in?

Who cares if your parser is faster than C? If it's "fast enough", that's all
that matters. Users of big, complex, graphical browsers or mySQL databases are
well accustomed to slow speeds. They have learned how to wait.

~~~
icebraining
Technically, you can write anything in JavaScript, for the simple reason you
can manipulate bytes arbitrarily (using Typed Arrays), and platforms like
NodeJS and Rhino let you write those bytes to a file and execute it, so you
could (in theory) write a x86 compiler in JavaScript and run the result
without ever dropping to C.

As an existing example, PyPy -a Python JIT compilter- is itself written in a
subset of Python.

In the browser case, it's true that your JavaScript is restricted, but C is
even more restricted: it doesn't run at all! (NaCl excluded)

~~~
overbroad
Does Javascript run outside the browser and outside of a platform like
Node.js? I want stuff that can run on bare metal as well as on top of other
code (software platform).

Personally, I don't care about browsers. One application of a gazillion
possible applications. They are an afterthought. I care about sockets and the
ability to connect a machine to other machines over a network.

I care about code that can boot a computer, code that can be used to write
drivers to control hardware (maybe some new hardware that just hits the
market), and code that let's us build on top of that. With this code we should
be able to build a kernel and userspace utilities and thereby manage to
operate the hardware. Once everything is up and running, then we can install
any scripting language we want. We don't have to use the same language we used
to build the system to do any work after that, but we could. Indeed many
higher level things are written in C, e.g., the interpreters for languages
like JavaScript and the web browsers they are a part of. Maybe there's a
reason for that?

If the best code for building from the ground up on any given piece of
hardware is Javascript, it's news to me. Any examples? I have a new piece of
hardware. Can I boot it using JavaScript? Can I control the hardware with
JavaScript?

I believe the OP just wanted to do parsing in userspace. Personally I use C
for that (generated from flex), but there are countless languages that can do
parsing. Why he chose to attack C I have no idea. Like I said, once the
computer is up and running (thanks to C), we can use any language we like. We
can run "web browsers", and software platforms. And JavaScript. So, have fun
with your JavaScript. But I'm pretty sure C isn't going away anytime soon.

~~~
icebraining
Nobody attacked C, not me, not the author. If you disagree, please be so kind
to indicate the excerpt where he attacks it.

Interpreters and kernels are written in C because C is a great, and probably
the best language for the job. That doesn't mean, and this was my only point,
that it's the only possible language that can ever do that; it isn't.

 _If the best code for building from the ground up on any given piece of
hardware is Javascript_

Where did _anyone_ say that? I didn't say that. The author didn't say that.

As far as I'm concerned, JavaScript is not the best code for anything except
pushing code to the browser.

The only thing I said was that _technically_ , you can write JS to do it.
That's all.

 _Can I boot it using JavaScript? Can I control the hardware with JavaScript?_

The only thing that can control the hardware is machine code. You can control
the hardware with anything that can generate that. JavaScript can, therefore
_in theory_ you can control the hardware with it. Doesn't mean it's a good
idea. Doesn't mean it's better than C. Nobody ever claimed that.

 _But I'm pretty sure C isn't going away anytime soon._

No, it must certainly won't, and thank $DEITY for that.

~~~
overbroad
ice: "Nobody attacked C, not me, not the author. If you disagree, please be so
kind to indicate the excerpt where he attacks it."

author: "So fuck - maybe it's time to finally give up and accept that I cannot
compete with a well engineered C binding. C must be faster after all.

Well - fuck this! This is unacceptable. Fuck this "C is the only choice if you
want the best performance" type of thinking. I want JavaScript to win this.
Not because I like JavaScript, oh it can be terrible. I want JavaScript to win
this because I want to be able to use a higher level language without worrying
about performance."

ice: "As far as I'm concerned, JavaScript is not the best code for anything
except pushing code to the browser."

We are in 100% agreement then.

Sure, technically (i.e. by creating a language using a lexer+aprser and some
primitives in asm), any language could be used for any purpose. The reason I
said what I said about JavaScript being limited is that it was not designed
that way, i.e. to do anything. It was as you state, designed to run in a web
browser. I would love to use JavaScript from, e.g. the command prompt, outside
of a browser, but it has never been easy to do that without pretending you are
running a web browser (learning DOM an so forth). The language is designed for
a browser. Is that a limitation? To me, yes.

C does not have that sort of limitation. That's all I'm saying. And C works
for many purposes right now - my OS has a vast library of C functions to do
all manner of things low and high level. And that's without even looking at
other huge repositories on the web. Compare this with mere "theoretical"
capabilities, e.g. ideas like "low level JavaScript".

I told you why I like C and why I see JavaScript as limited. Not to contradict
anything you said, but to explain where I'm coming from. Maybe I would like
JavaScript even more than C, if I explored it more fully, but there's no way
I'll like it more when it is so limited in what it can do (practically, not
theoretically). I approach computer languages from a practical standpoint. I
ask myself what can I do if I learn this language? I concluded that for me, C
opens more doors, many more doors, than JavaScript. Some people know both. But
I'm not that smart. I have to choose.

If I was smart, I'd learn many languages. But I have to work with a smaller
set of knowledge.

Given that I have to choose, truthfully, if I had my preference, I'd choose
FORTH and devote all my effort to learning and writing in FORTH. Technically
anything is possible using FORTH. So what? By focusing only on FORTH I would
be losing all the leverage that people's work with C can offer. There is only
so much I, with my limited smarts, could accomplish.

Certainly you can understand my position a little, can't you? Why do so many
people love Perl and Python? If we took away all the libaries (=enablement,
empowerment) would they still love them as much? For what I want to do (i.e.
potentially anything, from booting to browsing), C gives me ample enablement
and empowerment. Self-hosting JavaScript doesn't. And if someone writes a BIOS
for ARM scriptable in JavaScript, but they write some part of it in C, well,
I'm still going to want to learn C before JavaScript. That's just how I think.

~~~
icebraining
I don't think those excerpts show any attack on C, he just doesn't like that
he can't use higher level languages without sacrificing performance. Which is
a position that you may disagree with, but I don't think it's an attack on C.

 _would love to use JavaScript from, e.g. the command prompt, outside of a
browser, but it has never been easy to do that without pretending you are
running a web browser (learning DOM an so forth). The language is designed for
a browser._

I don't think there's anything in the language itself that is designed for the
browser; it's just the standard library that is lacking.

The Rhino shell, for example, comes with functions like readFile/2 and
runCommand/N which are much more adequate for that kind of programming.

But it's certainly not as useful as C, and I certainly don't use. Though I
tend to use Python, not C either (ctypes is _awesome_ ).

 _C does not have that sort of limitation. That's all I'm saying. And C works
for many purposes right now - my OS has a vast library of C functions to do
all manner of things low and high level. And that's without even looking at
other huge repositories on the web. Compare this with mere "theoretical"
capabilities, e.g. ideas like "low level JavaScript"._

Sure; I don't think anyone denies that.

That said, it's not true that those functions are closed to you if you use
JavaScript; check out node-ffi: <https://github.com/rbranson/node-ffi>

Running JS on bare metal is, at the moment, a pipe dream, though.

 _Certainly you can understand my position a little, can't you? Why do so many
people love Perl and Python? If we took away all the libaries (=enablement,
empowerment) would they still love them as much? For what I want to do (i.e.
potentially anything, from booting to browsing), C gives me ample enablement
and empowerment. Self-hosting JavaScript doesn't. And if someone writes a BIOS
for ARM scriptable in JavaScript, but they write some part of it in C, well,
I'm still going to want to learn C before JavaScript. That's just how I
think._

Sure, I can understand your position perfectly. I just don't think your
portrayal of the article was fair to the author, that's all.

------
philhippus
An equivalent claim: Faster than Assembly? Parsing binary data in JavaScript.
Pah.

------
chmike
Check the code : <https://github.com/felixge/node-mysql>

Note: it uses node_buffer.cc which is some C++ code in node. So it is not
exactly pure Javascript.

------
afhof
Why does everyone keep saying Doing X in Language Y is faster than X in
Language Z?

Really they are comparing compilers, not languages. Everyone seems to just
keep making potshots at Language Z.

------
goggles99
Please stop with the X higher level language can be faster than C unless you
can challenge the limitations imposed by the laws of physics. Not which
compiler is better. I can always find a better or worse C or JS
compiler/JITter so that proves nothing.

Doing more (Which all more highly abstracted languages currently do) in less
time with all else being the same is not possible as we understand quantum
physics today.

This title is clearly linkbait...

~~~
rat87
> Please stop with the X higher level language can be faster than C unless you
> can challenge the limitations imposed by the laws of physics. Not which
> compiler is better. I can always find a better or worse C or JS
> compiler/JITter so that proves nothing.

Turing equivalence and not even turing equivalence but 2 pieces of code with
roughly the same functionality does not dictate the speed between them. You
seem to be under some sort of misconception that two pieces of code have to be
implemented in the same. For a long time tcl led the computer language
shootout regex test because it has a wicked fast regex library(written in c I
think). Nowadays the c version of that test uses the tcl regex library and is
beaten by v8(chrome) javascript's even faster regex library(written in c++).

It is hard to beat c in speed and it is rare when something implemented in a
different language does it. When it does it is frequently do to the
algorithm/way it was implemented. The reason that this is so is that few
people care enough about beating c with c++ being the only real contender. if
you are careful you can beat c code with c++(almost all c++'s slower features
do not slow it down if not used) add that to some cool compile time tricks
with template metahackery and c++'s better inlining and you can do it.

The other part about beating c is complexity. Certain things are complex to
implement in c. There is a reason we use so little assembly anymore, it's
possible for smart people to beat optimizing compilers for certain cases but
the general case isn't so pretty for it. Also with the rise of more/cheaper
memory for gc to work well(and when it does it goes like hell on wheels) and
parallel computers(parallelism being much easier in some languages then c) we
may see it more soon. People have been saying that for a while but still.

~~~
goggles99
_> Turing equivalence and not even turing equivalence but 2 pieces of code
with roughly the same functionality does not dictate the speed between them.
You seem to be under some sort of misconception that two pieces of code have
to be implemented in the same_

I am merely pointing out that there is overhead with every VM. This is
especially true with every current JITted JavaScript in use today (more so
than with the JVM and CLR). So how could it possibly be faster if both
implementations use an equal amount of optimization otherwise.

How is this even ever an argument?

~~~
rat87
> So how could it possibly be faster if both implementations use an equal
> amount of optimization otherwise.

Who says they are?

~~~
goggles99
Anyone who says that JS or X other VM dependent language can be faster than C
must say this to have a leg to stand on.

They cannot say this??? Thus my point...

------
camus
INFLAMMATORY headline for self-branding and publicity , doesnt go much
further. Yes javascript can be fast but in the end , having to write evals to
gain performances demonstrate that there is something really wrong with that
langage...

~~~
ben0x539
I disagree!! Being able to use evals to dynamically generate code for unrolled
loops (and other similarly specialized procedures) sounds like a pretty
amazing tool, and I can't not consider having it readily available an
advantage of Javascript compared to C.

------
goggles99
Um every fast and decent JS engine IS WRITTEN IN C!!!

I refuse to click on anything as ridiculous sounding as "Faster than C?
Parsing binary data in JavaScript".

 _JavaScript will NEVER be faster than C._ If you personally test it and it is
- all that you have really proven is that the C compiler you are using was
horribly written and is probably 20+ years old. The level of ignorance that
programmers have about low level languages and the performance cost of
abstractions amazes me sometimes.

~~~
tptacek
This is a very silly point of view. What you think you're arguing is that
Javascript can't conceivably be faster than native code, and you're conflating
C with native code. But C isn't machine code either; like Javascript, it's
transformed into machine code by a compiler.

I don't generally think that Javascript runtimes are going to routinely beat C
compilers for most performant execution of basic programs any time soon, but
I'd happily bet that some high level language JIT is going to give C a real
run for its money sometime soon. That JIT will inevitably be expressible in C,
but when your recourse as a C programmer is "implement the important parts of
the JIT for language X, then proceed to solve your real problem", you're not
making much of a case for C.

~~~
goggles99
I am not even close to conflating C with native code (although it is the
lowest level language next to Assembly). C is the lowest level structured
language and JS is among the highest. The fact that they are both ultimately
compiled to a processor level binary means very little.

Since it seems so simple and plausible that a high level JITted language can
be on par with C, why did you not explain how?

You cannot because you clearly don't understand language compilation and the
laws that exist between performance and abstractions - so I am confused by
your argument.

Let me put it simply, take any two languages - both ultimately compile to
machine code, one has the overhead of bounds checking, run-time type
resolution and garbage collection (there is actually much more that I could
mention but for brevity...) and the other does not. Now please explain to me
how the one WITH all this overhead could possibly be faster?

There is only one way - If the C compiler were egregiously under-optimized.

This will be the case till the end of time. All other things being equal, the
executable code with more overhead to slow it down will lose. This seems a
very simple concept to me - I cannot understand how it is so hard to grasp.
Perhaps it is because along side learning Java, HTML and JavaScript - I also
learned Assembly Language, C, C++ and hardware architectures.

~~~
tptacek
"C is the lowest level structured language and JS is among the highest."

What does this even mean?

Ten message board style points for assuming that anyone who disagrees with you
must not know C.

~~~
goggles99
If you or anyone does not know what a high/low level or structured language
means - that is fine.

But WHY would you attempt to make arguments that require basic understanding
of such things.

~~~
andoriyu
How about you stop calling "C" a low level language?

~~~
goggles99
That you for the valuable response - BTW I only claimed that it was the lowest
level structured language.

~~~
tptacek
Which is also a silly claim.

------
andoriyu
And not a single word about DTrace?

------
sneak
Thousands of words about optimizing the reinvention of a wheel.

I thought we were hackers? We use libmysqlclient and stfu because we don't
give a shit what language a client library is in because it WORKS and isn't
unacceptably slow and LETS US SHIP.

I really dislike this whole crowd and attitude.

~~~
LnxPrgr3
Reinventing the wheel is a good thing when what you get is a better wheel, or
even just one better suited to your purpose.

Ever notice we're not driving cars on ox cart wheels?

~~~
gruseom
As someone once brilliantly (I thought) put it on HN: has anything ever needed
more reinventing than the wheel?

