Re: [go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

['Isaac Gouy' via golang-nuts]

On Tuesday, March 12, 2019, 12:54:47 PM PDT, Robert Engels wrote:

I swear you are just trolling now or looking at the wrong things. Review 
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-gpp-2.html
>  
> and 
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-gcc-1.html
>
> They are some of the slowest. Not surprisingly they also are the most 
> plain Jane solutions and easiest to understand and don’t use specialized 
> memory pools.
>

 
By "looking at the wrong things" do you mean looking at a C++ program 

 
that uses a boost library ? 

Doesn't that boost library  provide *"off the shelf 
memory management"* ?




On Tuesday, March 12, 2019 at 11:12:44 AM UTC-7, Isaac Gouy wrote:
>>
>> On Monday, March 11, 2019, 3:54:56 PM PDT, Robert Engels wrote:
>>
>> > Yes, so use Java - for this synthetic benchmark. I’m not sure what the 
>> point is you are trying to make. 
>> > Both Java and Go outperform the C and C++ solutions using off the shelf 
>> memory management in the binary tree tests. 
>>
>> In what way do Java and Go outperform the C and C++ solutions there?
>>
>> Those Java and Go programs are slower ? 
>> 
>>
>>
>> > As the real world application demonstrates both Java and Go offer 
>> superior performance to C++ in standard use cases. 
>>
>> The authors are admirably specific in their recommendation — "Based on 
>> our positive experiences, we recommend authors of other bionformatics 
>> tools  for processing SAM/BAM data, and potentially also other sequencing  
>> data  formats, to  also  consider Go as an implementation language." 
>>
>>
>> ==
>>
>> On Monday, March 11, 2019, 4:10:21 PM PDT, Robert Engels wrote: 
>>
>> > You are 100% correct - that is why they have exactly 0 value. Nothing 
>> to see here, please move on...
>>
>> On the contrary, there is value and there is plenty to see.
>>
>>
>> ==
>>
>> On Monday, March 11, 2019, 4:17:02 PM PDT, Robert Engels wrote:
>>
>> > Also, you realize that Java  has implemented auto vectorization for a 
>> long time...
>>
>> I do realize that. (I was using analogy).
>>
>>
>> > But If you want to spend your time coding and debugging C++ or C no one 
>> here is stopping you.
>>
>> I won't spend time coding and debugging C++ or C.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

['Isaac Gouy' via golang-nuts]

On Monday, March 11, 2019, 3:54:56 PM PDT, Robert Engels wrote:

> Yes, so use Java - for this synthetic benchmark. I’m not sure what the 
point is you are trying to make. 
> Both Java and Go outperform the C and C++ solutions using off the shelf 
memory management in the binary tree tests. 

In what way do Java and Go outperform the C and C++ solutions there?

Those Java and Go programs are slower ? 



> As the real world application demonstrates both Java and Go offer 
superior performance to C++ in standard use cases. 

The authors are admirably specific in their recommendation — "Based on our 
positive experiences, we recommend authors of other bionformatics tools  
for processing SAM/BAM data, and potentially also other sequencing  data  
formats, to  also  consider Go as an implementation language." 


==

On Monday, March 11, 2019, 4:10:21 PM PDT, Robert Engels wrote: 

> You are 100% correct - that is why they have exactly 0 value. Nothing to 
see here, please move on...

On the contrary, there is value and there is plenty to see.


==

On Monday, March 11, 2019, 4:17:02 PM PDT, Robert Engels wrote:

> Also, you realize that Java  has implemented auto vectorization for a 
long time...

I do realize that. (I was using analogy).


> But If you want to spend your time coding and debugging C++ or C no one 
here is stopping you.

I won't spend time coding and debugging C++ or C.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

['Isaac Gouy' via golang-nuts]

On Wednesday, March 6, 2019 at 5:44:21 AM UTC-8, Robert Engels wrote:
>
> As I pointed out long ago on stackoverflow the benchmark games are 
> seriously flawed and should not be used for language performance 
> comparisons. 
>
> As a simple example, look at binary trees. In all of the “fast” 
> implementations, they resort to specialized memory pools that wouldn’t be 
> useable in a highly concurrent system. The Go and Java versions use off the 
> shelf memory management so the code complexity comparisons are not even 
> close. I’m sure you could replicate the performance using off heap 
> structures in Go/Java but who would want to?
>


And yet, you also say  — "So for uses like highly mutable binary trees - 
Go’s lack of a generational garbage collector really hurts 
."

Does that difference show between the Go and Java  programs which use "off 
the shelf memory management" ?


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

[robert engels]

Ask yourself, if the pools are that important for performance, why are they 
external? Because some (often?) times the pool provides worse performance - in 
this particular small benchmark they do not - but a large applications using 
tons of different pools in the goal of “being fast” just might be (over a 
generalized whole application malloc/free)

Similar reasoning applies to why most Java code should not pool objects 
(anymore) - the allocator in most cases is actually more efficient than using a 
pool - just a simple pointer bump, and the de-allocator is amortized/concurrent.

> On Mar 6, 2019, at 5:29 PM, 'Isaac Gouy' via golang-nuts 
>  wrote:
> 
> On Wednesday, March 6, 2019 at 5:44:21 AM UTC-8, Robert Engels wrote:
> As I pointed out long ago on stackoverflow the benchmark games are seriously 
> flawed and should not be used for language performance comparisons. 
> 
> As a simple example, look at binary trees. In all of the “fast” 
> implementations, they resort to specialized memory pools that wouldn’t be 
> useable in a highly concurrent system. The Go and Java versions use off the 
> shelf memory management so the code complexity comparisons are not even 
> close. I’m sure you could replicate the performance using off heap structures 
> in Go/Java but who would want to?
> 
> 
> Definition of flawed
> : having a defect or imperfection a flawed diamond
> 
> Please share a perfect alternative comparison ;-) 
> 
> 
> > all of the “fast” implementations, they resort to specialized memory pools
> 
> I doubt `Apache Portable Runtime Pools` were designed to make those tiny 
> programs fast :-)
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

