The Windows API is so broad, so deep, and so functional that most ISVs would be crazy not to use it. And it is so deeply embedded in the source code of many Windows apps that there is a huge switching cost to using a different operating system instead...
It is this switching cost that has given the customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO, our lack of a sexy vision at times, and many other difficulties [...] Customers constantly evaluate other desktop platforms, [but] it would be so much work to move over that they hope we just improve Windows rather than force them to move.
In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago.
In 2002, Be Inc. sued [4] Microsoft claiming that Hitachi had been dissuaded from selling PCs loaded with BeOS, and that Compaq had been pressured to not market an Internet appliance in partnership with Be. BeOS also claimed that Microsoft acted to artificially depress Be Inc's IPO. The case was eventually settled out of court[5] with no admission of liability on Microsoft's part.
I frequently think of the behaviors I see in terms of human behavior and human emotional responses even though I know that they are wrong. The motivation and perception of a pig is incredibly different from that of a human, even a child at a similar level of intellectual development. The perfect person to readup on to learn about how fundamentally damaging the "anthropomorphic" view is to our understanding of animals is Temple Grandin.
Science has shown that animals such as mammals and birds feel pain in a manner similar to humans. Insects, viruses and microbes are not able to feel pain or suffer. More research is needed to determine the extent that fishes and amphibians feel pain. Present research shows that they do experience fear. Fear is very aversive and animals should be shielded form situations that cause great fear. Fear will cause a great rise in stress hormones. [...] When the structure of the brain and nervous system is studied, there is no black and white line between people and higher mammals such as chimps, dogs or cows. [...] As nervous system and brain complexity increases the welfare needs of the animal increase and become more complex, but all animals that have sufficient nervous systems complexity to suffer from either pain or fear need basic welfare protections. Animals with complex brains also have greater social needs and a need for greater environmental enrichment. [...] It is obvious to me that intelligent animals such as elephants experience emotions that are more complex than simple pain or fear. They will need different legal protections than animals with simpler nervous systems. The degree of protection, and environmental and social enrichment an animal will require will be dependent on the level of complexity of its nervous system.
Her opinions do not support your assertion that "the motivation and perception of a pig is incredibly different from that of a human," or that animals do not resemble human behavior or emotional responses.
Whoa, don't blow my mind quite so hard. I'm not sure I can handle all this wisdom at the same time.
C'mon, you think I execute shell commands by writing a C program that calls fork(), exec(), and pipe()? You think I write web pages pixel by pixel? Obviously high-level languages and programming paradigms are appropriate in many cases.
I'm sticking it to the Java weenies who think that C and C++ are obsolete. The people who year after year say that *now* Java is "often as fast as C++ and sometimes faster." The people who still won't acknowledge that there is a real reason C and C++ are still the languages of OS kernels.
It's not premature optimization to write libavcodec in C. Likewise with OS kernels, virtual machines, rendering engines, DSP plugins, and many other applications where the code will almost certainly be on the critical path of a resource-intensive application. It's not premature optimization to use manual memory management in applications that need to move lots of data around with low latency.
This is why I never understand how people can say "sure, maybe Java/garbage-collection/50mb-binaries/etc. are a little slower, but computers are SO FAST these days and programmer productivity is SO much more important. Hardware is cheap, programmers are expensive." etc.
Stephen Joyce to a James Joyce scholar he disagreed with: "You should consider a new career as a garbage collector in New York City, because you'll never quote a Joyce text again."
Your "abstract solutions" all take orders of magnitude more memory than C, and still suffer garbage collection pauses.
Why isn't your web browser written using these "abstract solutions"? The answer is the same reason that having real machine code on the client is a win, for those who want to go to the trouble.
But the killer thing here is that MapReduce says absolutely nothing about the updates problem.
That's because MapReduce is a data processing system, not a data storage system. You should read about BigTable, which is the data storage system we use (I work at Google), which does support updates.
In your comments on this thread, I think you miss the key difference between an RDBMS and a system like BigTable. BigTable is almost perfectly horizontally scalable. When you need more capacity, it really is as simple as throwing more machines at the problem.
RDBMS's can never give you this kind of horizontal scalability, because they make a promise to you that you can transactionally modify any two bits of data anywhere in your database. Fulfilling this promise requires that either your whole database lives on a single machine, or that you use a distributed transaction protocol like 2PC (which totally kills performance).
So when your database gets busier than a single machine can handle, you have to manually partition your database into multiple physical databases. All the nice RDBMS features like transactions, joins, foreign keys, triggers, etc. can only (reasonably) work within a single physical database. The divide between physical databases is something your application code has to deal with -- it has to know to direct its queries to the correct partition. And repartitioning your data to run on more machines later is an invasive procedure, both operationally and to your application's code.
BigTable is designed around the reality that a database of any significant size will need to run on more than one machine. It only guarantees that you can transactionally modify data within a single row. This gives BigTable the ability to move rows around between machines without the application even knowing this is happening. If you add more machines, BigTable can immediately start moving some subset of your rows onto this new machine.
I recommend reading this paper for a far more in-depth look at this pattern. The key point of this paper is:
A scale-agnostic programming abstraction must have the notion of entity as the boundary of atomicity.
Maybe in your field, but these are by no means universal.
There's a point where your software is running on enough machines at the same time that the developer cost of optimizing it is cheaper than the hardware cost of buying more machines.
Just because you've never worked in a situation where this was the case doesn't mean it doesn't exist.
Get over the victim complex. How about the fact that Obama and Joe talked for over five minutes, during which Obama mentioned that Joe would get some tax decreases from his plan (like for health care and capital gains). The phrase "spread the wealth around" doesn't come until almost five minutes into the exchange, but if you listen to the story according to the mainstream media, the exchange went something like this:
Joe: So Obama, why you gonna raise my taxes? Obama: Well Joe, I believe in spreading the wealth around. Deal with it!
Every fucking story reporting this - other than Fox News, of course - was attacking Joe for not having a permit/license (a revenue-raising device by greedy cities), for owing taxes, rather than actually addressing the merits of the question Joe had the temerity to ask.
Oh really? So you're saying that every result from a google news search of spread the wealth around is Fox News?
Whatever, I now return you to your regularly scheduled victim complex.
Maybe you just forgot to mention that while LuaJIT speeds up Lua execution, it also doubles its startup time.
I can't replicate that result on my box (see measurements below). But even if it's true, doubling is insignificant if you're starting at between 1-10ms to startup.
Here are the results I get on my box (OS X Leopard):
$ time java Hello hello, world!
real 0m0.145s user 0m0.080s sys 0m0.045s
$ time lua hello.lua Hello, world!
real 0m0.005s user 0m0.001s sys 0m0.003s
$ time./luajit hello.lua Hello, world!
real 0m0.005s user 0m0.001s sys 0m0.003s
Lua and LuaJIT are indistinguishable, and both are either 29x or 80x faster than Java, depending on whether you're measuring by real time or user time.
The JVMs JIT however, doesn't affect startup time at all.
Umm, this supports my point, which is that the JVM sucks for its own reasons, and that having a JIT doesn't imply being as resource-hungry as the JVM.
When comparing the relative performance improvements of the JITs, note that the JVM is playing in an entirely different league performance-wise, JIT [debian.org] or not [debian.org].
I think that a good programmer would know when to choose Lua and when to choose the JVM. He would probably be able to argue for and against each option and decide which one is better suited for a particular case.
How very mature of you. I love how you've taken my original argument which was nothing more than "JITs don't have be slow-starting memory hogs" as an argument that Lua is always better than the Java on the JVM. That would be a stupid argument, because there are clearly times when you want a static language with its associated performance characteristics. I happen to think the JVM sucks, but that doesn't mean that I think Lua is always the most appropriate alternative.
Umm, Lua is a language where global variable references and method calls require hash table lookups, where you can hook your own code into primitive operations like table reads and writes, and where primitive operations like binary operators have to check the types of their arguments at runtime (possibly performing implicit conversion). Java on the other hand knows the types of all data at compile time and can perform all method dispatch with a single pointer dereference.
This point is not whether Java is faster than Lua, the point is that a JIT doesn't have to allocate enough memory to fill a 1987-sized hard drive just to run "Hello, World."
Because really, Java's design makes it very close in features to something like D. But should JIT compiling really make the runtime take 3-18x as much RAM??
The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.
That JITs automatically incur large memory footprint or startup time penalties is the logical conclusion you come to if you look at the JVM. But the truth is that JITs don't have to suck as much as the JVM does.
I've never looked at the source for the JVM, so I can't say just why it takes so many resources, but I can only conclude that it's because Sun just doesn't consider startup time or memory footprint a priority.
I'm with you, except that I lament that the only way to get the "boxes and springs" tabular model that has been used by pretty much every UI ever invented is to use tables for layout. Which gets you crucified by the web standards crowd. The options that CSS gives you are a sad joke in comparison: in CSS, even creating a layout of three divs in non-overlapping columns is an art. Don't even think about trying to give it rows!
It seems they are being bitten in the rear by their home-grown proprietary inventory management system.
Because definitely if they had used another company's product or something open source, it could never have broken. Clearly being "home-grown" and "proprietary" is the part that caused the problem.
Really? In that case, I am defining a format for specifying series of integers. Here's how it works: for every integer, you find the corresponding prime (eg. for the number 5 you find the 5th prime). Then for every pair of numbers, you multiply them together, and emit the product into the output file. To parse, all you have to do is find each product and factor it into its two primes.
According to you, my format cannot have a speed. It is a format; it has no speed. So please write me a parser that parses my format into the original integers and is comparably fast to other formats (on a byte-by-byte basis).
You think it's a "mistake of the past" that Google wrote things like GFS and BigTable that run on commodity hardware, scale basically horizontally (eg. you can just throw machines at the problem) and survive machine failures without human intervention?
You don't "improve" on an existing tool like a relational database by adding a "feature" like fault tolerance. You have to redesign from the base up with those assumptions.
I do not speak for Google, but wanted to throw in a Googler's opinion. Here in Google Seattle (and Google Kirkland) we have tons of ex-Microsoft people. I was recently having a conversation with another Googler who has been here longer than me and we were musing about how neither of us knew of anyone who had gone the other way. Then this (non-)story breaks of one guy goes GOOG->MSFT, and my Googler friend sent me an email that said "well, now we know of someone who went in the opposite direction."
So whatever, one guy goes to Microsoft from Google Seattle when tons have gone the other way. But somehow this became a whole news cycle. One Microsofter called it "an exodus" (that's right, one guy plus anonymous unspecified other people is an "exodus"). I've tried to resist the urge to say anything, but come on. There is no exodus.
One thing to keep in mind is that Sergey Solyanik (the guy who started this whole news cycle) went back to Microsoft to be a Dev Manager. If what you want is to be a Dev Manager in the traditional sense (steering the course of a project top-down), I can see why you might leave Google -- management is totally different here. It's a very engineering-driven, bottom-up culture. Apparently that didn't work for Sergey. More power to him for recognizing that, and going to the place that works better for him.
But if you're an engineering-focused person like me, Google is a mind-blowingly awesome place to work.
To summarize: no, the tide is not turning on Google being an awesome place to work. Yes, Google is still awesome for people that fit its culture. No, there is not an "exodus." Yes, one guy left Google for Microsoft but many many people have gone the other direction. No, Google is not perfect. Yes, I do truly regret if a person has a bad experience interviewing here or if they get bad attitudes from anyone, but most of the people I know here are a pleasure to work with and very smart.
If I knew that my 21-year-old self was going to be reading this message, I would tell him: "yes, Google is exactly where you want to end up." I've worked at a couple of other places and had a good time, but Google is a perfect match for me.
(I'm not really interested in dignifying responses from bitter people who have a bone to pick with Google for whatever reason.)
"Linux images" is not a meaningful measure of computing resources. Things like bytes of RAM, bytes of disk space, and megahertz of CPU are.
The smallest Linux image can run in 8MB of RAM, so if I get 100 servers with 64GB of RAM I could theoretically fire up 800,000 Linux images on them. Does this mean my 100 servers are as powerful as your five z10s?
Very interesting project. Thanks!
I did not see any examples of how, say, 2 different languages can bind to the canonical grammar engine gazelle produces. Is there going to be an API for each supported language to bind actions to code in the host language? Yes. And rather than using something like SWIG, I want a lot of thought to go into each language's binding, so the interface is really idiomatic for each language.
For a look at my very preliminary version of the C api, check out this program that is built on Gazelle 0.1. Check out the "register_callback" calls in this source file:
As this gets more sophisticated, I want to use CSS selectors and/or XPath as a model for specifying the predicates for when callbacks are called. For example, imagine being able to specify callbacks like so:
register_callback("str_frag:unicode_char", callback);// call me when "unicode_char" is seen inside a str_frag rule register_callback("> object", callback);// call me when object is seen, but only at the top level
I would encourage anyone who is interested in parsing or ANTLR to follow my project Gazelle. It is intended to be a next-gen parsing framework that builds on the ideas set forth in ANTLR but packages them in a significantly different way, which offers a lot of benefits (which I list in detail on the website).
The primary thing I am trying to deliver is reusability of parsers. The open-source community should be able to cooperate to write canonical parsers for all popular languages, but this goal is hampered by the fact that almost all parsing tools (ANTLR included) encourages you to write non-reusable grammars by virtue of the fact that you embed actions into the grammar.
Gazelle also takes a interpreter+JIT approach instead of emitting code in an imperative language. So for example, if you want a really fast HTTP parser from Ruby (which is precisely the raison d'etre for Mongrel), you can use the HTTP Gazelle parser from Ruby, but since the parsing is actually performed by the interpreter+JIT (written in C), you get extremely fast parsing without writing a line of C.
Gazelle is still very immature and not ready for people to try out, but I would encourage anyone who's interested to follow the Gazelle category on my blog.
I am a die-hard C and C++ advocate. I consider it a high priority to make sure that the JVM and.NET aren't the de facto future of all computing, which seems like more and more of a risk when you see things like Singularity OS, which is an OS where all application code must be managed code. These managed code people go nuts and think that everything should be managed.
The current generation of managed code VMs clearly have some benefits. But but they fall far short on some of the key properties that make C and C++ so powerful. Even if I grant you that the JVM and.NET have caught up to C and C++ in speed (which I still don't believe has been demonstrated), it's undeniable that
VMs have comically bloated memory footprints: between 2x and 30x comparable C programs according to benchmarks: JVM, Mono. Even if you consider memory cheap, smaller is always better because it means fewer bits flying over the bus and better cache utilization.
VMs stop the world to do garbage collection. Point me to all the articles you want that explain how "it's getting better" and "they've figured out how to make it real-time," but that doesn't change the fact that you're stopping all threads whenever you garbage collect, which is making your latency suffer.
C and C++ are the only game in town for getting the best performance and a small memory footprint and the ability to have the lowest possible latency.
That said, I think that C and C++ are becoming harder to justify when you consider the havoc that memory errors can wreak. It's highly embarrassing to vendors and damaging to their customers when a buffer overflow exploit is discovered. malloc and free, even when used correctly, can still have some forgotten downsides like the memory fragmentation that was discovered in Firefox 2, and took some very smart people a lot of work to address.
What I would like to see is a language that gives the benefits of C and C++ (extremely fast, extremely small memory footprint, and no GC pauses) but that is also immune to C and C++'s weaknesses (memory corruption, memory leaks, memory fragmentation). Yep, I pretty much want to have my cake and eat it too. Why do I think this is possible? I think that the future is to have a fully concurrent, compacting GC. Everyone's telling us we're going to have more cores than we know what to do with soon, right? Well why not use all those extra cores to do GC in the background? Even if it's more expensive on the whole, we barely know what to do with all those extra cores as it is. With this strategy, you could get the performance guarantees and low overhead of C and C++ (on the real, non-GC thread, that is) without having to give up GC or suffer from memory fragmentation.
I'm also not willing to give up the option of dropping to C or C++ (or even assembly language) when it's justified. Mention JNI in a room of Java people and observe them reel in horror -- it's culturally shunned to deviate from "100% pure Java." Maybe this is a good value when you're on a big team of people writing a web app, but for systems and multimedia programming this is silly -- inner loops are inner loops, and some of them can benefit from machine-specific optimization.
Theoretically you could experiment with the fully concurrent GC using an existing language/runtime like Java, but I've sort of given up on the JVM and.NET communities, because they have empirically demonstrated that they culturally have no regard for small memory footprint, low overhead, short startup time, etc. They just don't consider huge memory footprint or ridiculous startup times a problem. This is not to ment
Slashdot Mirror
Based on their merits?
The Windows API is so broad, so deep, and so functional that most ISVs would be crazy not to use it. And it is so deeply embedded in the source code of many Windows apps that there is a huge switching cost to using a different operating system instead...
It is this switching cost that has given the customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO, our lack of a sexy vision at times, and many other difficulties [...] Customers constantly evaluate other desktop platforms, [but] it would be so much work to move over that they hope we just improve Windows rather than force them to move.
In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago.
--Internal Microsoft memo drafted for Bill Gates, Feb 21, 1997
In 2002, Be Inc. sued [4] Microsoft claiming that Hitachi had been dissuaded from selling PCs loaded with BeOS, and that Compaq had been pressured to not market an Internet appliance in partnership with Be. BeOS also claimed that Microsoft acted to artificially depress Be Inc's IPO. The case was eventually settled out of court[5] with no admission of liability on Microsoft's part.
--Wikipedia page about BeOS
I frequently think of the behaviors I see in terms of human behavior and human emotional responses even though I know that they are wrong. The motivation and perception of a pig is incredibly different from that of a human, even a child at a similar level of intellectual development. The perfect person to readup on to learn about how fundamentally damaging the "anthropomorphic" view is to our understanding of animals is Temple Grandin.
From what I have read, Temple Grandin does not support your arguments. From her essay Animals Are Not Things: A View on Animal Welfare Based on Neurological Complexity:
Science has shown that animals such as mammals and birds feel pain in a manner similar to humans. Insects, viruses and microbes are not able to feel pain or suffer. More research is needed to determine the extent that fishes and amphibians feel pain. Present research shows that they do experience fear. Fear is very aversive and animals should be shielded form situations that cause great fear. Fear will cause a great rise in stress hormones.
[...]
When the structure of the brain and nervous system is studied, there is no black and white line between people and higher mammals such as chimps, dogs or cows.
[...]
As nervous system and brain complexity increases the welfare needs of the animal increase and become more complex, but all animals that have sufficient nervous systems complexity to suffer from either pain or fear need basic welfare protections. Animals with complex brains also have greater social needs and a need for greater environmental enrichment.
[...]
It is obvious to me that intelligent animals such as elephants experience emotions that are more complex than simple pain or fear. They will need different legal protections than animals with simpler nervous systems. The degree of protection, and environmental and social enrichment an animal will require will be dependent on the level of complexity of its nervous system.
Her opinions do not support your assertion that "the motivation and perception of a pig is incredibly different from that of a human," or that animals do not resemble human behavior or emotional responses.
Want proof? Ctrl+U.
Whoa, don't blow my mind quite so hard. I'm not sure I can handle all this wisdom at the same time.
C'mon, you think I execute shell commands by writing a C program that calls fork(), exec(), and pipe()? You think I write web pages pixel by pixel? Obviously high-level languages and programming paradigms are appropriate in many cases.
I'm sticking it to the Java weenies who think that C and C++ are obsolete. The people who year after year say that *now* Java is "often as fast as C++ and sometimes faster." The people who still won't acknowledge that there is a real reason C and C++ are still the languages of OS kernels.
It's not premature optimization to write libavcodec in C. Likewise with OS kernels, virtual machines, rendering engines, DSP plugins, and many other applications where the code will almost certainly be on the critical path of a resource-intensive application. It's not premature optimization to use manual memory management in applications that need to move lots of data around with low latency.
Chrome got me where it matters most - raw speed.
This is why I never understand how people can say "sure, maybe Java/garbage-collection/50mb-binaries/etc. are a little slower, but computers are SO FAST these days and programmer productivity is SO much more important. Hardware is cheap, programmers are expensive." etc.
Speed still matters! And it always will.
The stuff in the linked articles is nothing, read this: The Injustice Collector: Is James Joyce's grandson suppressing scholarship?
Stephen Joyce to a James Joyce scholar he disagreed with: "You should consider a new career as a garbage collector in New York City, because you'll never quote a Joyce text again."
It does freeze during rendering and downloading. Simple way to reproduce: navigate to a 100MB file and see what happens to the UI.
FLAC is years older than Apple Lossless. FLAC was sitting out there for the taking when Apple decided to implement their own.
Your "abstract solutions" all take orders of magnitude more memory than C, and still suffer garbage collection pauses.
Why isn't your web browser written using these "abstract solutions"? The answer is the same reason that having real machine code on the client is a win, for those who want to go to the trouble.
A couple addenda to my last post:
But the killer thing here is that MapReduce says absolutely nothing about the updates problem.
That's because MapReduce is a data processing system, not a data storage system. You should read about BigTable, which is the data storage system we use (I work at Google), which does support updates.
In your comments on this thread, I think you miss the key difference between an RDBMS and a system like BigTable. BigTable is almost perfectly horizontally scalable. When you need more capacity, it really is as simple as throwing more machines at the problem.
RDBMS's can never give you this kind of horizontal scalability, because they make a promise to you that you can transactionally modify any two bits of data anywhere in your database. Fulfilling this promise requires that either your whole database lives on a single machine, or that you use a distributed transaction protocol like 2PC (which totally kills performance).
So when your database gets busier than a single machine can handle, you have to manually partition your database into multiple physical databases. All the nice RDBMS features like transactions, joins, foreign keys, triggers, etc. can only (reasonably) work within a single physical database. The divide between physical databases is something your application code has to deal with -- it has to know to direct its queries to the correct partition. And repartitioning your data to run on more machines later is an invasive procedure, both operationally and to your application's code.
BigTable is designed around the reality that a database of any significant size will need to run on more than one machine. It only guarantees that you can transactionally modify data within a single row. This gives BigTable the ability to move rows around between machines without the application even knowing this is happening. If you add more machines, BigTable can immediately start moving some subset of your rows onto this new machine.
I recommend reading this paper for a far more in-depth look at this pattern. The key point of this paper is:
BigTable calls such entities "rows."
Maybe in your field, but these are by no means universal.
There's a point where your software is running on enough machines at the same time that the developer cost of optimizing it is cheaper than the hardware cost of buying more machines.
Just because you've never worked in a situation where this was the case doesn't mean it doesn't exist.
Get over the victim complex. How about the fact that Obama and Joe talked for over five minutes, during which Obama mentioned that Joe would get some tax decreases from his plan (like for health care and capital gains). The phrase "spread the wealth around" doesn't come until almost five minutes into the exchange, but if you listen to the story according to the mainstream media, the exchange went something like this:
Joe: So Obama, why you gonna raise my taxes?
Obama: Well Joe, I believe in spreading the wealth around. Deal with it!
Every fucking story reporting this - other than Fox News, of course - was attacking Joe for not having a permit/license (a revenue-raising device by greedy cities), for owing taxes, rather than actually addressing the merits of the question Joe had the temerity to ask.
Oh really? So you're saying that every result from a google news search of spread the wealth around is Fox News?
Whatever, I now return you to your regularly scheduled victim complex.
Perhaps, but that one has committed unforgivable crimes against spelling.
Maybe you just forgot to mention that while LuaJIT speeds up Lua execution, it also doubles its startup time.
I can't replicate that result on my box (see measurements below). But even if it's true, doubling is insignificant if you're starting at between 1-10ms to startup.
Here are the results I get on my box (OS X Leopard):
$ time java Hello
hello, world!
real 0m0.145s
user 0m0.080s
sys 0m0.045s
$ time lua hello.lua
Hello, world!
real 0m0.005s
user 0m0.001s
sys 0m0.003s
$ time ./luajit hello.lua
Hello, world!
real 0m0.005s
user 0m0.001s
sys 0m0.003s
Lua and LuaJIT are indistinguishable, and both are either 29x or 80x faster than Java, depending on whether you're measuring by real time or user time.
The JVMs JIT however, doesn't affect startup time at all.
Umm, this supports my point, which is that the JVM sucks for its own reasons, and that having a JIT doesn't imply being as resource-hungry as the JVM.
When comparing the relative performance improvements of the JITs, note that the JVM is playing in an entirely different league performance-wise, JIT [debian.org] or not [debian.org].
This is entirely unrelated to my original point (which was that JITs don't inherently have to be resource pigs). But since I do pretty much hate the JVM I'll take the bait. I've already pointed out the reasons why Java is much more straightforward to optimize than Lua. If you want to compare apples to apples, compare a dynamic languages on the JVM with LuaJIT, like JavaScript Rhino vs. LuaJIT or Groovy vs. LuaJIT. On second thought you might not want to look, the results are kind of embarrassing.
I think that a good programmer would know when to choose Lua and when to choose the JVM. He would probably be able to argue for and against each option and decide which one is better suited for a particular case.
How very mature of you. I love how you've taken my original argument which was nothing more than "JITs don't have be slow-starting memory hogs" as an argument that Lua is always better than the Java on the JVM. That would be a stupid argument, because there are clearly times when you want a static language with its associated performance characteristics. I happen to think the JVM sucks, but that doesn't mean that I think Lua is always the most appropriate alternative.
Umm, Lua is a language where global variable references and method calls require hash table lookups, where you can hook your own code into primitive operations like table reads and writes, and where primitive operations like binary operators have to check the types of their arguments at runtime (possibly performing implicit conversion). Java on the other hand knows the types of all data at compile time and can perform all method dispatch with a single pointer dereference.
This point is not whether Java is faster than Lua, the point is that a JIT doesn't have to allocate enough memory to fill a 1987-sized hard drive just to run "Hello, World."
Because really, Java's design makes it very close in features to something like D. But should JIT compiling really make the runtime take 3-18x as much RAM??
The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.
That JITs automatically incur large memory footprint or startup time penalties is the logical conclusion you come to if you look at the JVM. But the truth is that JITs don't have to suck as much as the JVM does.
For example, take LuaJIT, a JIT for the already-speedy dynamic language Lua. It speeds up Lua roughly 2-5x while starting up in less than 0.01 CPU-seconds and introducing less than 20% memory overhead. It also takes 2-8x less memory and starts up 10x faster than the JVM, despite the fact that Lua is compiling from source, whereas the JVM starts with bytecode.
I've never looked at the source for the JVM, so I can't say just why it takes so many resources, but I can only conclude that it's because Sun just doesn't consider startup time or memory footprint a priority.
I'm with you, except that I lament that the only way to get the "boxes and springs" tabular model that has been used by pretty much every UI ever invented is to use tables for layout. Which gets you crucified by the web standards crowd. The options that CSS gives you are a sad joke in comparison: in CSS, even creating a layout of three divs in non-overlapping columns is an art. Don't even think about trying to give it rows!
It seems they are being bitten in the rear by their home-grown proprietary inventory management system.
Because definitely if they had used another company's product or something open source, it could never have broken. Clearly being "home-grown" and "proprietary" is the part that caused the problem.
Really? In that case, I am defining a format for specifying series of integers. Here's how it works: for every integer, you find the corresponding prime (eg. for the number 5 you find the 5th prime). Then for every pair of numbers, you multiply them together, and emit the product into the output file. To parse, all you have to do is find each product and factor it into its two primes.
According to you, my format cannot have a speed. It is a format; it has no speed. So please write me a parser that parses my format into the original integers and is comparably fast to other formats (on a byte-by-byte basis).
You think it's a "mistake of the past" that Google wrote things like GFS and BigTable that run on commodity hardware, scale basically horizontally (eg. you can just throw machines at the problem) and survive machine failures without human intervention?
You don't "improve" on an existing tool like a relational database by adding a "feature" like fault tolerance. You have to redesign from the base up with those assumptions.
I do not speak for Google, but wanted to throw in a Googler's opinion. Here in Google Seattle (and Google Kirkland) we have tons of ex-Microsoft people. I was recently having a conversation with another Googler who has been here longer than me and we were musing about how neither of us knew of anyone who had gone the other way. Then this (non-)story breaks of one guy goes GOOG->MSFT, and my Googler friend sent me an email that said "well, now we know of someone who went in the opposite direction."
So whatever, one guy goes to Microsoft from Google Seattle when tons have gone the other way. But somehow this became a whole news cycle. One Microsofter called it "an exodus" (that's right, one guy plus anonymous unspecified other people is an "exodus"). I've tried to resist the urge to say anything, but come on. There is no exodus.
One thing to keep in mind is that Sergey Solyanik (the guy who started this whole news cycle) went back to Microsoft to be a Dev Manager. If what you want is to be a Dev Manager in the traditional sense (steering the course of a project top-down), I can see why you might leave Google -- management is totally different here. It's a very engineering-driven, bottom-up culture. Apparently that didn't work for Sergey. More power to him for recognizing that, and going to the place that works better for him.
But if you're an engineering-focused person like me, Google is a mind-blowingly awesome place to work.
To summarize: no, the tide is not turning on Google being an awesome place to work. Yes, Google is still awesome for people that fit its culture. No, there is not an "exodus." Yes, one guy left Google for Microsoft but many many people have gone the other direction. No, Google is not perfect. Yes, I do truly regret if a person has a bad experience interviewing here or if they get bad attitudes from anyone, but most of the people I know here are a pleasure to work with and very smart.
If I knew that my 21-year-old self was going to be reading this message, I would tell him: "yes, Google is exactly where you want to end up." I've worked at a couple of other places and had a good time, but Google is a perfect match for me.
(I'm not really interested in dignifying responses from bitter people who have a bone to pick with Google for whatever reason.)
"Linux images" is not a meaningful measure of computing resources. Things like bytes of RAM, bytes of disk space, and megahertz of CPU are.
The smallest Linux image can run in 8MB of RAM, so if I get 100 servers with 64GB of RAM I could theoretically fire up 800,000 Linux images on them. Does this mean my 100 servers are as powerful as your five z10s?
For a look at my very preliminary version of the C api, check out this program that is built on Gazelle 0.1. Check out the "register_callback" calls in this source file:
recs-collate.c
As this gets more sophisticated, I want to use CSS selectors and/or XPath as a model for specifying the predicates for when callbacks are called. For example, imagine being able to specify callbacks like so:
register_callback("str_frag:unicode_char", callback);
register_callback("> object", callback);
I would encourage anyone who is interested in parsing or ANTLR to follow my project Gazelle. It is intended to be a next-gen parsing framework that builds on the ideas set forth in ANTLR but packages them in a significantly different way, which offers a lot of benefits (which I list in detail on the website).
The primary thing I am trying to deliver is reusability of parsers. The open-source community should be able to cooperate to write canonical parsers for all popular languages, but this goal is hampered by the fact that almost all parsing tools (ANTLR included) encourages you to write non-reusable grammars by virtue of the fact that you embed actions into the grammar.
Gazelle also takes a interpreter+JIT approach instead of emitting code in an imperative language. So for example, if you want a really fast HTTP parser from Ruby (which is precisely the raison d'etre for Mongrel), you can use the HTTP Gazelle parser from Ruby, but since the parsing is actually performed by the interpreter+JIT (written in C), you get extremely fast parsing without writing a line of C.
Gazelle is still very immature and not ready for people to try out, but I would encourage anyone who's interested to follow the Gazelle category on my blog.
You can also check out:
- the current draft of the manual, which will give you a better idea of the specifics of where I'm going with this.
- a graphical dump of the grammar for JSON, which the current development code is capable of generating.
The current generation of managed code VMs clearly have some benefits. But but they fall far short on some of the key properties that make C and C++ so powerful. Even if I grant you that the JVM and
C and C++ are the only game in town for getting the best performance and a small memory footprint and the ability to have the lowest possible latency.
.NET communities, because they have empirically demonstrated that they culturally have no regard for small memory footprint, low overhead, short startup time, etc. They just don't consider huge memory footprint or ridiculous startup times a problem. This is not to ment
That said, I think that C and C++ are becoming harder to justify when you consider the havoc that memory errors can wreak. It's highly embarrassing to vendors and damaging to their customers when a buffer overflow exploit is discovered. malloc and free, even when used correctly, can still have some forgotten downsides like the memory fragmentation that was discovered in Firefox 2, and took some very smart people a lot of work to address.
What I would like to see is a language that gives the benefits of C and C++ (extremely fast, extremely small memory footprint, and no GC pauses) but that is also immune to C and C++'s weaknesses (memory corruption, memory leaks, memory fragmentation). Yep, I pretty much want to have my cake and eat it too. Why do I think this is possible? I think that the future is to have a fully concurrent, compacting GC. Everyone's telling us we're going to have more cores than we know what to do with soon, right? Well why not use all those extra cores to do GC in the background? Even if it's more expensive on the whole, we barely know what to do with all those extra cores as it is. With this strategy, you could get the performance guarantees and low overhead of C and C++ (on the real, non-GC thread, that is) without having to give up GC or suffer from memory fragmentation.
I'm also not willing to give up the option of dropping to C or C++ (or even assembly language) when it's justified. Mention JNI in a room of Java people and observe them reel in horror -- it's culturally shunned to deviate from "100% pure Java." Maybe this is a good value when you're on a big team of people writing a web app, but for systems and multimedia programming this is silly -- inner loops are inner loops, and some of them can benefit from machine-specific optimization.
Theoretically you could experiment with the fully concurrent GC using an existing language/runtime like Java, but I've sort of given up on the JVM and