Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why git is so fast (or why Java is not as fast as C)

marc.info

Post reply on HN
Print view View original

101–110 of 110 posts

Re: Why git is so fast (or why Java is not as fast as C)

#101

Post by dasil003 »

tentonova wrote: post #92
dasil003 wrote: post #80

Earlier quoted context omitted.

Of course, but that's irrelevant to the utility of git branches. In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. In git though, branches are most commonly used within one developer's workflow. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discretion without imposing any overhead on anyo…

In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. svn cp ^/trunk ^/branches/tentonova-bugfix-x svn co ^/branches/tentonova ~/branch I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discre…

I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here.

Merging.

Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication.

If you're using the limitations of your VCS to manage team communication then you have bigger problems. The obvious analog to the "problem" you mention is people not checking in code because it's not ready yet. Maybe you think this is better because you only want deployable software in your main branch, but for large features that makes the history opaque and leaves your developer effectively without any of the benefits of version control while they are working on the large feature.

Frankly, a lot of the arguments against DVCS smack of the same sort of ignorance that the Java zealots were leveraging against Ruby back when Rails started picking up steam in 2005/2006. There's this fear that powerful features will lead to chaos and are in effect too powerful to be used safely. And the reality is that yes, in environments truly incompetent programmers work, there's definitely a strong argument to be made for limiting the damage they can do. But I think the past few years have borne out the fact that mediocre and merely-competent programmers can make strong use of these tools without leading to disaster.

Re: Why git is so fast (or why Java is not as fast as C)

#102

Post by tentonova »

dasil003 wrote: post #101
tentonova wrote: post #92

Earlier quoted context omitted.

In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. svn cp ^/trunk ^/branches/tentonova-bugfix-x svn co ^/branches/tentonova ~/branch I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discre…

I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here. Merging. Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication. If you're using the limitations of your VCS to manage team communication then you have bigger problems. The obvious analog to the "problem" you mention is people not che…

Merging.

Subversion 1.5, released in June of 2008, supports merge tracking.

If you're using the limitations of your VCS to manage team communication then you have bigger problems.

A simple but sufficiently powerful solution leads to simplified communication. If you're using the complexity of your VCS to hinder team communication and support cowboy coding, then you have bigger problems.

Frankly, a lot of the arguments against DVCS smack of the same sort of ignorance that the Java zealots were leveraging against Ruby back when Rails started picking up steam in 2005/2006 ... But I think the past few years have borne out the fact that mediocre and merely-competent programmers can make strong use of these tools without leading to disaster.

Nobody (intelligent) said there'd be disaster because of the "powerful features", just that operating in that manner would be more expensive than the much simpler alternatives.

Expending more effort with more powerful tools isn't actually an improvement, it's just busy-work -- constantly working on your muscle car instead of driving it.

Re: Why git is so fast (or why Java is not as fast as C)

#103

Post by riffraff »

fauigerzigerk wrote: post #18
axod wrote: post #15

>> "why Java is not as fast as C" Not actually true in reality. Modern JVMs can make on the fly optimizations based on the runtime profile, which would need to be done by hand in C. As said elsewhere though, Java excels when used for long running tasks - servers - backends etc where it can optimize for the long term. It doesn't excel when you try and start up the jvm loads of times for quick individual jobs. I don't…

The post specifically mentiones Java's implementation of memory mapped files, Java's lack of value types and Java's lack of unsigned types. These are very different areas but none of them can be solved by on the fly optimizations or longer running processes.

wrt value types, shouldn't it be partially solved by escape analisys? Cfr: http://weblogs.java.net/blog/forax/archive/2009/10/06/jdk7-d...

not that it would matter much in the case anyway, I guess.

Re: Why git is so fast (or why Java is not as fast as C)

#104

Post by kscaldef »

tentonova wrote: post #91
kscaldef wrote: post #81

Earlier quoted context omitted.

This still feels like the sort of statement that comes from having not worked with a (D)VCS that does branching well. There is no "inherent organizational complexity" in me having a private branch that I share with no one and which is only used for an hour or two while I work on a critical bug fix. What you're talking about seems to be multiple, long-running development or release branches. Those are hard to manage a…

This still feels like the sort of statement that comes from having not worked with a (D)VCS that does branching well. I've worked with both git and hg. There is no "inherent organizational complexity" in me having a private branch that I share with no one and which is only used for an hour or two while I work on a critical bug fix. What's the value of this private branch beyond simply committing to the actual branch?…

Reading this comment and your other comments in this discussion, I think you have some issues which have nothing to do with what version control system is being used. While you keep talking about "hiding code" and "hindering communication" and "cowboy coding", I think about keeping the history of our codebase well-organized so that you can understand the evolution of a single feature, so that commits are logically ordered, so that unrelated changes don't get lumped together because it was the easy thing to do.