['Isaac Gouy' via golang-nuts]

On Wednesday, March 6, 2019 at 5:44:21 AM UTC-8, Robert Engels wrote:
>
> As I pointed out long ago on stackoverflow the benchmark games are 
> seriously flawed and should not be used for language performance 
> comparisons. 
>
> As a simple example, look at binary trees. In all of the “fast” 
> implementations, they resort to specialized memory pools that wouldn’t be 
> useable in a highly concurrent system. The Go and Java versions use off the 
> shelf memory management so the code complexity comparisons are not even 
> close. I’m sure you could replicate the performance using off heap 
> structures in Go/Java but who would want to?
>



*Definition of flawed: having a defect or imperfection a flawed diamond*

Please share a perfect alternative comparison ;-) 


> all of the “fast” implementations, they resort to specialized memory pools

I doubt `Apache Portable Runtime Pools` were designed to make those tiny 
programs fast :-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

['Isaac Gouy' via golang-nuts]

On Wednesday, March 6, 2019 at 12:41:21 PM UTC-8, Bradlee Johnson wrote:
>
> As the saying goes, "there are lies, damned lies and benchmarks." 
>

After all, facts are facts, and although we may quote one to another with a 
chuckle the words of the Wise Statesman, 'Lies--damned lies--and 
statistics,' still there are some easy figures the simplest must 
understand, and the astutest cannot wriggle out of.

Leonard Henry Courtney, 1895

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

[bradleedjohnson]

As the saying goes, "there are lies, damned lies and benchmarks." 

Java is particularly difficult to get good benchmarks in due to the nature 
of HotSpot and JIT compilation. I was listening to James Gosling recently 
and he pointed out that there are over 100 flavors of JIT compilation on 
the JVM for x86 alone. Essentially the JVM can tweak the compilation 
parameters for the specific processor it is running on. HotSpot also 
requires warm up time for it to observe sections of code that are running 
repeatedly which it then inlines and otherwise optimizes and will JIT 
compile that optimized code as well. That doesn't even get into the JVM 
version or the type of code being run. Where the JVM is really going to hit 
its stride is when you have long running code with a lot of libraries where 
the JVM can profile the code and optimize it over time.

I'm a big fan of Go and prefer coding in it but that the JVM ran their code 
a bit faster doesn't surprise me nor does it surprise me that the footprint 
was larger. That's a big concern in the Dockerized world. If every 
container has to has its own JVM before you even start, the memory, thread 
and other resource overhead can get daunting. 

Like any geek, I like benchmarks but just have to take them with a grain of 
salt. 



