Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MorleyDev]

Maybe use the demo of dotTrace to figure out where the CPU time is being spent?

[GalenEvil]

Just a few things that I noticed that may or may not have a significant impact:

The Vector2 for the start of the line isn't changing, and so can be assigned as soon as S is assigned. So you'd have

Code: [Select]

Vector2 lineStartPoint = new Vector2(S.ProjectedPosition.x, S.ProjectedPosition.y);and change

Code: [Select]

ls = LineIntersect(new Line(new Vector2(S.ProjectedPosition.x, S.ProjectedPosition.y), new Vector2(E.ProjectedPosition.x, E.ProjectedPosition.y)), Edges[i]);to

Code: [Select]

ls = LineIntersect(new Line(lineStartPoint, new Vector2(E.ProjectedPosition.x, E.ProjectedPosition.y)), Edges[i]);in both of the points it is called.

Secondly, there is potential for recalculating whether S is inside for every E, which doesn't need to be done since S doesn't change in the middle of the foreach(E) loop. It could be calculated just under S's assignment and stored in a boolean.

Code: [Select]

bool SInside = Inside(i, S.ProjectedPosition);and replace

Code: [Select]

}else if (Inside(i, S.ProjectedPosition)){ with

Code: [Select]

}else if (SInside){
Not sure if those will result in any noticeable changes to the speed, but they could help. You also have some variables that are used a lot within the loop that get destroyed during scope changes. Those could be declared outside of the loop and altered within it to keep it from allocating and deallocating the variables on scope change.

Example of how you could rearrange things:

Code: [Select]

// variable assignments
Vertex[] Outputs = new Vertex[7];
int OutputAdd = 0, numOutputs;
List<Vertex> outputs, inputList;
Vertex S;
Vector2 ls, SLineStart;
bool SInside;

foreach(IEnumerable<int> triangle in Triangles.Batch(3)){
outputs = triangle.Select(x => vs[x]).ToList();
numOutputs = outputs.Count;
//List<Vertex> outputs = new List<Vertex>(triangle.Select(x => vs[x]));
for (int i = 0; i < numOutputs; ++i){
//for (int i = 0; i < outputs.Count; i++){
Outputs[i] = outputs[i];
}
OutputAdd = numOutputs;
//OutputAdd = outputs.Count;
for(int i = 0; i < 4; i++){ // for each edge
intputList = Outputs.Take(OutputAdd).ToList();
///List<Vertex> inputList = new List<Vertex>(Outputs.Take(OutputAdd));
OutputAdd = 0;
if (inputList.Any()){
S = inputList.Last();
SInside = Inside(i, S.ProjectedPosition);
SLineStart = new Vector2(S.ProjectedPosition.x, S.ProjectedPosition.y);

//Vertex S = inputList.Last();
foreach (Vertex E in inputList){
if (Inside(i, E.ProjectedPosition)){
if (!SInside){
//if (!Inside(i, S.ProjectedPosition)){
//Vector2 ls = Vector2.zero;
ls = LineIntersect(new Line(SLineStart, new Vector2(E.ProjectedPosition.x, E.ProjectedPosition.y)), Edges[i]);
//ls = LineIntersect(new Line(new Vector2(S.ProjectedPosition.x, S.ProjectedPosition.y), new Vector2(E.ProjectedPosition.x, E.ProjectedPosition.y)), Edges[i]);
//outputs.Add(CalculateVertexFrom(S, E, ls));
Outputs[OutputAdd] = CalculateVertexFrom(S, E, ls);
OutputAdd++;
}
//outputs.Add(E);
Outputs[OutputAdd] = E;
OutputAdd++;
}else if (SInside){
//} else if (Inside(i, S.ProjectedPosition)){
//Vector2 ls = Vector2.zero;
ls = LineIntersect(new Line(SLineStart, new Vector2(E.ProjectedPosition.x, E.ProjectedPosition.y)), Edges[i]);
//ls = LineIntersect(new Line(new Vector2(S.ProjectedPosition.x, S.ProjectedPosition.y), new Vector2(E.ProjectedPosition.x, E.ProjectedPosition.y)), Edges[i]);
//outputs.Add(CalculateVertexFrom(S, E, ls));
Outputs[OutputAdd] = CalculateVertexFrom(S, E, ls);
OutputAdd++;
}
S = E;
}
}
}
}
I'll have to look through it a little more carefully on my next break to see if I can come up with anything else that may be causing slow downs.

[Skyrunner]

How I hate debugging OpenCL T_T
For some reason, changing an argument in a kernel from 'global const int*' to 'global const unsigned int*' causes an access violation to 0xfeefee.
Also, even though func(cl::Buffer* argpointer) and I have a cl::Buffer* grid, I have to pass func(*grid). func(grid) ?causes another access violation.

[Telgin]

I can't remember if this is the case for OpenCL, but doesn't constant memory reside in a different memory region?  Setting the kernel argument to be a constant may cause a buffer somewhere to be accessed wrong.

I hated working with OpenCL too.  If you're running it on the Intel or AMD driver you can build it to run on the CPU and debug it like any old C program though.  That helps, but naturally running it on a GPU changes things and you can get crashes in each mode that don't happen in the other.

[alexandertnt]

Thanks for the reply.

Unfortunetely S does change in the foreach(E) loop (the sneaky little "S = E" bit near the end). I put the modifications anyway in the foreach(E) loop, along with declaring the Vector2 ls outside of the loop and it diddnt make any noticible difference in speed (which would make sense now that I think about it, as "Inside(i, S.ProjectedPosition)" and "new Vector2(S.ProjectedPosition.x, S.ProjectedPosition.y)" only happen at most once for each iteration of the foreach(E) loop).

[GalenEvil]

Thanks for the reply.

Unfortunetely S does change in the foreach(E) loop (the sneaky little "S = E" bit near the end). I put the modifications anyway in the foreach(E) loop, along with declaring the Vector2 ls outside of the loop and it diddnt make any noticible difference in speed (which would make sense now that I think about it, as "Inside(i, S.ProjectedPosition)" and "new Vector2(S.ProjectedPosition.x, S.ProjectedPosition.y)" only happen at most once for each iteration of the foreach(E) loop).

Oh carp you are right. I had forgotten about that "S = E" bit >.<

[freeformschooler]

wrong thread damit

[Skyrunner]

Randomly found this:

http://matt.might.net/articles/what-cs-majors-should-know/

Do you people agree with the long, pretty specific list of things? o_O Just wondering, as I have little experience relative to many people here.

[alexandertnt]

Assembly

I dont know how necessary it would be to learn Assembly. It seems like the thing you may need in some obscure situation, but generally wont. (Horay for high-level languages).

I dont have much experience in the actual businessy part of computer science though, so I could be completely wrong.

[Siquo]

Randomly found this:

http://matt.might.net/articles/what-cs-majors-should-know/

Do you people agree with the long, pretty specific list of things? o_O Just wondering, as I have little experience relative to many people here.

Well I'm not a computer scientist, but if you want a good IT job:

Yep. If you want to get a nice job in the field, learn (almost) ALL of those things, but you can safely skip Formal methods, Graphics and simulation, Robotics, AI and Machine Learning (although Machine learning is actually useful in a lot of fields) unless your job is in one of those fields). If you do know all of em, you're what I consider a good (That is: better than me) IT-person.

