Number Array to Boolean Array across multiple CPU Cores

[Branson]

Is there a way to detect how many cores are on a computer, and pragmatically split up the code to execute evenly on the CPU cores?  Here is my attempt at 4 cores, but I can't tell if I'm making the code faster or not, because I don't have a 4 core comptuer.  Let me know what you guys think. 

Thanks, Branson

[altenbach]

A couple of things strike me odd and I don't think you'll get any real benefit out of all this. You are doing a lot of memory reallocations and data shuffling for little benefit.

• If performance is not an issue, it does not really matter how many cores are used. Keep the code simple and clean for better readability and maintenenance.
• If performance is critical, then you should stay far away from any boolean arrrays. A boolean array uses 8x more memory for the same information. Why do you need a boolean array at all? Most likely whatever you need to do can be done orders of magnitude faster by bitwise operation on integers.

Can you tell us exactly what you want to do with all this? Do you have performance issues?

You should also get rid of the orange wires because you are only dealing with integers. Your rounded up division could e.g. be done as follows.

Message Edited by altenbach on 05-05-2009 07:23 AM

[GerdW]

Hi Branson,

in the presentations for LV days you will find a vi for checking the number of cpu cores... (in the multicore presentation -> common -> "get number of cpus.vi" )

Message Edited by GerdW on 05-05-2009 04:50 PM

[Branson]

I removed the quad core part to simplify better what I'm doing.  I am taking a U32 Array and compressing it based on the MSB, then repacking back into another U32 Array.  I hope I'm explaining this in an understandable way.  Try looking at the code if you want to see what I'm trying to say.  Thanks for the advice for rounding with all blue wires.

Currently the process takes between 20ms to 60ms per Array I put into it.  The Arrays vary in size from 1 to 100k elements at most for now. Yes I agree that the conversion to boolean is the place that is taking the most time to comptue.  I would like to make it more streamlined and as fast as possible.

Thanks

-Branson

PS how do you make the Image appear in the message?

[altenbach]

Yes, you don't need anything green. I'm sure that can be done well in sub-ms times. 😮

For some ideas, you might want to look at the results of the old bit twiddling challenge. 😄

[nathand]

---

Branson wrote:

PS how do you make the Image appear in the message?

---

Write and submit the message with the image as an attachment.  Go to the message you just posted and copy the location of the link to the image.  Under the Options link in the top right corner of your message, choose Edit.  Use the "Insert/edit image" button in the message editor to insert your image, using the link location you just copied.  Submit the edited message and your image will appear in it.  This is why any post with an image (unless the image is hosted elsewhere) shows up as having been edited.

[smercurio_fc]

---

Branson wrote:

I removed the quad core part to simplify better what I'm doing.  I am taking a U32 Array and compressing it based on the MSB, then repacking back into another U32 Array.  I hope I'm explaining this in an understandable way.  Try looking at the code if you want to see what I'm trying to say. 

---

I looked at the code and saw what it was doing but I still don't understand why. It's also not clear to me how you're supposed to be able to "uncompress". In other words, given "Array Out", how do you get back to "Array In" since you do not know where the array was trimmed in the first place. 

[altenbach]

---

smercurio_fc wrote:

I looked at the code and saw what it was doing but I still don't understand why. It's also not clear to me how you're supposed to be able to "uncompress". In other words, given "Array Out", how do you get back to "Array In" since you do not know where the array was trimmed in the first place. 

---

Basically it seems to strip the unused high-order bits and then pack only the significant bits into the output. Yes, I agree the output need information about the number of significant bits, e.g. as a first array element else things don't translate back. 😉

[Branson]

Sorry I didn't show that the trimmed bit is also outputted and appended to the beginning of the array.  Here is the decompress.

The reason why I'm doing this is to save this information inside an image I capture using the IMAQ Write Custom vi's.  I need the data to be as small as possible as I have filled up all my free space on all my harddrives. lol

 

Message Edited by Branson on 05-06-2009 03:50 PM

Message Edited by Branson on 05-06-2009 03:51 PM

[smercurio_fc]

---

@altenbach wrote:

Basically it seems to strip the unused high-order bits and then pack only the significant bits into the output.

---

Yes, I was able to figure out that much but I just couldn't figure out why. In other words, what's the objective here? Is this for some transmission protocol? File compression? CPU testing? Fun? 

I was just curious. 

UPDATE:  Saw the new post indicating why. In this case, I think the easier solution is to get a bigger hard drive!

Message Edited by smercurio_fc on 05-06-2009 02:56 PM