Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #35667 > unrolled thread

Re: Java is faster!

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Java is faster! Arne Vajhøj <arne@vajhoej.dk> - 2016-09-29 21:17 -0400
    Re: Java is faster! Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-29 22:23 -0400
      Re: Java is faster! Arne Vajhøj <arne@vajhoej.dk> - 2016-10-01 11:17 -0400
        Re: Java is faster! Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-01 12:54 -0400

#35667 — Re: Java is faster!

On 9/23/2016 9:31 AM, Stefan Ram wrote:
>       "Java is faster!
>       In terms of throughput in a long running system ...
>       For specific applications ...
>       On a well tuned JVM ...
>       With near-optimal GC strategy selected ..."
>
>   says Chandler Carruth, one of Google's C++ experts. (JFTR)

Java JIT and GC are pretty good today.

No surprise that it is faster "For specific applications".

There are probably also some other specific applications where
C++ are faster.

The real point is that throughput is not a decisive
factor in picking the language.

Arne

[toc] | [next] | [standalone]

#35672

On 9/29/2016 9:17 PM, Arne Vajhøj wrote:
> On 9/23/2016 9:31 AM, Stefan Ram wrote:
>>       "Java is faster!
>>       In terms of throughput in a long running system ...
>>       For specific applications ...
>>       On a well tuned JVM ...
>>       With near-optimal GC strategy selected ..."
>>
>>   says Chandler Carruth, one of Google's C++ experts. (JFTR)
> 
> Java JIT and GC are pretty good today.
> 
> No surprise that it is faster "For specific applications".
> 
> There are probably also some other specific applications where
> C++ are faster.
> 
> The real point is that throughput is not a decisive
> factor in picking the language.
> 
> Arne
> 
> 

I also think it would depend on how efficient the C++ coding is.  I've
seen some awfully bad C++ code which works at a snail's pace, and other
C++ code which does the same thing in the blink of an eye.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#35678

On 9/29/2016 10:23 PM, Jerry Stuckle wrote:
> On 9/29/2016 9:17 PM, Arne Vajhøj wrote:
>> On 9/23/2016 9:31 AM, Stefan Ram wrote:
>>>       "Java is faster!
>>>       In terms of throughput in a long running system ...
>>>       For specific applications ...
>>>       On a well tuned JVM ...
>>>       With near-optimal GC strategy selected ..."
>>>
>>>   says Chandler Carruth, one of Google's C++ experts. (JFTR)
>>
>> Java JIT and GC are pretty good today.
>>
>> No surprise that it is faster "For specific applications".
>>
>> There are probably also some other specific applications where
>> C++ are faster.
>>
>> The real point is that throughput is not a decisive
>> factor in picking the language.
>>
>> Arne
>>
>>
>
> I also think it would depend on how efficient the C++ coding is.  I've
> seen some awfully bad C++ code which works at a snail's pace, and other
> C++ code which does the same thing in the blink of an eye.

There are a lot of bad C++ code out there.

But Chandler Carruth is member of ISO C++ standard committee and
heads Googles work with the CLang/LLVM, so my guess is that
he can recognize good and bad C++ code.

Arne

[toc] | [prev] | [next] | [standalone]

#35681

On 10/1/2016 11:17 AM, Arne Vajhøj wrote:
> On 9/29/2016 10:23 PM, Jerry Stuckle wrote:
>> On 9/29/2016 9:17 PM, Arne Vajhøj wrote:
>>> On 9/23/2016 9:31 AM, Stefan Ram wrote:
>>>>       "Java is faster!
>>>>       In terms of throughput in a long running system ...
>>>>       For specific applications ...
>>>>       On a well tuned JVM ...
>>>>       With near-optimal GC strategy selected ..."
>>>>
>>>>   says Chandler Carruth, one of Google's C++ experts. (JFTR)
>>>
>>> Java JIT and GC are pretty good today.
>>>
>>> No surprise that it is faster "For specific applications".
>>>
>>> There are probably also some other specific applications where
>>> C++ are faster.
>>>
>>> The real point is that throughput is not a decisive
>>> factor in picking the language.
>>>
>>> Arne
>>>
>>>
>>
>> I also think it would depend on how efficient the C++ coding is.  I've
>> seen some awfully bad C++ code which works at a snail's pace, and other
>> C++ code which does the same thing in the blink of an eye.
> 
> There are a lot of bad C++ code out there.
> 
> But Chandler Carruth is member of ISO C++ standard committee and
> heads Googles work with the CLang/LLVM, so my guess is that
> he can recognize good and bad C++ code.
> 
> Arne
> 
> 

Maybe.  I have nothing against Chandler - I don't know him except by
title.  But I've seen some "experts" working for big corporations which
aren't nearly as good as they claim to be - or people think they are.
This includes technology companies, where management should know better.
 It also has included some people on standards committees.

Often times people who are in such positions are there more for their
political savvy and management ability than their programming ability.
Their job isn't to write code - it's to deal with people.

OTOH, I have seen some excellent programmers who would never be in such
a position because of their lack of ability to deal well with people.

Of course, these are broad generalizations, and there is a wide range of
people between, as well as people who are good programmers and good
managers.  They are about as common in business as bad programmers with
bad people skills.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web