Java Faster Than C ?

Discussion in 'Java' started by Rishi Boparai, Apr 1, 2008.

  1. Can Java be faster than 'C'? Incredible but true.
     
    Rishi Boparai, Apr 1, 2008
    #1
    1. Advertisements

  2. RedGrittyBrick, Apr 1, 2008
    #2
    1. Advertisements

  3. With the proper JIT Java can be faster than the light!!!!!!!
     
    Andrea Francia, Apr 1, 2008
    #3
  4. Ops. I meant JIT complier.
     
    Andrea Francia, Apr 1, 2008
    #4
  5. Rishi Boparai

    Lew Guest

    "Just Invert Time" compiler?

    The program completes before you start it.
     
    Lew, Apr 1, 2008
    #5
  6. Rishi Boparai

    Roedy Green Guest

    Roedy Green, Apr 1, 2008
    #6
  7. Chase Preuninger, Apr 1, 2008
    #7
  8. Rishi Boparai

    Lord Zoltar Guest

    Nonesense, nothing is faster than c! :p
     
    Lord Zoltar, Apr 1, 2008
    #8
  9. Rishi Boparai

    Roedy Green Guest

    You did two things I consider naughty.

    1. You effectively bashed Microsoft then used http://ibm.com as your
    supporting evidence. You need a more specific URL than that.

    2. It is great to provide web-based information about coding, sample
    code etc. but splitting DISCUSSION just makes it harder for anyone to
    get an answer to a question.
     
    Roedy Green, Apr 1, 2008
    #9
  10. I realized just now. 'c' is also the speed of light! :)
     
    Andrea Francia, Apr 1, 2008
    #10
  11. Rishi Boparai

    Daniel Pitts Guest

    Daniel Pitts, Apr 2, 2008
    #11
  12. Rishi Boparai

    Stefan Ram Guest

    There seems to have been a new benchmark execution
    that shows Jet 6.4 to be about as fast as GCC, while
    VMs also achieved impressive results, but still are
    about half as fast on the average:

    »SUN's JDK has some weak points that can be seen in the
    fannkuch and himeno benchmarks. Without these two
    benchmarks the hotspot server compiler would be almost
    competitive with GCC. Nevertheless JDK 6U6 has gained
    quite a bit performance in comparison to JDK 6U2.«

    http://www.stefankrause.net/wp/?p=9
     
    Stefan Ram, Jul 3, 2008
    #12
  13. Rishi Boparai

    Roedy Green Guest

    When you benchmark different code, the results have a lot to do with
    the skill of the person who tweaks the benchmark. I used to work for
    Univac fine tuning benchmarks. Tiny tweaks would let us skunk the
    competition.

    For your sort of benchmark, you need to let a representative of each
    compiler tweak the code.
     
    Roedy Green, Jul 3, 2008
    #13
  14. This can be overdone. There's the well-known SQL benchmark where the
    winning vendor tweaked their optimizer to recognize the query text and
    return the answer immediately. (They got much slower when extra whitespace
    was added.)
     
    Mike Schilling, Jul 3, 2008
    #14
  15. Rishi Boparai

    Roedy Green Guest

    One of the strategies for winning benchmarks is to provide the
    benchmark. If you have control over that, you can bias it to the
    party you want to win.

    The catch is, it is rare when those composing the benchmark don't have
    bias.

    Knuth has frightened people off EVER tweaking code. People don't
    realise today how tiny changes to code can give you huge boosts, or
    looked at the other way, how tiny errors in coding have huge time
    penalties.
     
    Roedy Green, Jul 3, 2008
    #15
  16. Well, to be honest, how many programmers have ever heard of Knuth, let alone
    know what he's done, and let alone read his books? I became aware of the guy
    early in my career because I used TeX/LaTeX (itself quite rare), and later I
    bought the 3-volume set of TAoCP (and how many developers have done that?).
    Hell, I've even read parts of those books. :)

    I bring that up because it's unlikely, having never heard of Knuth, that
    most coders know the full quote: "We should forget about small efficiencies,
    say about 97% of the time: premature optimization is the root of all evil.
    Yet we should not pass up our opportunities in that critical 3%." In other
    words, go ahead and do it when the decision is informed; don't do it when
    it's not. So many programmers likely do have this vague idea that they
    should not tweak code at all, not until the last moment anyhow (when it's
    entirely possible that a tweak now becomes a hack). I've myself encountered
    the mindset often enough.

    I realize that you aren't suggesting that Knuth himself pooh-poohed all
    optimization.

    AHS
     
    Arved Sandstrom, Jul 3, 2008
    #16
  17. Roedy Green wrote:
    ....
    Huh? Knuth's greatest work contains pseudo-code implementations in a
    sort of assembly language for a machine that never existed. Practical
    use of an algorithm from "The Art of Computer Programming" has
    to begin with reimplementation in a different language.

    Patricia
     
    Patricia Shanahan, Jul 3, 2008
    #17
  18. As stated, it's almost a tautology. Optimization that's a good idea
    isn't premature.
     
    Mike Schilling, Jul 3, 2008
    #18
  19. Rishi Boparai

    Arne Vajhøj Guest

    The programmers with a formal IT education should have heard about
    Knuth.

    Arne
     
    Arne Vajhøj, Jul 3, 2008
    #19
  20. Rishi Boparai

    Arne Vajhøj Guest

    When the word tweaking applies it is usually the wrong form
    of optimization.

    All the "is doing it with this language feature versus doing
    it with this language feature" optimization (which is what I
    consider tweaking) is usually a waste of time.

    What matters is algorithms (which BTW was what Knuth was
    writing about) and architecture.

    Arne
     
    Arne Vajhøj, Jul 3, 2008
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.