That only demonstrated that poor usage of the language can make C++ slow.
Comparison of C++17, Go, and Java for a next-generation sequencing tool
31–40 of 190 posts
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#32Very surprising result. I wouldn’t have bet that this is what would have happened. But anyone working on language perf should take note even though it’s just one result from one team and one application. Of course they probably used C++ in a not great way and probably use Go in a better way. But maybe that is caused by something in Go that encourages good behavior or at least encourages the kind of behavior that Go o…
> I wouldn’t have bet that this is what would have happened.
Which part of the results are you referring to? It's well-known that reference counting has significantly lower throughput that tracing garbage collectors, so the fact that C++ is outperformed here isn't surprising at all.
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#33Earlier quoted context omitted.
In C/C++ we have the possibility to avoid dynamic allocation altogether and to use system features like memory mapping. If we use C++ the same way as Java (everything dynamically) it's not too surprising the result is not (much) faster than Java.
Their original implementation was in common lisp. Common Lisp also lets you use mmap (in fact it's not that uncommon to do so if you have a large amount of mostly static data) to manage your memory manually. They clearly wanted automatic memory management, so the C++ implementation is reasonable. A fairer comparison might have used MPS or boehm instead of refcounting, but I suspect the results would have been similar…
> the C++ implementation is reasonable
Fig. 4 shows that deallocation, presumably of objects allocated during the first phase, takes half as long as the first phase itself. Unless the nature of the problem solved by the program requires you to have a ton of objects with shared mutability (the use case for shared_ptr), and requires you to make a lot of allocations up-front without knowing if you will need them, the memory thrashing occurring does not seem reasonable.
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#34I thought it was well known that reference counting is slower than all but the worst tracing GCs.
It's not well known, because it's not true, at least not absolutely. Speed could either mean latency or throughput. Reference counting is almost always worse than GC at throughput, but is usually better for latency.
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#35Earlier quoted context omitted.
Their original implementation was in common lisp. Common Lisp also lets you use mmap (in fact it's not that uncommon to do so if you have a large amount of mostly static data) to manage your memory manually. They clearly wanted automatic memory management, so the C++ implementation is reasonable. A fairer comparison might have used MPS or boehm instead of refcounting, but I suspect the results would have been similar…
> Common Lisp also lets you use mmap But not without allocating dynamic memory and copying data. > They clearly wanted automatic memory management Most likely because of some misconceptions. > so the C++ implementation is reasonable. How so? > but I suspect the results would have been similar Don't forget the data sets to be filtered, sorted an analyzed are up to 200 GB.
> > Common Lisp also lets you use mmap
> But not without allocating dynamic memory and copying data.
Sure it does. In SBCL you can force a stack allocation (though rarely does it improve performance), and very short-lived values do not leave registers in any case.
> > They clearly wanted automatic memory management
> Most likely because of some misconceptions.
There are both good and bad reasons to want automatic memory management. At least one good reason it it would decrease the porting effort by keeping the code similar.
> > so the C++ implementation is reasonable.
> How so?
Using reference counting is a reasonable way to get automatic memory management in C++
> > but I suspect the results would have been similar
> Don't forget the data sets to be filtered, sorted an analyzed are up to 200 GB.
Which is going to be rough on any automatic memory management system, which makes using a language with a better ecosystem of automatic memory management more performant.
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#36Very surprising result. I wouldn’t have bet that this is what would have happened. But anyone working on language perf should take note even though it’s just one result from one team and one application. Of course they probably used C++ in a not great way and probably use Go in a better way. But maybe that is caused by something in Go that encourages good behavior or at least encourages the kind of behavior that Go o…
> I wouldn’t have bet that this is what would have happened. Which part of the results are you referring to? It's well-known that reference counting has significantly lower throughput that tracing garbage collectors, so the fact that C++ is outperformed here isn't surprising at all.
If either of those affects performance there are WAY too many memory allocations happening.
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#37They should benchmark Java's implementation with different GCs...
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#38I thought it was well known that reference counting is slower than all but the worst tracing GCs.
It's not well known, because it's not true, at least not absolutely. Speed could either mean latency or throughput. Reference counting is almost always worse than GC at throughput, but is usually better for latency.
I intended it to mean throughput.
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#39Earlier quoted context omitted.
> I wouldn’t have bet that this is what would have happened. Which part of the results are you referring to? It's well-known that reference counting has significantly lower throughput that tracing garbage collectors, so the fact that C++ is outperformed here isn't surprising at all.
If either of those affects performance there are WAY too many memory allocations happening.
Sure, but I guess that's the point --- the GCs in Java and Go can handle any allocation pattern you throw at them reasonably well, but there's not, as far as I know, such a "one-size-fits-all" solution in C++ (not that it needs one.)
Re: Comparison of C++17, Go, and Java for a next-generation sequencing tool
#40"We have not performed a detailed comparison against the original version of elPrep implemented in Common Lisp, but based on previous performance benchmarks, the Go implementation seems to perform close to the Common Lisp implementation." LMFAO.