hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
K-ballo has quit [Ping timeout: 240 seconds]
K-ballo has joined #ste||ar
Yorlik_ has joined #ste||ar
Yorlik has quit [Ping timeout: 265 seconds]
hkaiser has quit [Quit: Bye!]
<K-ballo>
rand() is a bad option
gdaiss[m] has quit [Remote host closed the connection]
HHN93 has joined #ste||ar
<HHN93>
How do I find return type of a function?
<HHN93>
I am aware of result_of_t, invoke_result_t but does HPX have a macro for it?
HHN93 has quit [Quit: Client closed]
hkaiser has joined #ste||ar
HHN93 has joined #ste||ar
HHN93 has quit [Ping timeout: 245 seconds]
Arnav-Negi has joined #ste||ar
akheir1 has joined #ste||ar
akheir has quit [Ping timeout: 256 seconds]
akheir has joined #ste||ar
akheir1 has quit [Ping timeout: 264 seconds]
Arnav-Negi has quit [Quit: Konversation terminated!]
<gnikunj[m]>
Also a google thread discussion where Joel said boost spirit v2 is anywhere from 2.5x to 7x faster than Antlr. I'm sure v3 to bring me some joy now ;)
<gnikunj[m]>
hkaiser K-ballo : are there any spirit v3 programs that parse a relatively complex grammar (not json or single node grammars in examples) that I can look into? Need to understand how I can connect an already built infrastructure (Instructions/Functions etc. classes) to Spirit V3 structs/classes (Boost Fusion only gets me partly there as some types are class/structs/enums that needs to be mapped as well).
<gnikunj[m]>
I've mostly written code in spirit qi as well. hkaiser asked me to try v3 so...
<hkaiser>
gnikunj[m]: the biggest parser in Spirit V3 I have is parsing the performance counter names in HPX
<gnikunj[m]>
hkaiser: not sure how complex that would be. Could you point me to the code for it?
<hkaiser>
however, converting Spirit V2 to V3 is trival (almost a nobrainer), so looking at any V2 code might be an options - and there are plenty complex V2 parsers available
<gnikunj[m]>
Aah, didn't think that. I can look into Phylanx then. That has been my goto.
<hkaiser>
well, the PhySL parser is not too difficult either
<K-ballo>
it's a good idea to keep the parser not too difficult anyways
<K-ballo>
don't go spirit crazy, don't play into attribute compatibility magic, don't play into semantic actions, don't play into validation, that's all post
<gnikunj[m]>
K-ballo: need to write a parser for a language ;) The corresponding Antlr4 grammar for it is about ~150 lines of grammar. Given I need to create AST myself in spirit v3, I would've liked some inspiration to begin the work.
<K-ballo>
I don't see how a language changes things
<hkaiser>
the spirit parser should be constructing the AST directly, with the constraints K-ballo mentioned, just keep the types the parser produce as is and let it compose the hierarchical AST
<K-ballo>
for example, don't have your language parser deal with precedence and associativity, just parse a simple dumb expression and handle those later
<hkaiser>
it's more of a parse tree actually, not even quite an AST
<K-ballo>
you _can_ the parser deal with precedence and associativity, but it's simply not a good idea... best case scenario you end up with considerable more complex code that takes way longer to compile to do just the same
<K-ballo>
and with a spirit parser that also means you can't debug it, so you better get it right the first time
<gnikunj[m]>
Right, but I do need to parse the tree and set values (semantic actions/boost fusion).
<K-ballo>
don't use semantic actions
<K-ballo>
have your ast match the grammar's natural attributes, no semantic actions, no compatibility magic
<K-ballo>
you can have two ASTs: one that's the result of the parser, and one that's the result of an actual "compilation" phase (with type and semantic rules baked into it)
<gnikunj[m]>
That's a little hard to do as of now the way code is already written. I will need some plug points. But I get your point and try for a KISS approach.
<K-ballo>
so you are working with an existing x3 parser?
<K-ballo>
do NOT try to parse into an existing ast, use an intermediate
<gnikunj[m]>
No. It's not as straightforward and I'm bound by NDA :/
<K-ballo>
alright, in that case I guess I don't need to help you
HHN93 has joined #ste||ar
<HHN93>
T *arr[4] creates an array of 4 elements, populated with garbage
<HHN93>
is there something similar I can do for a vector?
<hkaiser>
no
<hkaiser>
vector calls the constructor for all elements
<HHN93>
I wanted to try vectorising generate_n by generating 4 elements first, storing them in a vector
<HHN93>
and then loading them into the corresponding position (this is more likely to be vectorised)
<HHN93>
so any suggestion on how I can do it? Should I use a C-style array?
<hkaiser>
why can't you use a vector?
<HHN93>
if the default constructor is deleted?
<HHN93>
it would throw an error, right?
<hkaiser>
std::vector<int> v(4); creates a vector with 4 default initialized integers
<HHN93>
std::vector<T> v(4) where T has no default constructor
<hkaiser>
does T have another constructor?
<HHN93>
let's say, yes
<hkaiser>
use std::vector<int> v(4, 0); if it can be constructed from an int, for instance
<HHN93>
I want to add vectorisation to generate_n(v.begin(), v.end(), f)
<HHN93>
v is vector<T>
<HHN93>
I am generating the object using f and moving it into the corresponding iterator
<HHN93>
this code will fail to compile if f_RetTy has no default constructor, right?
<HHN93>
so can I do anything about it?
<hkaiser>
yes, indeed
<HHN93>
what do I do?
<hkaiser>
vectorization makes sense for types only that can be used in vector registers: int, double, float, etc.
<hkaiser>
all of those are default constructibe
<HHN93>
ok, but I don't think users would be happy when they move from std::generate_n to hpx::generate_n and see that their compilation fails
<HHN93>
can I do something or do I just drop the idea?
<hkaiser>
HHN93: well, for non-vectorizable code this wouldn't be used
<hkaiser>
non-vectorizable types*
<HHN93>
We do try to stick to std right? and also just a note, my method doesn't vectorise the loads even for int, tried checking the vectorisation report and the assembly
<HHN93>
so do we break our alligment with std?
<HHN93>
`my method doesn't vectorise the loads even for int, tried checking the vectorisation report and the assembly`
<HHN93>
atleast with clang 14
<hkaiser>
the std wouldn't attempt to vectorize non-vectorizable types, even for unseq
<HHN93>
yeah, but in our case the compilation itself fails. Which does seem less desirable
<hkaiser>
it fail only if you unconditionally try to vectorize
<hkaiser>
vectorizing code should be selected only for vectorizable types
<HHN93>
oh ok
<HHN93>
fine,
<HHN93>
also can I trust compiler vectorisation reports?
<hkaiser>
probably, looking at the assembly is more informative, however
<HHN93>
I am running a profiler instead to screening through the whole assembly
<HHN93>
and looking at hotspots on the profiler
<gnikunj[m]>
HHN93: compiler vectorization reports are very accurate. The reports are generated as the compiler tries to vectorize loops.
<gnikunj[m]>
IIRC the compiler fails to vectorize in an event of: 1. conditional branching within the loop; 2. Anti-dependency of a loop variable found outside the basic block; 3. Non trivial data layout making it difficult for the compiler to interpret and implement
<HHN93>
yes, that's why I am breaking generate into 2 loops, generating part and then loading into the vector
<HHN93>
loading should ideally be vectorised, but doesn't seem to be
<HHN93>
-Rpass-analysis=loop-vectorize
<HHN93>
tried this compile option, and there is no mention of the loop
<gnikunj[m]>
Point me to the code. Could be something trivial.
<gnikunj[m]>
and why would L19 be vectorized again?
<HHN93>
looking at assembly, there are no vector registers being used (no xmm, ymm) so i assume there is no vectorization happening
<HHN93>
isn't it an element being moved into the vector?
<HHN93>
it should correspond to a load instruction right?
<gnikunj[m]>
sure - 4 loads and not a single simd load
<HHN93>
ok how do you suggest I make it a simd load?
<HHN93>
I thought that's what HPX_VECTORISE did
<HHN93>
ok I think I had an wrong understanding of how vector registers worked
<HHN93>
let me look into it again
<gnikunj[m]>
It comes under 3. of what I said above - the compiler doesn't know if it can do write all 4 directly using first. Why not use copy_from from std::simd or srinivasyadav18 's implementation?