101–110 of 190 posts
It would be interesting to see an output of the compiler flags used in the C++ program that was benchmarked. The build script doesn't set an optimization level so it would default to -O0: https://github.com/ExaScience/elprep-bench/blob/master/cpp/m... I am sure they didn't benchmark it like this but it would be interesting to see the flags that /were/ used.
The fact that gc is well suited to this application isn't suprising but what I thought was interesting was that subtracting the time to do the deallocation from the C++ benchmark brought it into line with Go. In other words, ignoring mem management, for this application, Go and C++ performed on par.
The rest is a lot of string manipulation. If you are not taking advantage of being able to layout your objects carefully and avoid memory avoiding allocations, I wouldn't expect C++ to have any particular advantage over Go or Java in in this particular scenario.
After quickly glancing the code, I concluded that they wrote C++ like there is no static type. It seems they faithfully ported the very dynamic nature of their existing code to C++ without thinking. Like what is this? https://github.com/ExaScience/elprep-bench/blob/master/cpp/f... auto alns = any_cast >>>(data); So the data is sam_alignment type inside shared_ptr inside deque inside another share_ptr inside god forbi…
> They really like std::deque and use it everywhere even though the sizeof(T) is like a few dozen bytes at best so they should rather use std::vector. The data structure of deque is a list of array. while it can amortize the continious adding of the elements to front or back, since the element size is very small, they should rather use vector. Are you saying that access patterns (push/pop front/back) never matter and…
"but the standard deque data type is really quite bad. I wouldn't recommend anyone use it for anything. if you look at the implementation constraints, the constraints placed upon its iterators, and its invalidation constraints, it's painted into a very unpleasant corner and it has very few opportunities to be an efficient data structure."
Earlier quoted context omitted.
We should break ABI on unordered map just to stop embarrassing ourselves in public and in front of new users.
why not just define std::dict or something like that that is better?
> Based on our benchmark results, we selected Go as our new implementation language for elPrep, and recommend considering Go as a good candidate for developing other bioinformatics tools for processing SAM/BAM data as well. They don't seem to take into account that their results depend on their own proficiency in each programming language.
> They don't seem to take into account that their results depend on their own proficiency in each programming language. If they're going to implement it as well, then that's perfect. They now know which language they should be using with their proficiency. In some other team, Java might have been #1. The overall best results with a great team would almost certainly be achievable by using C++. But this is what worked…
They could've just saved themselves the trouble and said "Anyone fancy doing this in C++? No. Great, that's that tricky question off the table!" Rather thna going through this ridiculous exercise of writing bad C++ in order to justify not using C++. If we really believe that this is just a way of idnetifying a revealed preference fine, but engineers should be smart enough to not need to trick thesmlves into coming to the obvious conclusion.
This may indeed have some performance benefits, but it's a very impractical approach from a hardware point of view. Few places doing processing of genomic data will have many compute nodes with > 256GB memory, yet that would barely process 1 sample with this framework. God forbid you have a family of samples or tumor/normal comparison samples to analyse and need several genomes in memory together.
Genomes are for the most part massively parallelisable and nearly every other toolkit I have seen has put that first and foremost in its design approach. Ensuring tools process data in a streaming manner and pipe between each other is a basic expectation of most genomic data tools.
Which is all to say ... this is a very strange beast and I'm not sure a lot of conclusions can be drawn from it that generalise to other activities or approaches.
Earlier quoted context omitted.
They are atomic in the sense that it is not possible to observe the intermediate states and they are not data races. It is extremely hard though to implement them in a lock-free way without a true DCAS (which pretty much no architecture implements). I think all implementations use spinlock pools. I guess transactional hardware could be used. This is one of the reasons why GC does make it easier to implement some lock…
> without a true DCAS (which pretty much no architecture implements) Does x86-64's cmpxchg16b not qualify?
That said, some of the code used is quite... odd.
Guys hire better C++ programmers rather making stupid claims.