I still have quite a few to do from that list, but lack the time/motivation (as in: I already have a job) to do them
It's actually quite a good list.

I dont know how necessary it would be to learn Assembly. It seems like the thing you may need in some obscure situation, but generally wont. (Horay for high-level languages).

I never typed a letter of assembly in my life. I do know how it works and studied/can read programs written in it, which helps a lot in sometimes understanding why and how higher level languages (that is: all other languages) do the things they do. It's background knowledge you won't use directly, but greatly increases your understanding of other stuff. That goes for a lot on that list.
Yes, you can write PHP programs without knowing how a transistor works, but that lack of general knowledge makes you "an IT person" as opposed to "a good IT person".

[alexandertnt]

I know how a transistor works (used to be interested in electronics before discovering programming) but I dont see how this knowledge would help you write better PHP scripts.

Maths is pretty important though, and programmers sometimes seem to be lacking in this particular area.

[Siquo]

I know how a transistor works (used to be interested in electronics before discovering programming) but I dont see how this knowledge would help you write better PHP scripts.

That is what I said.

[alexandertnt]

I know how a transistor works (used to be interested in electronics before discovering programming) but I dont see how this knowledge would help you write better PHP scripts.

That is what I said.

Oh, whoops, I see now. Nevermind then.

[alway]

Assembly

I dont know how necessary it would be to learn Assembly. It seems like the thing you may need in some obscure situation, but generally wont. (Horay for high-level languages).

I dont have much experience in the actual businessy part of computer science though, so I could be completely wrong.

You should learn it because it helps in understanding what is actually being done with the code you write. It gives the foundation upon which the things you take for granted rest; and so allows you to extrapolate what will happen in scenarios you haven't learned about. Things like caching, low level efficiency tweaks, SIMD... in terms of the higher level language, they basically aren't explained phenomena. And what's worse, you can end up with inefficient solutions which, according to the high-level theory, should be the most efficient. A list may be faster than an array in some situation... Until you find out that its advantage is negated by caching issues related to scattered memory addresses. Which is itself an issue that you can fix to some extent by taking that knowledge into account. So yeah, if you're going to be doing any programming more intense than HTML, you should learn how things work on a low level so your code isn't a steaming pile of naively implemented excrement.

At this point, you are probably thinking 'what is he talking about, most of those things are clearly under the OS category!' And of course you would be right. However, without knowing what your code is being compiled down to, or at least having a good idea of what it is probably compiled down to, you're going to have a really hard time seeing that OS level. If the water below you is murky, you won't be able to see the bottom, as it were. And so that assembly knowledge ends up being the glue that holds the high level theory together with the low-level realities of the actual implementation.

[Skyrunner]

Today, I learned that AMD made an MSVS debugger plugin for openCL.

Things are going to be much, much better now. :3