Re: Win32 build - Drag/Drop file name problem

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Win32 build - Drag/Drop file name problem

stonysmith
> From: Brad Pitcher [hidden email]
>
> Subject: Re: [OpenSCAD] Win32 build - Drag/Drop file name problem
> I packaged up a windows build with the fix. I didn't get a chance to test that bug yet...
> https://github.com/downloads/brad/openscad/openscad-2011.09.27.win32.zip

The fix works fine for me. Thanks!
I don't have a compiler environment handy, so I appreciate you doing these builds.
I can at least always offer to help test them.

FYI.. I too get the Assertion error in Example 21.
Reply | Threaded
Open this post in threaded view
|

Re: Win32 build - Drag/Drop file name problem

Brad Pitcher
I found the problem causing the assertion error and filed a pull request:
https://github.com/openscad/openscad/pull/27

On Tue, Sep 27, 2011 at 9:21 PM, <[hidden email]> wrote:
> From: Brad Pitcher [hidden email]
>
> Subject: Re: [OpenSCAD] Win32 build - Drag/Drop file name problem
> I packaged up a windows build with the fix. I didn't get a chance to test that bug yet...
> https://github.com/downloads/brad/openscad/openscad-2011.09.27.win32.zip

The fix works fine for me. Thanks!
I don't have a compiler environment handy, so I appreciate you doing these builds.
I can at least always offer to help test them.

FYI.. I too get the Assertion error in Example 21.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|

Re: Win32 build - Drag/Drop file name problem

kintel
Administrator
On Sep 28, 2011, at 07:56 AM, Brad Pitcher wrote:

> I found the problem causing the assertion error and filed a pull request:
> https://github.com/openscad/openscad/pull/27
>
Merged.

One thing though: According to the Eigen docs, you need to include <Eigen/StdVector> before using the Eigen allocator.
Eigen/StdVector will modify std::vector to support aligned operations to work correctly with Eigen.
Unfortunately, due to dxfdata.h being included in multiple places, this eventually causes a conflict with boost, which I'm not sure it's worth to hunt down and fix.

Perhaps it will work as it is but I don't know.
Any ideas?

 -Marius


Reply | Threaded
Open this post in threaded view
|

Passing arrays around

William Adams
In reply to this post by Brad Pitcher
Recently, I've been doing this work in OpenScad to do height mapping: http://www.thingiverse.com/thing:11981
 
Although the basic technique worked initially, it was as slow as molasses in winter.
 
After pondering it much, I found that the bigger my height maps, the slower things became.  that didn't make much sense to me, until I realized that these things must be copied whenever passed to a function.  So, I might have had something like this:
 
function getpixel(array, width, height, x, y) = array[y*width+x];
 
I'm speculationg, but I think this function call will copy my array?
 
So, from this assumption, I just 'unrolled' the function calls, and did this directly:

pixel = array[y*width+x];
 
After I did this, things became much faster, orders of magnitude faster!
 
Question:  Do variables get copied into functions?  If that's the case, then for my 256x256 array, I am getting 64K copies of the array, just to make one pass through the pixel values?
 
Just speculation.  can someone tell me what's really going on here, and why doing simple array lookups might be so expensive?
 
would using the 'lookup' function make any difference?
 
-- William
Reply | Threaded
Open this post in threaded view
|

Re: Passing arrays around

kintel
Administrator
On Sep 28, 2011, at 22:22 PM, William Adams wrote:

> Question:  Do variables get copied into functions?  If that's the case, then for my 256x256 array, I am getting 64K copies of the array, just to make one pass through the pixel values?

Arguments are passed by value in several places. For your example, see e.g. expr.cc, line 140.
Since all these values are immutable, I see no reason why it should be like this - probably just a quick and dirty implementation. Once you start pushing the boundaries, you stumble across such issues.

> would using the 'lookup' function make any difference?

Perhaps a tiny bit, but glancing at the code, I think you'll still get a bunch of copies.

I'll take a note of this and at some point do some performance testing and optimization.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Passing arrays around

William Adams
Thanks for confirming my suspicions.
 
For now, I can continue to optimize my code around this fact.  If this were changed, there would certainly be a dramatic speedup for a whole class of models.
 
-- William

===============================
- Shaping clay is easier than digging it out of the ground.


http://internationalwilliam.spaces.msn.com/

 
> From: [hidden email]

> Date: Wed, 28 Sep 2011 23:59:50 +0200
> To: [hidden email]
> Subject: Re: [OpenSCAD] Passing arrays around
>
> On Sep 28, 2011, at 22:22 PM, William Adams wrote:
>
> > Question: Do variables get copied into functions? If that's the case, then for my 256x256 array, I am getting 64K copies of the array, just to make one pass through the pixel values?
>
> Arguments are passed by value in several places. For your example, see e.g. expr.cc, line 140.
> Since all these values are immutable, I see no reason why it should be like this - probably just a quick and dirty implementation. Once you start pushing the boundaries, you stumble across such issues.
>
> > would using the 'lookup' function make any difference?
>
> Perhaps a tiny bit, but glancing at the code, I think you'll still get a bunch of copies.
>
> I'll take a note of this and at some point do some performance testing and optimization.
>
> -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
Reply | Threaded
Open this post in threaded view
|

Re: Win32 build - Drag/Drop file name problem

donbright
In reply to this post by kintel
On Wed, Sep 28, 2011 at 5:00 AM, Marius Kintel <[hidden email]> wrote:

> On Sep 28, 2011, at 07:56 AM, Brad Pitcher wrote:
>
>> I found the problem causing the assertion error and filed a pull request:
>> https://github.com/openscad/openscad/pull/27
>>
> Merged.
>
> One thing though: According to the Eigen docs, you need to include <Eigen/StdVector> before using the Eigen allocator.
> Eigen/StdVector will modify std::vector to support aligned operations to work correctly with Eigen.
> Unfortunately, due to dxfdata.h being included in multiple places, this eventually causes a conflict with boost, which I'm not sure it's worth to hunt down and fix.
>
> Perhaps it will work as it is but I don't know.
> Any ideas?
>
>  -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>


i had to completely disable SIMD eigen stuff when i was running the
the tests under linux.

http://eigen.tuxfamily.org/index.php?title=FAQ

-DB

Reply | Threaded
Open this post in threaded view
|

Re: Win32 build - Drag/Drop file name problem

Brad Pitcher

On Thu, Sep 29, 2011 at 4:48 PM, Don Bright <[hidden email]> wrote:
> One thing though: According to the Eigen docs, you need to include <Eigen/StdVector> before using the Eigen allocator.
> Eigen/StdVector will modify std::vector to support aligned operations to work correctly with Eigen.
> Unfortunately, due to dxfdata.h being included in multiple places, this eventually causes a conflict with boost, which I'm not sure it's worth to hunt down and fix.
>
> Perhaps it will work as it is but I don't know.
> Any ideas?

After pulling your latest changes to rebuild win32 I found more assertion errors, only this time the error happens every time you compile anything! Trying to fix it with the same technique, I ran in to that exact issue (conflict with boost).
 

i had to completely disable SIMD eigen stuff when i was running the
the tests under linux.

http://eigen.tuxfamily.org/index.php?title=FAQ


I found that I could just define EIGEN_DONT_ALIGN as Don suggests and now things compile fine in the win32 version. I really don't know enough about these libraries to know if this is the best thing to do. I'm just trying to keep things from blowing up.
My commit is here if you want to try it:
Reply | Threaded
Open this post in threaded view
|

Re: Win32 build - Drag/Drop file name problem

donbright
On Wed, Oct 5, 2011 at 1:51 AM, Brad Pitcher <[hidden email]> wrote:

>
> On Thu, Sep 29, 2011 at 4:48 PM, Don Bright <[hidden email]> wrote:
>>
>> > One thing though: According to the Eigen docs, you need to include
>> > <Eigen/StdVector> before using the Eigen allocator.
>> > Eigen/StdVector will modify std::vector to support aligned operations to
>> > work correctly with Eigen.
>> > Unfortunately, due to dxfdata.h being included in multiple places, this
>> > eventually causes a conflict with boost, which I'm not sure it's worth to
>> > hunt down and fix.
>> >
>> > Perhaps it will work as it is but I don't know.
>> > Any ideas?
>
> After pulling your latest changes to rebuild win32 I found more assertion
> errors, only this time the error happens every time you compile anything!
> Trying to fix it with the same technique, I ran in to that exact issue
> (conflict with boost).
>
>>
>> i had to completely disable SIMD eigen stuff when i was running the
>> the tests under linux.
>>
>> http://eigen.tuxfamily.org/index.php?title=FAQ
>>
>
> I found that I could just define EIGEN_DONT_ALIGN as Don suggests and now
> things compile fine in the win32 version. I really don't know enough about
> these libraries to know if this is the best thing to do. I'm just trying to
> keep things from blowing up.
> My commit is here if you want to try it:
> https://github.com/brad/openscad/commit/0407d287b035e4f3aabf718f290eb31365fad26e
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>
>

AFAIK the Eigen patches are enabling SIMD optimizations for Eigen, (
http://en.wikipedia.org/wiki/SIMD ) which is super awesome, but it
breaks linux/windows compiles. Ideally we could fix the linux/windows
compiles, but until someone can figure that out, in theory, im
assuming it wouldnt hurt anything to just turn the optimizations off
for linux/windows and leave them on for Mac OSX (#ifndef __APPLE__ is
one way to do this???)...

-DB

Reply | Threaded
Open this post in threaded view
|

Re: Win32 build - Drag/Drop file name problem

kintel
Administrator
On Oct 13, 2011, at 01:13 AM, Don Bright wrote:
> [...] assuming it wouldnt hurt anything to just turn the optimizations off
> for linux/windows and leave them on for Mac OSX (#ifndef __APPLE__ is
> one way to do this???)...
>
For now, #ifndef __APPLE__ is good enough. We could also switch the feature itself on/off somewhere (e.g. in the build system).

 -Marius