Slashdot Mirror


Experimental MacRuby Branch Is 3x Faster

An anonymous reader writes "Zen and the Art of Programming published an article about MacRuby's new experimental 0.5 branch (project blog entry here). According to the included benchmarks, Apple's version of Ruby could already, at this early stage of its development, be about three times as fast as the fastest Ruby implementation available elsewhere."

191 comments

  1. That's because it's spiked with assembly by Anonymous Coward · · Score: 5, Funny

    I heard it made a guy in Michigan's head explode! That's why I stay away from the experimental stuff, man.

  2. All right! by MillionthMonkey · · Score: 0, Troll

    My wife's 17" macbook is now my dev machine! She can surf on my old XP box that takes a half hour to boot. All I have to do now is learn Ruby.

    1. Re:All right! by postmortem · · Score: 1

      you made it boot half hour, originally before you put crap on, it would take less than minute even on abysmal hardware.

    2. Re:All right! by MillionthMonkey · · Score: 1

      OK, more like 15 minutes. But it's a 3 year old XP install; 15 minutes is pretty good. The secret is: try not to install anything, and carefully rip out the shareware crap preinstalled by the OEM.

    3. Re:All right! by Antique+Geekmeister · · Score: 2, Informative

      Care to bet on that? I've seen 5 minute boot times for XP on end-of-life hardware, primarily due to massive delays in indexing large disk drives. And no, it's not "booted" until it gives you a usable mouse and keyboard. Printing up the Windows boot screen and ignoring you for another few minutes does not count as "booted". Vista is noticeably worse on the same hardware due to the larger memory footprint: Win9x used to be OK on the hardware.

  3. Why MacRuby Matters? by Anonymous Coward · · Score: 4, Insightful

    Why MacRuby Matters (Present & Future)?

    Apparently because an experimental incomplete version of Ruby is fast. Colour me unimpressed.

    1. Re:Why MacRuby Matters? by NoTheory · · Score: 4, Insightful

      MacRuby matters for a lot of reasons. Early benchmarks aren't one of them. http://blog.headius.com/2009/03/on-benchmarking.html

      MacRuby's potential for Cocoa integration is fantastic and great, and something i very very much want to see.

      It's not clear however what relationship benchmarks at this stage (with an incomplete implementation) will actually correspond to in the future. They are a total red herring for discussion.

      Look at MacRuby on the merits! not the benchmarks!

      --
      There are lives at stake here!
    2. Re:Why MacRuby Matters? by Artuir · · Score: 5, Funny

      Whenever I read posts like these I start to wonder if I accidentally walked into a Starbucks.

    3. Re:Why MacRuby Matters? by bonch · · Score: 1

      Well, if you ask me, I suspect that someday in a future version of the Mac OS, Ruby will be a first-class language for application development alongside or perhaps replacing Objective-C. I think Apple likes Ruby and its aesthetic. A lot of the Rails devs are Mac developers, and I think that's where it sparked.

    4. Re:Why MacRuby Matters? by thePowerOfGrayskull · · Score: 4, Funny

      I suspect that someday in a future version of the Mac OS, Ruby will be a first-class language for application development alongside or perhaps replacing Objective-C.

      Wouldn't that require Ruby being a first-class development language in the first place? ;)

      Yeah, yeah, go on and mod me troll, I can handle it.

    5. Re:Why MacRuby Matters? by tyrione · · Score: 5, Insightful

      Well, if you ask me, I suspect that someday in a future version of the Mac OS, Ruby will be a first-class language for application development alongside or perhaps replacing Objective-C. I think Apple likes Ruby and its aesthetic. A lot of the Rails devs are Mac developers, and I think that's where it sparked.

      First Class, maybe. Replacing ObjC? You're prediction makes LSD trips seem dull.

    6. Re:Why MacRuby Matters? by Macthorpe · · Score: 5, Funny

      Yeah, yeah, go on and mod me troll, I can handle it.

      Alright then!

      Wait a minute...

      Shit.

      --
      "It does not do to leave a live dragon out of your calculations, if you live near him." - Tolkien
    7. Re:Why MacRuby Matters? by Anonymous Coward · · Score: 0, Troll

      The least used scripting language on the least used platform. Yes indeed, that matters - not.

    8. Re:Why MacRuby Matters? by nicolas.kassis · · Score: 1

      I don't see why it couldn't be a first choice for many developers. Objective-C might be used for more complex task while ruby is the main language used to develop applications.

    9. Re:Why MacRuby Matters? by Anonymous Coward · · Score: 2, Insightful

      Whenever I read posts like these I start to wonder if I accidentally walked into a Starbucks.

      Yea, these Mac snobs need to get with the program. If they put half the effort they put into MacRuby into CocoOnPunchCards, perhaps the rest of us might take them a little more seriously.

    10. Re:Why MacRuby Matters? by Anonymous Coward · · Score: 2, Funny

      This is slashdot. Benchmarks are all that matters.

    11. Re:Why MacRuby Matters? by M.+Baranczak · · Score: 1

      The latest Mac OS already has Ruby bindings for Cocoa, and Ruby-Cocoa templates in XCode. I haven't used this yet, so I've no idea how well it works, but it seems like it might have potential.

    12. Re:Why MacRuby Matters? by Malevolyn · · Score: 1

      Well that, and whether or not said subject will blend and/or run Linux.

      --
      Your ad here.
    13. Re:Why MacRuby Matters? by ToasterMonkey · · Score: 1

      Right, because the most used scripting language on the most used platform matters? What's that, VBScript?

      I don't think this was thought all the way through.

    14. Re:Why MacRuby Matters? by Malevolyn · · Score: 3, Funny

      Don't forget the possibility of ObjC extensions for Ruby.

      --
      Your ad here.
    15. Re:Why MacRuby Matters? by Antique+Geekmeister · · Score: 1, Troll

      Just let me know when Objective C succeeds in replacing anything else, first.

    16. Re:Why MacRuby Matters? by ahabswhale · · Score: 1

      I agree unless they will let me write iPhone apps in Ruby. I'm not a Ruby fanboi by any stretch of the imagination but Objective C sucks balls. I passionately despise it and their IDE for it is even worse than the language. Using a language that other people use opens the possibility of using non-Apple tools (which lets face it, suck). For all of Apple's efforts to make nice consumer devices, they don't give a rat fuck about developers and their tools. Xcode is lightyears behind the equivalent tools for Java, Ruby or Groovy. Seriously, it's from the dark ages of programming. The code editors I used 10 years ago (like SlickEdit) were better than Xcode is today. Even if it were brought into this millenium, Objective C is still a fucking joke of a language.

      --
      Are agnostics skeptical of unicorns too?
    17. Re:Why MacRuby Matters? by theolein · · Score: 1

      In all seriousness, Ruby is probably used less than Python and PHP.

    18. Re:Why MacRuby Matters? by rishistar · · Score: 1

      Because it allows people to show how rich they are.

      --
      Professor Karmadillo Songs of Science
    19. Re:Why MacRuby Matters? by mcvos · · Score: 1

      In all seriousness, Ruby is probably used less than Python and PHP.

      But growing faster.

    20. Re:Why MacRuby Matters? by ceoyoyo · · Score: 1

      It's not already? I had the impression the Ruby-Cocoa bridge was as mature as the Python-Cocoa one.

    21. Re:Why MacRuby Matters? by tixxit · · Score: 1

      Yes, it is used less right now. But it has support from Apple and Sun. I still prefer Python, but it is a fun language and now seems to be a long-term player.

    22. Re:Why MacRuby Matters? by Teilo · · Score: 3, Insightful

      I don't care much for Ruby myself. I'm a Python guy, but I don't give a frack what language people use.

      "Least used scripting language"? Right, because nobody develops on Rails (like it or hate it).

      Ever check the stats on Developers who use Macs (vs. the general populace)? Didn't think so.

      And finally: that which makes MacRuby very very fast can also make Ruby on *nix very very fast.

      The problem with Ruby is not the language. It is the VM. Improve the VM, and more people will look at other uses where Ruby is a great fit but for its speed.

      --
      Mir tut es leid, Menschen daß Einfältigfehlersuchenbaumfolgendenaffen sind.
    23. Re:Why MacRuby Matters? by bonch · · Score: 1

      Objective-C replaced C-based Carbon as the first-class language for app development. You really don't think Apple would happily switch things over again in the future?

    24. Re:Why MacRuby Matters? by LWATCDR · · Score: 1

      Yes it could be very nice.
      The problem is that it is too mac centric.
      MacRuby could make a very good RAD platfrom except that it will only work on a Mac. The problem is that very few Macs are used in business. There are even fewer businesses that are Mac only.
      Ruby+QT would seem to be a much better idea for a RAD system.
      It would run everywhere.
      Honestly I am really hoping that QT 4.5 will help kill Visual Basic onces and for all.
      It offers an inexpensive platform for cross platform development.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    25. Re:Why MacRuby Matters? by tyrione · · Score: 1

      I don't see why it couldn't be a first choice for many developers. Objective-C might be used for more complex task while ruby is the main language used to develop applications.

      Make it your first choice. Be my guest. ObjC is the choice of OS X since 1989. If Apple restores WebObjects to it's original language, ObjC [I hated that decision when I worked there] I for one would have one more reason to use Cocoa and ObjC besides just on OS X--the Appserver Market.

    26. Re:Why MacRuby Matters? by swissmonkey · · Score: 1

      Oh yeah, supported by a dying company (Sun) and one that has absolutely no server market share.

      Way to go Ruby !

  4. And... by Creepy+Crawler · · Score: 2, Informative

    Of course, Slashdot is a dime short and days late on the real news.

    JavaScript 3-10x Faster On iPhone OS 3.0

    Well, for a better, no BS news aggregator, try The Hacker News. Then after seeing it there for a few days, come to slashdot to see a regurgitated discussion.

    --
    1. Re:And... by iamhigh · · Score: 2

      Yeah, a site of links really compares to the discussion system here on /.. The discusssion and moderation system are what make this site good. Everyone but the dumbest of fucks knows that.

      --
      No comprende? Let me type that a little slower for you...
  5. LLVM strikes again. by jcr · · Score: 2, Interesting

    This is great news. The work that Apple's doing on LLVM is a renaissance in compilers.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
    1. Re:LLVM strikes again. by samkass · · Score: 5, Interesting

      Of course, the results don't exactly show a "3x speedup"... they show between a 0.08x speedup and a 7.8x speedup, with a high variability. Which is really great for such an early build, but it's not an instant panacea for everything.

      --
      E pluribus unum
    2. Re:LLVM strikes again. by Anonymous Coward · · Score: 1, Insightful

      Not really, it's neat but hardly new. You want to see a renaissance in compilers, look at TraceMonkey, LuaJIT, V8 and whatever the WebKit engine is called this week.

    3. Re:LLVM strikes again. by TheRealMindChild · · Score: 2, Interesting

      You know. It was bad enough when we had multitudes of acronym collisions with 3-letter acronyms... but did anyone else associate LLVM with Linux Logical Volume Manager?

      *sigh*

      --

      "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
    4. Re:LLVM strikes again. by earthbound+kid · · Score: 1

      See also the Unladen swallow project, which is using LLVM to speed up Python. They're still in the very early stages, but it looks promising.

    5. Re:LLVM strikes again. by Anonymous Coward · · Score: 1, Insightful

      no.

    6. Re:LLVM strikes again. by tyrione · · Score: 1

      Not really, it's neat but hardly new. You want to see a renaissance in compilers, look at TraceMonkey, LuaJIT, V8 and whatever the WebKit engine is called this week.

      What the hell do you think WebKit will use to be built? LLVM.

      Qt 4.5 already builds with LLVM. Same for the FreeBSD kernel.

    7. Re:LLVM strikes again. by tyrione · · Score: 1

      You know. It was bad enough when we had multitudes of acronym collisions with 3-letter acronyms... but did anyone else associate LLVM with Linux Logical Volume Manager? *sigh*

      No.

    8. Re:LLVM strikes again. by bdash · · Score: 1

      What the hell do you think WebKit will use to be built? LLVM.

      Err, what? WebKit is compiled with GCC on Mac OS X (4.0 on Tiger, 4.2 on Leopard), and Visual C++ on Windows. Compiling WebKit with llvm-gcc is possible, but I'd only recommend it if you want something that's slower and takes longer to compile.

      It's likely that the grandparent is referring to the SquirrelFish Extreme (AKA Nitro) JavaScript engine developed by Apple for WebKit.

    9. Re:LLVM strikes again. by walshy007 · · Score: 1

      I did

  6. Hackers. by Anonymous Coward · · Score: 0, Offtopic

    Was the best movie of all time.

  7. Your sig by i.of.the.storm · · Score: 1

    Your sig is pure evil. Nicely done!

    --
    All your base are belong to Wii.
    1. Re:Your sig by Creepy+Crawler · · Score: 2, Informative

      Thanks ;)

      You'd be surprised of the multitudes of comments I get on me and my bastardly signature... Well, you could always look at my freaks list to get an inking.

      I thought it was rather dryly funny.

      --
    2. Re:Your sig by Anonymous Coward · · Score: 1, Informative

      I thought it was rather dryly funny.

      It was mildly funny a long time ago. It's boring and irritating now.

    3. Re:Your sig by Anonymous Coward · · Score: 0

      What's the sig? I'm not logging on to find out...

    4. Re:Your sig by jonaskoelker · · Score: 1

      Well, you could always look at my freaks list to get an inking.

      I'd rather not get inked, but I might want to get a ballpark feel for how unpopular it is. And maybe get an 'l' ;-)

  8. Ruby? by edivad · · Score: 0, Offtopic

    One question. WHY?!?

    1. Re:Ruby? by moniker127 · · Score: 0, Flamebait

      Because puts { "I like beans" } is 9000% better than just typing I like beans.
      In reality though, I dont know. Ruby is a language that attempts to simplify something that is already perfectly simple, and in the process of trying it really does not introduce much of anything useful.
      I'm not sure why layers upon layers of complexity if preferable to some people.

    2. Re:Ruby? by Anonymous Coward · · Score: 0

      Those layers upon layers were a result of decades and several agreed upon standards.

      If they are too complex for you simply, make them easier. The complexity isn't an excuse to throw out everything achieved so far and recreate the wheel, the transmition, engine, driving interface, etc...

    3. Re:Ruby? by NoTheory · · Score: 4, Insightful

      Er, way to troll? If you'd like to do your ridiculous hello world you can stick to:

      puts "i like beans"

      And it's really unclear what "it" you're referring to. Because Ruby, for me, is a good blend of the things i wanted from Perl and Lisp with a side of Object Orientation. I get all the laziness and conveniences of Perl, and i can do all the crazy stuff i'd want to do with Lisp. So imo, you're way off base.

      --
      There are lives at stake here!
    4. Re:Ruby? by Vectronic · · Score: 1

      Because binary is incredibly boring and tedious.

      Same reason why all of our spoken/written languages aren't just sequences of "Yes" and "No". The same reasons why we no longer live in caves, is the same reason why programming languages will continue to evolve, and become more abstract. There are numerous variables, but the main one being that the original version is never all-encompassing and generally flawed, wood rollers are quicker to make than rubber on metal rims, but the latter is far more adaptable.

      Binary = Wood Rollers
      Stone Wheel = Assembly
      Wood Wheel = Fortran
      Steel Wheel = C
      Steel + Solid Rubber = C++
      Magnesium + Air Filled Rubber C#
      Aluminum + Air Filled = Scripting or something
      Magnetic Levitation = ????

      Or something like that...

    5. Re:Ruby? by moniker127 · · Score: 1

      Yes but any sort of layering in a computer system is a major cause of bugs/slowdown. If you dont have to translate between four different languages, then you have a better experience and fewer things lost in translation.
      Obviously we cant all write in machine code, so a limited about of layering is acceptable, but really, what does it help in this case?

    6. Re:Ruby? by Anonymous Coward · · Score: 0

      While you make a good point. It's obvious that in the future programming is gonna keep evolving into higher and higher abstraction. Layering is just a means of reaching this objective.

      If we could, we would develop everything as straight forward as possible, but because we are flawed and bug-prone, using layers of abstractions as step-stones is probably the best way.

    7. Re:Ruby? by anegg · · Score: 3, Insightful

      Any sort of layering is a major cause of bugs/slowdown? Quick, throw out TCP/IP. Everyone start using Ethernet frames directly from their apps, even if what you really want to use is SOAP over HTTP over SSL over TCP over IP... I'm not sure how you will get your Ethernet frames past the first router, but I'm sure you will think of something. Damn layering just gets in the way!

    8. Re:Ruby? by Anonymous Coward · · Score: 0

      Steel Wheel = C
      Steel + Solid Rubber = C++
      Magnesium + Air Filled Rubber C#
      Aluminum + Air Filled = Scripting or something

      Further supporting your analogy, these four are all "built on top of a rollers layer": the bearings and races.

    9. Re:Ruby? by rgravina · · Score: 2, Insightful

      So you're suggesting that instead of creating languages like Ruby, we should create libraries to more complex environments like Java to make them faster to develop with? Variety is the spice of programming :). Personally, I'm glad languages like Python and Ruby exist and they are not only great and productive languages, they have both made me rethink the way I write software. I'm not sure just adding on top of Java would have achieved the same thing.

    10. Re:Ruby? by Anonymous Coward · · Score: 0

      I can't understand your argument. Ruby wasn't created as a response to Java, it predates it.

    11. Re:Ruby? by ToasterMonkey · · Score: 1

      Any sort of layering is a major cause of bugs/slowdown? Quick, throw out TCP/IP. Everyone start using Ethernet frames directly from their apps, even if what you really want to use is SOAP over HTTP over SSL over TCP over IP... I'm not sure how you will get your Ethernet frames past the first router, but I'm sure you will think of something. Damn layering just gets in the way!

      Absolutely hilarious that you brought up TCP/IP/Ethernet.

      Are you familiar with Fibre Channel? I'm guessing no. Look it up, compare with Ethernet & IP & TCP, SCSI, etc.
      Do you know what Data Center/Converged Ethernet is? Yup, a COMPLETELY reengineered Ethernet with features of most upper layers (like in order delivery, retransmission, etc) built in to support FCoE. Essentially, it's Ethernet adapted to Fibre Channel, not FC adapted to Ethernet. I'm not really sure what this will do to IP/TCP, but you're going to be very surprised what an Ethernet frame is capable of in a few years.

      Continually adding new layers over time is bad engineering IMO.

    12. Re:Ruby? by Serious+Callers+Only · · Score: 2, Insightful

      Because puts { "I like beans" } is 9000% better than just typing I like beans.

      What a terrible example

      1. It's not functioning Ruby (try puts "I like beans", like most languages in fact)

      2. It has nothing to do with the strengths or failings of Ruby as a language.

      Do you know anything about Ruby? Do your empty platitudes about 'layers upon layers of complexity' actually have any basis in reality? From your comment, I suspect not.

      There are some not so nice corners of Ruby, but an attempt to oversimplify is not one of them.

    13. Re:Ruby? by FooBarWidget · · Score: 1

      And how many people use Fibre Channel for it to matter?

    14. Re:Ruby? by moniker127 · · Score: 1, Flamebait

      It was a sarcastic comment. I'm SO sorry.

      The reason ruby fails is because it combines things which need not be combined. As much as i'd love to have one language that does everything on the planet- it isnt that way- FOR A REASON. It is slow.
      It is an unnecessary layer of obfuscation that- the concept of which is apparently acceptable to today's programmers. Apparently efficiency is bullshit- everyone just wants it to be easy so they can attend a two week course and call themselves the master of it.
      It does not add any functionality you cant get from a more localized, specific focus language.

      Look - if you like ruby nothing is stopping you from using it- I sure as hell wont- but I wont stop you from masturbating either. It isnt any of my business. Do what you want.

    15. Re:Ruby? by mcvos · · Score: 1

      Ruby is a language that attempts to simplify something that is already perfectly simple, and in the process of trying it really does not introduce much of anything useful.

      Ruby is a language that simplifies something that is bloody hard in Java. Ever heard of AOP? Trivial in Ruby.

    16. Re:Ruby? by mcvos · · Score: 1

      I can't understand your argument. Ruby wasn't created as a response to Java, it predates it.

      True. It's programmers migrating to Ruby that's a response to Java.

    17. Re:Ruby? by vjoel · · Score: 1

      Magnetic Levitation = MagLev

      --
      What part of `yes no` don't you understand?
  9. Yeah , a true renaissance by Viol8 · · Score: 4, Insightful

    "LLVM supports effective optimization at compile time, link-time (particularly interprocedural), run-time"

    Amazing, truly unique ideas. If only someone had thought of doing this 30 years ago... oh wait...

    1. Re:Yeah , a true renaissance by RAMMS+EIN · · Score: 1

      ``"LLVM supports effective optimization at compile time, link-time (particularly interprocedural), run-time"

      Amazing, truly unique ideas. If only someone had thought of doing this 30 years ago... oh wait...''

      Well? That doesn't make it any less of a renaissance. If anything, it makes it more like the renaissance. After all, that also started with the idea of "hey, let's go do something with all this great stuff we had a long time ago".

      --
      Please correct me if I got my facts wrong.
    2. Re:Yeah , a true renaissance by Viol8 · · Score: 1

      Well what? They've been standard compiler techniques for as long as I can remember. Isn't a renaissance supposed to be forgotten ideas coming back to life?

    3. Re:Yeah , a true renaissance by bonch · · Score: 2, Interesting

      The greatness of LLVM and Clang is that they replace the slow, rigid, crumbling GCC codebase. When the BSD-licensed Clang hits ready status, expect a massive switchover.

    4. Re:Yeah , a true renaissance by tyrione · · Score: 1

      The greatness of LLVM and Clang is that they replace the slow, rigid, crumbling GCC codebase. When the BSD-licensed Clang hits ready status, expect a massive switchover.

      Precisely.

  10. The questions remains... by dvh.tosomja · · Score: 1, Flamebait

    What is 3x faster than super uber ultra slow? Is ruby now just plain slow instead?

    1. Re:The questions remains... by Peter+Cooper · · Score: 1

      All dynamic scripting languages are "uber ultra slow" then, by your measure. Ruby 1.9 betters or equals the performance PHP, Perl and Python 3 in the latest Alioth Shootout.

    2. Re:The questions remains... by FooBarWidget · · Score: 5, Insightful

      Every time a story is posted about Ruby performance improvements, someone will post something along the lines of "x times faster than super ultra duper slow is still slow". Even if Ruby is 1000 times faster, there will still be people complaining. My guess is that none of these people actually use Ruby in production to be able to tell how much interpreter performance actually matters in the grand scheme of things.

    3. Re:The questions remains... by wrook · · Score: 5, Interesting

      I agree with this totally. These days I'm writing exclusively in Ruby and it is "fast enough" (even with 1.8.X). In fact, this speed issue is such a big red herring for me. I hardly ever have any issues with speed. Instead I spend most of my optimization time trying to cut down on memory usage.

      For me, even an order of magnitude difference in speed (i.e., 10X) isn't going to mean too much. There are certainly places where I'd like my code to be faster, but they are very, very small places. I can easily code them in C if I have to (C/Ruby bindings are *very* easy to write). But honestly, I've never gotten to the point where a speed improvement is more important than a functionality improvement. Every program is different, of course. So not every problem is suited to Ruby.

    4. Re:The questions remains... by 33degrees · · Score: 3, Informative

      While the Ruby 1.8 VM is quite slow, the YARV VM used in 1.9 is much faster, resulting in similar performance to most other dynamic languages. These tests are showing MacRuby being 3x faster than 1.9, which puts it in "quite fast" territory.

    5. Re:The questions remains... by Otterley · · Score: 4, Insightful

      These days I'm writing exclusively in Ruby and it is "fast enough" (even with 1.8.X).

      I suspect that's because your website doesn't receive thousands of dynamic requests per second.

    6. Re:The questions remains... by raisin · · Score: 1, Flamebait

      Thanks, Captain Anecdote, but you've left out even the anecdotal evidence. What's all this exclusive writing you're doing with Ruby? I've been doing all my grocery list work in Ruby too, and it's *totally* fast enough.

      I think Ruby is a fantastic language, but then I see comments like this modded up to 5 that are completely nonsensical. This makes Ruby fandom seem more like Java 1999, which makes me think twice about my positive opinion of it.

    7. Re:The questions remains... by FooBarWidget · · Score: 2, Informative

      Tell that to MTV and New York Times. Yes, they run Rails. Not on the front page, but nevertheless, they use it on very busy parts of their sites.

      And heck, do I even need to mention 37signals? Those guys receive tons and tons of requests per second.

    8. Re:The questions remains... by FooBarWidget · · Score: 3, Informative

      "Thanks, Captain Anecdote, but you've left out even the anecdotal evidence. What's all this exclusive writing you're doing with Ruby? I've been doing all my grocery list work in Ruby too, and it's *totally* fast enough."

      I'm not the GP, but New York Times, MTV, Aboutus.com (high-ranking Alexa site), Yellow Pages, are all running Ruby. I'd love to give you even more examples but I've signed NDAs.

      "I think Ruby is a fantastic language, but then I see comments like this modded up to 5 that are completely nonsensical. This makes Ruby fandom seem more like Java 1999, which makes me think twice about my positive opinion of it."

      I can say the same thing about comments that complain about Ruby's speed without providing any kind evidence that the interpreter's speed is the bottleneck in their application. This makes it seem like bashing Ruby is just the latest fad, which makes it very hard for me to take any of these complaints seriously. If you cry wolf several times then nobody will listen to you anymore.

    9. Re:The questions remains... by Berfert · · Score: 1

      These days I'm writing exclusively in Ruby and it is "fast enough" (even with 1.8.X).

      I suspect that's because your website doesn't receive thousands of dynamic requests per second.

      If your front end page code is doing enough that speed is an issue, there's good odds that your front end page code is doing too much.

    10. Re:The questions remains... by Anonymous Coward · · Score: 0

      Or maybe he's not working on websites, Rails is not the only thing Ruby is used for.

    11. Re:The questions remains... by 1110110001 · · Score: 1

      Even if Ruby is 1000 times faster, there will still be people complaining.

      1000 times faster than super ultra duper slow is still slow ;)

    12. Re:The questions remains... by srussell · · Score: 1

      Hm. According to the Computer Language Benchmarks Game, Ruby is 140 times slower than C (the median, across all tests). Ruby 1.9 is "only" 52 times slower than C. Three times faster than that means that MacRuby is only 17 times slower than C. Which makes it only twice as slow as Lua and only three times as slow as Lisp. I wouldn't classify that as "quite fast", although that's a bit more than twice as fast than Python, which is pretty good.

      God, I love the CLBG (which used to be the GCPLS).

      In any case, I love Ruby for what it is good at -- one-off scripts that grow gracefully. I've grown distrustful of languages that don't support any form of pre-runtime type checking for non-trivial application development. That's not a failing that is particular to Ruby, though.

  11. Painted red by EdZ · · Score: 2, Funny

    Those new code contributions by Mr Aznable made all the difference.

    1. Re:Painted red by PixetaledPikachu · · Score: 1

      Those new code contributions by Mr Aznable made all the difference.

      Funny, I didn't recognize him. Maybe because of the shade

    2. Re:Painted red by deathtopaulw · · Score: 1

      hahahaha Gundam jokes are rare here, and for some reason I didn't think of that one. Good call sir.

  12. What's so special about it? by Anonymous Coward · · Score: 1, Informative

    What's so special about this implementation? It runs on an intel x86 running a modified bsd kernel. I suppose that this was spiked with a healthy dose of reality distortion field, (remember how RISC processors were X times faster than chips that fell prey to the dreaded "megahertz myth") right up until they switched, and the new systems were 4-6x faster than the old ones?

    1. Re:What's so special about it? by mini+me · · Score: 1

      What is different is that it uses the Foundation library for the underlying implementation. i.e. a Ruby array maps to a NSArray, a Ruby string maps to a NSString, etc.

    2. Re:What's so special about it? by larry+bagina · · Score: 1

      it gives direct access to the Cocoa framework. And the experimental version uses LLVM for code generation, so it could be optimized close to native (objective c) speeds.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

  13. Nitro AKA Squirrelfish by stefaanh · · Score: 3, Interesting

    I wonder if this has any connection to what they learned creating the optimized javascript "interpreter" they made for their next generation rendering engine Webkit.

    --
    --------
    * Sigh *
    1. Re:Nitro AKA Squirrelfish by mr_mischief · · Score: 1

      The next generation of what, KHTML? WebKit did not spring from the forehead of Steve Jobs fully formed, you might want to know.

  14. true, but seems unnecessary by Trepidity · · Score: 2, Informative

    Common Lisp is ultra-dynamic and whatnot and still compiles to machine code, which in some implementations (SBCL/CMUCL) is quite respectable in performance. Is there something inherently less-compilable about Python, Ruby, Perl, etc., or have they just not had the same engineering work put into them?

    1. Re:true, but seems unnecessary by Anonymous Coward · · Score: 0

      Probably the dynamic typing.

    2. Re:true, but seems unnecessary by cryptoluddite · · Score: 2, Informative

      Common Lisp scores really well on benchmarks because they turn off all the safety protections that are most of the reason to use a dynamic language in the first place.

      All scripting/dynamic languages are slow, and they always will be because nobody wants a really high level language that crashes.

    3. Re:true, but seems unnecessary by Cyberax · · Score: 2, Interesting

      LISP compilers are not magical. They just try to:
      1) Infere types and then compile typed code.
      2) Do inlined threaded interpreter for everything else.

      I.e. if you want fast LISP code - you have to write it like you would write it in C/Java/C++/another_static_language.

    4. Re:true, but seems unnecessary by Trepidity · · Score: 2, Interesting

      It scores pretty well even if you don't turn them off, because the good compilers (mainly CMUCL/SBCL) have type inference that can determine at compile time a large subset of the cases where it's safe to elide the runtime checks.

    5. Re:true, but seems unnecessary by Anonymous Coward · · Score: 1

      Simple. The so-called "Scripting Languages" simply aren't designed for the same type of work as languages like C.

      If you're using Ruby in an environment where its relative slowness is actually a problem, then Ruby probably isn't the right tool.

    6. Re:true, but seems unnecessary by Trepidity · · Score: 1

      They're still orders of magnitude faster for generic code, though. You don't get C-like speed, but you get 10x+ better speed than you get in Python, especially on loop-heavy code.

    7. Re:true, but seems unnecessary by Cyberax · · Score: 1

      Python has some brain-dead design issues in its interpreter, so it's not that great a feat.

      "Unladen Swallow" will probably fix a lot of these issues (and maybe, just maybe, we'll get rid of GIL in Python).

      CMU and SBCL are nice, but if you want the current state-of-the-art in virtual machine development, you should check Sun JVM.

    8. Re:true, but seems unnecessary by maxume · · Score: 1

      There isn't any type inference (Psyco helps with that) and there aren't any declarations. It is a bit of a copout, but the often recommended strategy is to rewrite the slow parts in C (which for the people writing the Python interpreter in C was probably a lot easier and more effective than building an advanced compiler...).

      --
      Nerd rage is the funniest rage.
    9. Re:true, but seems unnecessary by the_one(2) · · Score: 1

      From what i understand you can compile python code to x86 with psyco for a pretty nice speedup.
      from wikipedia:

      Psyco can noticeably speed up CPU-bound applications. The actual performance depends greatly on the application and varies from a slight slowdown to a 40x speedup.

    10. Re:true, but seems unnecessary by Tumbleweed · · Score: 1, Flamebait

      if you want the current state-of-the-art in virtual machine development, you should check Sun JVM.

      Yeah, but then you run into the problem where you have to write in Java, and let's be honest -- fuck that.

      If you're going to write in something as butt-ugly as Java, you might as well write in C++, and really, if you're going to write in something as nasty as C++ for performance reasons, you might as well just go all the way and write in asm.

      Then again, there is always D to consider, if you don't want to go down that path.

    11. Re:true, but seems unnecessary by 644bd346996 · · Score: 1

      The JVM architecture is still too restrictive to cleanly run truly dynamic languages, so the fact that it is fast isn't really useful.

    12. Re:true, but seems unnecessary by Cyberax · · Score: 0, Troll

      You can write in Scala, it's very nice. Although, I'd like to see better support for its type system in the JVM.

      It's the unofficial 'next Java' for JVM.

      PS: Do you want me to punch you in face? You see, C++ is one of my favorite languages :)

    13. Re:true, but seems unnecessary by Trepidity · · Score: 1

      The JVM seems to have advanced to the point where other languages besides Java are targeting it as well. Two of the more popular seem to be Clojure and Jython. I suspect more will start appearing if JRE 7 adds better built-in support for compiling dynamic languages, as has been long discussed.

    14. Re:true, but seems unnecessary by Cyberax · · Score: 1

      JVM is going to get invokedynamic instruction soon - http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html

      Even without 'invkoedynamic', JRuby is one of the best-performing Ruby interpreters.

    15. Re:true, but seems unnecessary by Tumbleweed · · Score: 4, Funny

      PS: Do you want me to punch you in face? You see, C++ is one of my favorite languages :)

      I don't like the feeling of being punched in the face, which is one of the big reasons I don't code in C++ or Java. But if that's your thing, you should keep at it! :)

    16. Re:true, but seems unnecessary by ChunderDownunder · · Score: 2, Informative

      Who mentioned programming Java? Only your fouled-mouthed troll.

      Cyberax was talking about running languages such as Python, Ruby or Lisp on the Java Virtual Machine. In turns out that many of the runtime techniques within HotSpot to speed Java can also be used to optimise the performance of others. Where not the case, special mechanisms are being added to bytecode to create a truly language independant VM.

      Thanks to Red Hat, there's also an LLVM based backend for HotSpot in development, Shark.

    17. Re:true, but seems unnecessary by NewbieProgrammerMan · · Score: 1

      What are the brain-dead design issues? I've not really looked into interpreter/VM design, so I'm just curious about what constitutes bad design (if it's easy to explain to a noob).

      --
      [b.belong('us') for b in bases if b.owner() == 'you']
    18. Re:true, but seems unnecessary by Anonymous Coward · · Score: 0

      ...if you want the current state-of-the-art in virtual machine development, you should check Sun JVM.

      Cool; where can I download the source for the Sun JVM to see what such an awesome VM implementation looks like? ;)

    19. Re:true, but seems unnecessary by Cyberax · · Score: 1

      The worst design issue is GIL (Global Interpreter Lock) - it prevents Python from using threads.

      The second design issue is the usage of refcounters instead of real GC.

      And finally, Python's bytecode and internal representation is far from optimal. Any Forth programmer can tell you that :)

    20. Re:true, but seems unnecessary by 644bd346996 · · Score: 1

      Cool. I hadn't checked the status of JSR 292 in quite a while. It's good to see that it's actually being implemented, even if it is still a ways away.

    21. Re:true, but seems unnecessary by nneonneo · · Score: 1

      Ahem, it doesn't prevent Python from using threads, merely preventing it from executing *Python code* in parallel. There's nothing preventing you from creating 20 threads to handle I/O: this is one of the most common uses of threads, anyway.

      Besides, if you are attempting to get maximal performance out of Python by threading your computationally-heavy code, well, you are probably better off writing parallelized C or something, as the speedup from that move will far exceed any improvement you can get from using fully threaded Python.

      GIL doesn't prevent you from using threads in one of the more common usage scenarios, which is blocking I/O: 20 threads all handling one socket each is just fine with Python, and all those threads will provide a meaningful speedup to your program.

      Python also has "real GC". Objects are cleaned up when their refcounts hit zero (as in a normal reference-counted implementation) but full GC sweeps are also done less frequently. Thus, there is a real garbage collection implementation which can properly clean up cycles and other problematic objects, and a refcounted GC for efficiency.

      I am curious about your statement regarding Python's bytecode. As far as I can tell, it's not too bad (this coming after I've done some manual disassembly of Python bytecode using the "dis" module). I'm not a Forth programmer, but I would like to know your specific gripes about the bytecode.

    22. Re:true, but seems unnecessary by nneonneo · · Score: 1

      That's a JIT (Just-In-Time) compiler: these are quite common; for example, Java on supported hardware has a JIT (HotSpot is the name, I think).

      This differs from native code compilation, where you take a source file (in the scripting language) and generate (and store) the machine code corresponding to that source code. In principle, you can think of a JIT like a compiler which is running while the source code is being executed: as the code runs, the JIT compiles parts of it to native code to speedup execution.

    23. Re:true, but seems unnecessary by jonaskoelker · · Score: 1

      I.e. if you want fast LISP code - you have to write it like you would write it in C/Java/C++/another_static_language.

      Like Haskell/ML/Ocaml where I don't write the types myself?

    24. Re:true, but seems unnecessary by renoX · · Score: 1

      >>if you want the current state-of-the-art in virtual machine development, you should check Sun JVM.
      >Yeah, but then you run into the problem where you have to write in Java, and let's be honest -- fuck that.

      What about Scala?
      It seems to be a really nice language: I would say that Scala's syntax is better than D's syntax.

    25. Re:true, but seems unnecessary by Schraegstrichpunkt · · Score: 1

      Cool; where can I download the source for the Sun JVM to see what such an awesome VM implementation looks like? ;)

      Here, and it's licensed under the GPL.

  15. How they did it by Anonymous Coward · · Score: 5, Funny

    Sleep(30); /* used to be 90 */

  16. The Future by Narpak · · Score: 1

    Experts predict Computers to get faster with time! News at eleven.

    1. Re:The Future by bonch · · Score: 1

      Do you know what a benchmark is and how it's made?

  17. This sounds great! by Anonymous Coward · · Score: 2, Funny

    But I'm a heterosexual so I will not be able to take advantage.

    1. Re:This sounds great! by Anonymous Coward · · Score: 0

      That's not what your mom told me last night, Francis.

  18. GCC avoids high level interprocedural optimization by Pinky's+Brain · · Score: 2, Interesting

    Because they don't want to expose high level intermediary code (too easy to hijack part of the compiler into a closed source project). Or at least that was one of the reasons LLVM was rejected for next generation GCC at the time.

    They might have changed their mind now LLVM is bearing down on them ...

  19. Code signing requirements that vary per language by tepples · · Score: 1

    There are certainly places where I'd like my code to be faster, but they are very, very small places. I can easily code them in C if I have to (C/Ruby bindings are *very* easy to write).

    Until you try to execute your code on someone else's computer, and your Ruby code works but the C code fails to start because unlike the Ruby interpreter, your code hasn't been digitally signed by the platform maintainer. This is already the case for JavaScript: Windows allows parts of a JScript program to be coded in C as "ActiveX" objects, but they have to be signed with a valid Authenticode certificate issued by a trusted CA first.

  20. Apple is not Microsoft ... by Pinky's+Brain · · Score: 2, Insightful

    They don't have any particular antipathy to the GPL ... Chriss Lattner proposed LLVM as a GCC successor after starting work at Apple. The FSF kicked him to the curb. I don't know if they underestimated his and Apple's commitment into turning the compiler into a true competitor or if they are simply stupid.

    As LLVM gets better GCC will lose developers, this is unavoidable, it's EGCS all over again ... but this time a merge doesn't seem on the cards. It wasn't LLVM but the FSF themselves who torpedoed one of the GPL flagships ... and for very very poor reasons.

    1. Re:Apple is not Microsoft ... by tyrione · · Score: 1

      They don't have any particular antipathy to the GPL ... Chriss Lattner proposed LLVM as a GCC successor after starting work at Apple. The FSF kicked him to the curb. I don't know if they underestimated his and Apple's commitment into turning the compiler into a true competitor or if they are simply stupid.

      As LLVM gets better GCC will lose developers, this is unavoidable, it's EGCS all over again ... but this time a merge doesn't seem on the cards. It wasn't LLVM but the FSF themselves who torpedoed one of the GPL flagships ... and for very very poor reasons.

      They kicked him proposal to the curb because certain devs in GCC, like all businesses [for profit or otherwise] don't like to lose the power of control.

      It shows how truly dense the GCC group always was of NeXT and now of Apple Engineering.

    2. Re:Apple is not Microsoft ... by jcr · · Score: 1

      The FSF kicked him to the curb.

      "Kicked him to the curb" isn't quite the right metaphor, since it implies that he needed the FSF in some way.

      As LLVM gets better GCC will lose developers

      I'm not sure it's that the FSF will lose anyone, so much as people entering the field will start with LLVM instead of GCC. It's rather like the way Linux came along and delivered everything that the FSF was going to get around to any decade now...

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
    3. Re:Apple is not Microsoft ... by Anonymous Coward · · Score: 1, Informative

      But since neither LLVM nor Clang are licensed under the GPL, RMS will never accept it.

      Also, if you've not followed the GCC development mailing lists it seems a large number of core GCC developers are very unhappy with the FSF's "meddling" in the project. Most recently almost all development was brought to a standstill for over two months when the FSF mulled over changes to a license text while the project was in regression-only mode in preparation for the 4.4.0 branch. The kicker was that the license changes were relevant only to the future 4.5 version which will introduce a plugin architecture and were completely unnecessary for the 4.4.0 release. The views expressed by the developers before the problem was resolved indicate that many of them would be prepared to jump ship if they find that the FSF is hindering the development of the compiler.

    4. Re:Apple is not Microsoft ... by jcr · · Score: 1

      Most recently almost all development was brought to a standstill for over two months when the FSF mulled over changes to a license text

      They do have a bit of a license fetish over there, don't they?

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
    5. Re:Apple is not Microsoft ... by Anonymous Coward · · Score: 0

      They do have a bit of a license fetish over there, don't they?

      Not as much as Apple - you should see the number (and length) of EULAs & other licenses there is on Apple software! With restrictions on use that the FSF would never even consider.

      If the FSF have a license fetish, then Apple has a license wardrobe full of chains/whips/large black dildos/cock rings/piercing kit/candles/latex/camels....

  21. GNUstep? by tepples · · Score: 1

    What is different is that it uses the Foundation library for the underlying implementation. i.e. a Ruby array maps to a NSArray, a Ruby string maps to a NSString, etc.

    Would a Linux port be possible using GNUstep, the Free implementation of the same API that Cocoa is based on?

    1. Re:GNUstep? by Anonymous Coward · · Score: 0

      it would take some work as MacRuby makes Ruby objects Objective-C objects and vice/versa. GNUStep uses the GNU Objective-C runtime rather than Apple's- mainly because Steve Jobs tried to rip off gcc back in the NEXT days, and when he found all the shit he'd get into he handed over the compiler but not the runtime. It's a somewhat different object model between the runtimes.

      Also GNUStep doesn't use Apple's Objective-C2.0 garbage collector which MacRuby relies on.

    2. Re:GNUstep? by Anonymous Coward · · Score: 1, Informative

      Macruby is based on Objective-C 2 (which privides a garbage collector).

      AFAIK, GNUstep doesnt use Objective-C 2. So, you would also have to port that. :/

  22. Please don't start you sentences in the subject... by Tubal-Cain · · Score: 2, Informative

    ...line. It is disorienting for the people that don't always read the subject line (almost everybody). And capitalizing the first word of the body text when the word takes place in the middle of the sentence doesn't help, either.

  23. you are thinking of scheme not clisp by Anonymous Coward · · Score: 0

    Scheme is "ultra-dynamic and whatnot", but it is an interpreted language.

    Clisp has dynamic scoping, which is an unrelated concept, but as far as I know it does not have ruby/python/javascript style runtime dynamic typing... I think you may be confusing the issue.

    Objective-c is a better example of a compiled language that supports dynamic types... that's why ruby and python plug into the Cocoa libraries so well.

  24. no I'm not by Trepidity · · Score: 1

    Common Lisp is every bit as dynamic as Scheme, and yes it has fully dynamic runtime typing. It also has optional declarations, but you need not use them, and idiomatic Lisp style doesn't, except when attempting to optimize performance-critical code. Indeed Common Lisp is so dynamic that function calls can't even be resolved at compile time, because functions can redefine other functions (or themselves) at runtime.

    Scheme is also not generally interpreted; there are both compilers and interpreters available.

  25. Re:Apple's work on LLVM by jcr · · Score: 1, Insightful

    Apple should be enormously grateful to the LLVM project.

    So should everyone else who's been living through the dark ages of GCC. The main effect of GCC for the last 20 years has been to suck all of the air out of the room for anyone else who wanted to develop compilers.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  26. Re:GCC avoids high level interprocedural optimizat by jcr · · Score: 3, Insightful

    So, GCC is making what should be technical decisions on a political basis?

    Good to know. That's one more reason to be glad when GCC fades away.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  27. Re:GCC avoids high level interprocedural optimizat by Anonymous Coward · · Score: 0

    Given that the entire reason for the existence of gcc is political, your surprise at the reason for its design decisions merely highlights your ignorance. Now go play in your closed source world and leave the grownups alone.

  28. just you wait... by 3seas · · Score: 3, Insightful

    ... for them to get further along in completing it... it'll slow down.

  29. Who cares? by scurvyj · · Score: 0, Troll

    Who cares? Ruby should just die.

  30. Re:Apple's work on LLVM by Anonymous Coward · · Score: 0

    The main effect of GCC for the last 20 years has been to suck all of the air out of the room for anyone else who wanted to develop compilers.

    That is one of the most retarded statements I've ever read.

  31. not because of ... by v4vijayakumar · · Score: 1

    languages (?!) are getting faster and faster, because of more memory and faster processors ? right ? :)

  32. Re:Apple's work on LLVM by Anonymous Coward · · Score: 0

    Apple should be enormously grateful to the LLVM project.

    So should everyone else who's been living through the dark ages of GCC. The main effect of GCC for the last 20 years has been to suck all of the air out of the room for anyone else who wanted to develop compilers.

    -jcr

    I'd say the one effect GCC has had over the last 20 years is to allow Apple to survive.

    No way Apple could've shipped a decent, cross platform compiler without GCC's existence. No way could Apple have had their skunkworks intel project without GCC's existence. iPod compiling? OS X on arm? All with a compiler you can customise & redistribute to your heart's content.

    You should thank RMS. If you've got Apple stock, you owe him a debt of gratitude.

  33. Re:GCC avoids high level interprocedural optimizat by Anonymous Coward · · Score: 0

    So, GCC is making what should be technical decisions on a political basis?

    GCC is making decisions to protect their intellectual property.

    You're statement is like saying:

    Apple aren't releasing source to the iPhone? That's making a technical decision on a political basis!!!!1!

  34. Re:GCC avoids high level interprocedural optimizat by Lars+T. · · Score: 1

    So, GCC is making what should be technical decisions on a political basis?

    GCC is making decisions to protect their intellectual property.

    So now suddenly there is such a thing as IP?

    --

    Lars T.

    To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

  35. Re:GCC avoids high level interprocedural optimizat by Anonymous Coward · · Score: 0

    s/IP/copyright/

  36. Re:Apple's work on LLVM by jcr · · Score: 2, Interesting

    You may not want to believe it, but when GCC came out there was a pretty healthy competition going with plenty of vendors offering C compilers, and driving each other to improve their products. RMS decided to put them out of business, and the upshot was that commercial compiler development came to a screeching halt, with a few exceptions like IBM and Motorola working on their optimizers. There were a few scattered academic projects going on, but GCC wiped out everyone in the compiler business besides microsoft and metrowerks.

    Fortunately, one of those academic projects came to Apple's attention, and it's about to bring the dark ages to an end.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  37. Re:GCC avoids high level interprocedural optimizat by jcr · · Score: 1, Troll

    Now go play in your closed source world and leave the grownups alone

    Grownups need to make a living, sunshine. Very few people can get a MacArthur grant and extend their adolescence indefinitely.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  38. Re:GCC avoids high level interprocedural optimizat by jcr · · Score: 1

    Apple aren't releasing source to the iPhone? That's making a technical decision on a political basis!!!!1!

    You're not clear on the difference between a technical and a political decision.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  39. Re:Apple's work on LLVM by jcr · · Score: 1

    I'd say the one effect GCC has had over the last 20 years is to allow Apple to survive.

    I'd say that's quite a stretch. Apple used GCC because there were few alternatives. GCC sharply reduced the number of alternatives. See how that works?

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  40. Re:GCC avoids high level interprocedural optimizat by glenstar · · Score: 0, Flamebait

    wait... is there someone who actually understands economics on ./? Someone who understands that hundreds/thousands of hours of work on software is actually worth... GASP!... Money!? Someone who understands that maybe... just maybe... giving away the code that you spent a lot of money/time/effort on does not make sense?

    There is good reason I own the gplisshitty.com domain...

  41. Re:Apple's work on LLVM by rmav · · Score: 3, Insightful

    The main effect of GCC for the last 20 years has been to suck all of the air out of the room for anyone else who wanted to develop compilers.

    That is one of the most retarded statements I've ever read.

    No. What the poster said is true. Also unfair, because GCC is a very useful tool, but it still had a bad influence as well. GCC is extremely useful and produces decent code as well, but it has effectively stifled a lot of C/C++ compiler research. And it seems to become slower with each release. I have a lot of code that was faster with 2.95 than with any 3.x release, and with 4.x it is even slower.

    Now, LLVM is still a mixed bag, sometimes code is much faster, sometimes a bit slower, and does not compile everything I throw at it, but it is impressive technology. It has a more modern infrastructure, and finally allows things like compiling to bytecode and dynamic run-time optimisation with C. It may even allow for CPU-independent operating systems in the future, where you have LLVM bytecode in the binaries that will run like natively-compiled code once loaded.

    I compiled some C programs _to_ LLVM bytecode and then ran them on my mac.

    Their performance was comparable, oftentimes better, than that of the same programs compiled with a recent GCC. And I can still add inline assembler, which then is used only on the right architecture, if I provide C alternatives.

    Think about this. This has the potential of *finally* freeing us from dependence on a CPU ISA. It may be an Apple-sponsored project, but we all should be grateful to them that they are actually pushing it.

    Roberto

  42. Re:Apple's work on LLVM by Anonymous Coward · · Score: 0

    You may not want to believe it, but when GCC came out there was a pretty healthy competition going with plenty of vendors offering C compilers,

    You may not be aware of it, but when Ford started making the model T, there was a petty healthy competition going with plenty of vendors offering buggy's.

    The main effect of the automobile for the next 20 years has been to suck all of the air out of the room for anyone who wanted to develop buggies.

    (Isn't that a stupid statement?)

  43. Re:GCC avoids high level interprocedural optimizat by Anonymous Coward · · Score: 0

    not clear on the difference between a technical and a political decision.

    What's the technical reason that the iPhone source code isn't published?

  44. Re:Apple's work on LLVM by GreatBunzinni · · Score: 1

    So I take it you never heard of Intel C++ compiler, Microsoft's Visual C++ compiler, Comeau C/C++, Digital Mars C++, Open64, etc... They must be figments or our collective imagination.

    --
    Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
  45. Apple fan flaming OSS??? by theolein · · Score: 1

    I'm not sure if you were flaming OSS there, but you do realise that Apple owes a great deal to OSS and that much of what is OSX would be next to impossible without it, given that the BSD part of OSX is, in fact, OSS.

    1. Re:Apple fan flaming OSS??? by DECS · · Score: 2, Insightful

      While that's certainly true, OSS also benefits a lot from Apple. Without Mac OS X, BSD would have 25 million fewer users exercising its code.

      Apple also owns CUPS and finances LLVM and WebKit and initiated Darwin Calendar Server and lots of other projects. Had the world not rejected NeXT and Unix to race after Microsoft's vaporware in the 90s, all the effort at reinventing BSD as Linux could have been united into a single OSS effort. So Apple has been working against the tide to return the world back to open, interoperable software.

      I think open interoperability is more important that forcing companies to propagate an ideology that only hardware should be marketable.

    2. Re:Apple fan flaming OSS??? by Anonymous Coward · · Score: 0

      Had the world not rejected NeXT and Unix to race after Microsoft's vaporware in the 90s, all the effort at reinventing BSD as Linux could have been united into a single OSS effort.

      You think if OS X had been around in 1991 linus wouldn't have bothered?

      What a fucking retard!

  46. Re:GCC avoids high level interprocedural optimizat by Anonymous Coward · · Score: 0

    You are not clear on the difference either, are you. Whether the source code of a piece of software, any software, should be opened or not is entirely a political *decision*. How a compiler should work internally is a technical *decision*. You don't need technical reasons to make a political decision and you shouldn't consider political reasons when making a technical decision.

  47. Re:Code signing requirements that vary per languag by FooBarWidget · · Score: 1

    What are you talking about? This is about server-side software, not executable applets in clients' browsers.

  48. Re:GCC avoids high level interprocedural optimizat by Anonymous Coward · · Score: 0

    GCC is making decisions to protect their intellectual property.

    No, they're not.

  49. Re:Apple's work on LLVM by Anonymous Coward · · Score: 0

    Are you honestly claiming that a voluntary project and a voluntary userbase "killed" a commercial market? Do you realize how ridiculous that sounds?

    Again (if you didn't get it) -- the entire process was 100% voluntary. There were no patents involved, no lawsuits, no wrongdoing at all. Just pure voluntary effort. If you don't like this, then you and the rest of the industry have every chance and every right to try to change it.

    So what are you waiting for? If you or another company has something better to offer, then we'd love to see it. If we deicide that your improvements aren't worth the cost, then so be it. Good luck!

  50. "could" by Anonymous Coward · · Score: 0

    Enough said.

  51. Wot? by Anonymous Coward · · Score: 0

    I thought Ruby was gay too?

  52. gcc permitted Apple to survive... heh. by Gary+W.+Longsine · · Score: 1

    Mod parent funny! The flip side of this coin is that gcc has placed certain shackles on what's possible for Apple and others to do. LLVM is about to break those chains.

    I, for one, welcome our new really-truly-freely-licensed-compiler-(not-kinda-sorta-free-as-in-gcc) overlords.

    --
    If you mod me down, I shall become more powerful than you could possibly imagine.
  53. Re:Apple's work on LLVM by Pollardito · · Score: 1

    I took him to mean that competition breeds improvements, whether they're made via volunteer development or not.

    One thing I didn't like about the post was the statement that it was GCC that wiped everybody out, as at least some vendors (e.g. Borland) were wiped out by MS. Several other vendors had their compilers stagnate due to the fact that their OS lost a lot of marketshare.

  54. Eventually, you may need AJAX or... by tepples · · Score: 1

    This is about server-side software, not executable applets in clients' browsers.

    Eventually, your server-side software may have to communicate with an executable applet in clients' browsers. Without code signing, this applet can be written only in JavaScript (AJAX), ActionScript (Flex SDK), C# or another CLR language (Silverlight 2), or Java or another JVM language (Java applet viewer).

  55. Re:Code signing requirements that vary per languag by tepples · · Score: 1

    This is about server-side software

    Another thing I forgot to mention: Web hosts may restrict what kinds of server-side software may run. For example, a web host may forbid customers not on a dedicated or virtual dedicated server plan from running uploaded EXE files but allow code written for JSP, ASP.NET, Ruby, or one of the P languages.

  56. Re:Apple's work on LLVM by Anonymous Coward · · Score: 0

    Only a small minority of GCC has been contributed by volunteers. The rest has been developed by people getting paid for it or academic researchers.

  57. Re:Apple's work on LLVM by makomk · · Score: 1

    No. Back when gcc was created, there were plenty of compilers - but there was also a proliferation of platforms and architectures, most of which had their own from-scratch vendor compiler that sucked. The reason gcc caught on was partly that it was a sort of baseline for compiler quality - vendor compilers that were worse than gcc could be replaced by it, so that a semi-decent compiler was available everywhere.

  58. Re:GCC avoids high level interprocedural optimizat by Anonymous Coward · · Score: 0

    So now suddenly there is such a thing as IP?

    Slashdot comments (with the exception of yourself) are from a single hive-mind, so finding a contradiction between what an AC said today & yesterday is exactly the same as a real person contradicting themselves!!!!1!

    Well done - give yourself a pat on the back. This 'Anonymous Coward' character has been allowed to get away with contradicting themselves for far too long.

    (You fucking retard).

  59. Re:Apple's work on LLVM by Anonymous Coward · · Score: 0

    Apple used GCC because there were few alternatives.

    So, basically you're angry at GCC for providing a compiler free of charge that Apple could make money from?

    Gosh, if only GCC hadn't existed - Apple would've been able to license a PPC/intel compiler for plenty of money & divert engineers from other projects to customise it.

    Damn you GCC! *shakes fist*

  60. Re:Apple's work on LLVM by jcr · · Score: 1

    So, basically you're angry at GCC for providing a compiler free of charge that Apple could make money from?

    Project much? I'm not angry about the effects of GCC on the compiler business, I just pointed out what it's effects were.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  61. Re:Apple's work on LLVM by Anonymous Coward · · Score: 0

    Well, you said the main effect of a freely distributable cross platform compiler was its effect on the competition.

    Consider the enormous benefits GCC had on hardware manufacturers (like Apple), it's pretty obvious that you've got some anger issues towards the GCC guys.

    Little bit sad really - biting the hand that feeds you & all.

  62. Re:Apple's work on LLVM by jcr · · Score: 1

    it's pretty obvious that you've got some anger issues towards the GCC guys.

    I already told you I didn't. Why do you insist that I do?

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  63. Re:Apple's work on LLVM by Anonymous Coward · · Score: 0

    You're anger is clearly unconscious - a little sad that you don't realise yourself - but it's a fairly common affliction.

  64. Re:Apple's work on LLVM by jcr · · Score: 1

    You're anger is clearly unconscious

    Guess again, armchair shrink.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  65. Re:Apple's work on LLVM by Anonymous Coward · · Score: 0

    Your anger at the FSF clearly shows, yet you say you're not angry - the possibilities are:

    1) You're lying.
    2) Your anger is subconscious.

  66. Re:Apple's work on LLVM by jcr · · Score: 1

    You forgot 3) you're wrong.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  67. Re:Apple's work on LLVM by Anonymous Coward · · Score: 0

    "You may not be aware of it, but when Ford started making the model T, there was a petty healthy competition going with plenty of vendors offering buggy's."

    Yes, it is a stupid statement. Ford didn't invent the automobile, dummy. There *were* a lot of automobile manufacturers before the model T. They were, however, much more expensive, being luxury products. There were even electric cars.

  68. Doesn't look like it by pavon · · Score: 1

    The speed improvements in the MacRuby experimental branch come from using LLVM to generate code and from using the ObjC Runtime (for method dispatch and garbage collection) rather than a homebrew Ruby runtime like the other interpreters.

    Squirrelfish does not use LLVM. I imagine using LLVM for JIT compilation of javascript would have to much overhead, and could be more difficult to integrate into the brower DOM interface.