To quickly comment on a couple of your other concerns, my local hard-drive is backed up, so that's irrelevant; and I personally feel that code review at the level of individual commits has very little value, and you should instead be reviewing complete feature implementations.

Re: Why git is so fast (or why Java is not as fast as C)

#105

Post by wvenable »

axod wrote: post #100
rbanffy wrote: post #98

Earlier quoted context omitted.

"Yes Java can be faster than C in some situations." Unless the person writing the C implementation is grossly incompetent, I would like to see even one example for that.

You can't see a situation where the JVM can optimize things, inline code, etc at runtime and beat a general C implementation? :/

A Java application will invariably use more much memory than C implementation of almost any non-trivial application. You can inline code all you want, but it'll never change that. The JVM isn't magical -- it's not going to solve all your performance problems. When you're allocating a million tiny little objects with all the necessary accounting you can't optimize that away.

BTW, if it's so obvious why haven't you still provided at least one non-trivial concrete example of Java faster than C?

Re: Why git is so fast (or why Java is not as fast as C)

#106

Post by rbanffy »

axod wrote: post #100
rbanffy wrote: post #98

Earlier quoted context omitted.

"Yes Java can be faster than C in some situations." Unless the person writing the C implementation is grossly incompetent, I would like to see even one example for that.

You can't see a situation where the JVM can optimize things, inline code, etc at runtime and beat a general C implementation? :/

I would say that any C programmer worth his salt (unlike me) knows how to profile the code under a meaningful workload and how to optimize it to be faster.

I remember I used the shortest possible integers and the register keyword in the late 80's far too many times to count.

The point of somewhat higher-level languages like Java (I refuse to say Java is a high-level language - it would be one in the late 80s, but not today) is not to make programs run faster, but to make it easier to make them run correctly.

Re: Why git is so fast (or why Java is not as fast as C)

#107

Post by wglb »

ajross wrote: post #71
wglb wrote: post #52

Earlier quoted context omitted.

That is why the rewording I use is "First make it right, then make it fast". If you make it fast first, then that is premature optomization.

But that's just saying the same thing. The point being made above is that working "correctly" simply isn't enough if performance is a design goal too (or rather, correct operation requires that the software meet the performance goals at design time). So if you start out working on only half the problem, you'll still fail.

My experience has shown me that it is very difficult to know where the performance bottlenecks are without measurement. You can't measure it if you haven't built it, and if it is not correct, why bother?

I have always taken this to mean what the original "premature optimization" quote is all about. I felt that making the statement a little simpler helps my focus.

Re: Why git is so fast (or why Java is not as fast as C)

#108

Post by [deleted] »

kscaldef wrote: post #104
tentonova wrote: post #91

Earlier quoted context omitted.

This still feels like the sort of statement that comes from having not worked with a (D)VCS that does branching well. I've worked with both git and hg. There is no "inherent organizational complexity" in me having a private branch that I share with no one and which is only used for an hour or two while I work on a critical bug fix. What's the value of this private branch beyond simply committing to the actual branch?…

Reading this comment and your other comments in this discussion, I think you have some issues which have nothing to do with what version control system is being used. While you keep talking about "hiding code" and "hindering communication" and "cowboy coding", I think about keeping the history of our codebase well-organized so that you can understand the evolution of a single feature, so that commits are logically or…

[deleted]

Re: Why git is so fast (or why Java is not as fast as C)

#109

Post by fauigerzigerk »

riffraff wrote: post #103
fauigerzigerk wrote: post #18

Earlier quoted context omitted.

The post specifically mentiones Java's implementation of memory mapped files, Java's lack of value types and Java's lack of unsigned types. These are very different areas but none of them can be solved by on the fly optimizations or longer running processes.

wrt value types, shouldn't it be partially solved by escape analisys? Cfr: http://weblogs.java.net/blog/forax/archive/2009/10/06/jdk7-d... not that it would matter much in the case anyway, I guess.

Yes I think you're right that it should help a little in some cases. But the big issue with the lack of value types is memory usage (not in the case of jGit), which isn't solved by escape analysis.

Re: Why git is so fast (or why Java is not as fast as C)

#110

Post by dasil003 »

tentonova wrote: post #102
dasil003 wrote: post #101

Earlier quoted context omitted.

I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here. Merging. Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication. If you're using the limitations of your VCS to manage team communication then you have bigger problems. The obvious analog to the "problem" you mention is people not che…

Merging. Subversion 1.5, released in June of 2008, supports merge tracking. If you're using the limitations of your VCS to manage team communication then you have bigger problems. A simple but sufficiently powerful solution leads to simplified communication. If you're using the complexity of your VCS to hinder team communication and support cowboy coding, then you have bigger problems. Frankly, a lot of the arguments…

If you're using the complexity of your VCS to hinder team communication and support cowboy coding, then you have bigger problems.

This is a blub attitude plain and simple.

Post reply on HN