Possible bug with specific application, CModel gives correct results #9
Comments
pf-un
changed the title
|
Just to be clear, |
|
I just found out that if I run So this might be an issue with the ping-pong mechanism, no? |
|
Actually, regarding my last comment, vertex 7 (with value 8) has value 0 in the CModel, when it should be |
|
@HongshiTan, I've uploaded a compressed archive of the xclbin folder here. I also tried: inline prop_t scatterFunc(prop_t srcProp, prop_t edgeProp)
{
return (edgeProp);
}
inline prop_t gatherFunc(prop_t ori, prop_t update)
{
return (update);
}and inline prop_t scatterFunc(prop_t srcProp, prop_t edgeProp)
{
return 0+edgeProp;
}
inline prop_t gatherFunc(prop_t ori, prop_t update)
{
return 0+update;
}The results are the same. |
|
After analyzing your code and the simulation waveform, I think it is the problem of the gatherFunc. Can I confirm with you that you are going to gather the latest update (only one update from the neighbour) of a vertex rather than the sum of all the update from its neighbour? |
|
Exactly. For this test, I'm only interested in the last update/last neighbour to be processed. The expected outcome is to double the property of each vertex, so I set all edge properties to 2 and only propagate the edge properties during the scatter phase. |
|
OK, I changed the gatherFunc as follows (that may not be the final solution): inline prop_t gatherFunc(prop_t ori, prop_t update) The problem comes from the HLS compiler, if ori is not used, the entire function and the logic that relies on this function would be over-simplification by LLVM, which leads to a wrong result (e.g, the update is directly connected to the initial register which is zero) the above code is only applied to the cases that all edge property is the same value. Some details you might be interested in: |
|
I suspected as much but didn't come up with an adequate test for the scenario unfortunately! P.S. I'll probably update #8 soon with an example application (SSSP) showing the discrepancy between vertex properties accessed via |
|
OK, we can provide an API to access the property as you expected |
I believe there may be a bug running this specific application, which is meant to double the property of all vertices (via edge properties).
When executing a superstep, the vertex properties remain unaltered. CModel reports what I would expect to be the correct result, but additionally seems to think the vertex properties are all 0 when they are not (since they are unaltered!).
Note that I set the vertex property to i+1 (so vertex 0 has property 1).
See below the results of a run. After the CModel verification I print the first 10 entries for
MEM_ID_PUSHIN_PROPandMEM_ID_PUSHIN_PROP_MAPPED. Note that some vertices are also missing fromMEM_ID_PUSHIN_PROP_MAPPEDas per #8 but this is not the issue at hand here. None of the vertices have had their property doubled.I am running on a U250 and using SDAccel 2018.3.
The text was updated successfully, but these errors were encountered: