Re: [Pharo-users] Copy array of float to GPU memory
Hello Ronie. thanks for your response. >Sorry for the late answering. I needed to check some stuffs. no problem. >What kind of error are you getting? a NativeBoost error or incorrect results? Yes I were getting incorrect result. But when I use methods like asCLFloatArray and asFlotArrayFromCL it works. > For completeness, I just added the following new methods. Nice! I am sure that it makes OpenCL package more and more robust and enable friendly programming on GPU. >Unlike passing an IntegerArray or a FloatArray, these are method are creating a new array, looping over all >elements and doing marshalling/unmarshalling. These methods can be very inefficient. Be careful when >using them. Yes thanks a lot Ronie I will be careful to this. @Ben Cormas Look at this link http://forum.world.st/Using-VirtualGPU-td4826028.html - Cheikhou -- View this message in context: http://forum.world.st/Use-array-of-float-to-GPU-memory-tp4831970p4832335.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] storeOn: and literal limits
stepharo wrote > storeOn: is old because it will not handle cycles and other. > So I would simply use Ston. I agree. I ran into two problems right away - internal references are not maintained and it's easy to hit the literal array limit. However, my use case is saving data in Pharo and loading it into Amber, and right now amber-ston is not in a usable state. So, #storeOn: has the unique advantage of saving as Smalltalk source code, and therefore requiring no external library support. So it's useful in simple cases/models where one won't hit those limits - Cheers, Sean -- View this message in context: http://forum.world.st/storeOn-and-literal-limits-tp4832255p4832337.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
