drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Haynes <philip.hay...@virtualnation.com.au>
Subject Re: LLVM + C++
Date Wed, 24 Oct 2012 20:40:48 GMT
I don¹t 100% know. This is why I am building the performance test case at
the moment with the JVM and supersonic (and am happy to share the load
with other volunteers).

I pretty much have the basis for the Java test with an existing
multi-threaded vector processing engine.
Now previously doing these sort of tests for common use cases (involving
string processing),
_Java_ was faster. Furthermore, I became performance bound due to memory
IO @ around 7 core so further per core optimisation using C++ was a waste
of time as it could not improve performance further.
However, GC pause and other similar factors as the JVM memory footprint
exceeded 4GB became key issues. (This was using both the G1GC and Azul
JVM).

Now these guys are are doing good work with optimised JVM usage.
http://mechanical-sympathy.blogspot.co.uk/2012/10/compact-off-heap-structur
estuples-in.html


That stated, having to go to these sort of lengths to get BigData Java
seems to 
be forcing the use of Java.

Thus, until Google published Supersonic, I thought the route of directly
producing LLVM assembler with a bit of C++ glue code was likely to produce
the best result. However, if Supersonic proves the goods, I for one would
rather a practical solution for drill sooner rather than later.

So we shall seeŠ.

On 25/10/12 3:10 AM, "Appu" <ashwinaravind@gmail.com> wrote:

>Hi,
>
>For the execution code generation does using LLVM + C++ give performance
>advantage over JVM?
>
>
>
>Regards
>Ash win
>
>On Oct 24, 2012, at 6:32 PM, Ted Dunning <ted.dunning@gmail.com> wrote:
>
>> I have been using very standard Sun style with 4 space indentation.
>>This
>> is the standard setting for IntelliJ.
>> 
>> Other aspects of standard code should include lots of tests, clear
>>naming
>> and good comments.
>> 
>> None of this is very controversial.  The only unusual things that Apache
>> projects usually insist on are a) no @author tags in javadoc and b)
>>apache
>> copyright at the top.
>> 
>> Another way to look at it is that we use the Lucene/Hadoop/Mahout style
>> with four spaces instead of 2.  See
>> http://wiki.apache.org/lucene-java/HowToContribute#Making_Changes and
>> http://www.cs.bilgi.edu.tr/pages/standards_project/java_CodingStyle.pdf
>> 
>> For now, I am happy to be a human style checker.
>> 
>> On Wed, Oct 24, 2012 at 12:00 AM, Arunabha Ghosh
>><arunabha.gh@gmail.com>wrote:
>> 
>>> Hi Folks,
>>>              I was wondering if there is an existing style guide for
>>>code
>>> in the Drill project ? If not it would be good to get one defined soon
>>>as a
>>> uniform style throughout the codebase certainly helps. Once the style
>>>guide
>>> is defined, it would be fairly easy to provide config files for
>>> Eclipse/IntelliJ to automatically format according to the Style Guide.
>>> 
>>> Arunabha
>>> 



Mime
View raw message