On Wednesday, March 6, 2019 at 7:44:21 AM UTC-6, Robert Engels wrote:
>
> As I pointed out long ago on stackoverflow the benchmark games are 
> seriously flawed and should not be used for language performance 
> comparisons. 
>
> As a simple example, look at binary trees. In all of the “fast” 
> implementations, they resort to specialized memory pools that wouldn’t be 
> useable in a highly concurrent system. The Go and Java versions use off the 
> shelf memory management so the code complexity comparisons are not even 
> close. I’m sure you could replicate the performance using off heap 
> structures in Go/Java but who would want to?
>
> On Mar 6, 2019, at 7:17 AM, Haddock > wrote:
>
> Benchmarks are always limited, I know. But this might indicate some 
> direction:
>
>
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html
>
> Am Mittwoch, 6. März 2019 14:07:03 UTC+1 schrieb JuciÊ Andrade:
>>
>> That doesn't surprises me at all.
>>
>> A couple years ago I worked for a company where I created prototypes in 
>> Go and production code in C++, using the same architecture and algorithms. 
>> Go version usually ran 15% faster. After some work both versions could be 
>> tuned to run faster, but it amazed me to find that just plain Go code was 
>> faster than the corresponding C++ code.
>>
>> On Thursday, February 28, 2019 at 2:05:55 PM UTC-3, Isaac Gouy wrote:
>>>
>>> "We reimplemented elPrep in all three languages and benchmarked their 
>>> runtime performance and memory use. Results: *The Go implementation 
>>> performs best*, yielding the best balance between runtime performance 
>>> and memory use. While the Java benchmarks report a somewhat faster runtime 
>>> than the Go benchmarks, the memory use of the Java runs is significantly 
>>> higher."
>>>
>>> proggit discussion 
>>> 
>>>
>>> article 
>>>
>>>
>>> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

[Robert Engels]

As I pointed out long ago on stackoverflow the benchmark games are seriously 
flawed and should not be used for language performance comparisons. 

As a simple example, look at binary trees. In all of the “fast” 
implementations, they resort to specialized memory pools that wouldn’t be 
useable in a highly concurrent system. The Go and Java versions use off the 
shelf memory management so the code complexity comparisons are not even close. 
I’m sure you could replicate the performance using off heap structures in 
Go/Java but who would want to?

> On Mar 6, 2019, at 7:17 AM, Haddock  wrote:
> 
> Benchmarks are always limited, I know. But this might indicate some direction:
> 
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html
> 
> Am Mittwoch, 6. März 2019 14:07:03 UTC+1 schrieb JuciÊ Andrade:
>> 
>> That doesn't surprises me at all.
>> 
>> A couple years ago I worked for a company where I created prototypes in Go 
>> and production code in C++, using the same architecture and algorithms. Go 
>> version usually ran 15% faster. After some work both versions could be tuned 
>> to run faster, but it amazed me to find that just plain Go code was faster 
>> than the corresponding C++ code.
>> 
>>> On Thursday, February 28, 2019 at 2:05:55 PM UTC-3, Isaac Gouy wrote:
>>> "We reimplemented elPrep in all three languages and benchmarked their 
>>> runtime performance and memory use. Results: The Go implementation performs 
>>> best,  yielding the best balance between runtime performance and memory 
>>> use. While the Java benchmarks report a somewhat faster runtime than the Go 
>>> benchmarks, the memory use of the Java runs is significantly higher."
>>> 
>>> proggit discussion
>>> 
>>> article
>>> 
>>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

[Haddock]

Benchmarks are always limited, I know. But this might indicate some 
direction:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html

Am Mittwoch, 6. März 2019 14:07:03 UTC+1 schrieb JuciÊ Andrade:
>
> That doesn't surprises me at all.
>
> A couple years ago I worked for a company where I created prototypes in Go 
> and production code in C++, using the same architecture and algorithms. Go 
> version usually ran 15% faster. After some work both versions could be 
> tuned to run faster, but it amazed me to find that just plain Go code was 
> faster than the corresponding C++ code.
>
> On Thursday, February 28, 2019 at 2:05:55 PM UTC-3, Isaac Gouy wrote:
>>
>> "We reimplemented elPrep in all three languages and benchmarked their 
>> runtime performance and memory use. Results: *The Go implementation 
>> performs best*, yielding the best balance between runtime performance 
>> and memory use. While the Java benchmarks report a somewhat faster runtime 
>> than the Go benchmarks, the memory use of the Java runs is significantly 
>> higher."
>>
>> proggit discussion 
>> 
>>
>> article 
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Performance comparison of Go, C++, and Java for biological sequencing tool

[Louki Sumirniy]

It shouldn't really be surprising. Go and Java share the use of interfaces, 
but Go's concurrency is far lighter weight, and on top, Java has the extra 
burden of a virtual machine before it actually hits the CPU as binary code. 
I suspect also that the Go version could handle a much greater level of 
concurrency and then the advantage of compilation would be more visible.

On Thursday, 28 February 2019 18:05:55 UTC+1, Isaac Gouy wrote:
>
> "We reimplemented elPrep in all three languages and benchmarked their 
> runtime performance and memory use. Results: *The Go implementation 
> performs best*, yielding the best balance between runtime performance and 
> memory use. While the Java benchmarks report a somewhat faster runtime than 
> the Go benchmarks, the memory use of the Java runs is significantly higher."
>
> proggit discussion 
> 
>
> article 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.