About my short term goals

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

About my short term goals

Nicolas Cellier
 
Hi,
I feel like I did not explain my short term goals.
This lack of explanation may let my recent commit be viewed as gratuitous breakage.

They are not. What I'm after is:

- reduce the number of C Undefined Behaviours that we depend upon
  my own vm brand can be compiled without the -fwrapv workaround, it's doable.
- eliminate ever more C compiler warnings
  Eliot did really a great job these last two years
  maybe we're not yet ready to compile with -Wall -Werror, but we are approaching
- simplify the slang source when possible
- connect the 32 bits limbs trick for accelerating large integer arithmetic

About this last point, I'm now thinking about a different strategy for the hypothetical BIG-ENDIAN machines: swap bytes while fetching/storing limbs instead of using native order tricks.
It's more robust and not really expensive nowadays.
This way, the code that would fetch largeInteger bytes would still work unchanged.
Also no need to hack ImageSegment and image version number.

I'm thinking of using the approach of this kind of references:
http://www.boost.org/doc/libs/1_60_0/boost/endian/detail/intrinsic.hpp
https://blogs.oracle.com/DanX/entry/optimizing_byte_swapping_for_fun
http://hardwarebug.org/2010/01/14/beware-the-builtins
http://stackoverflow.com/questions/105252/how-do-i-convert-between-big-endian-and-little-endian-values-in-c

So, once again, apologies for the hiccups, there might be a few more, even if I'll try my best to take it seriously and carefully, it's currently too expensive to guaranty non regression. With a single dev branch, it's more than expensive, it's impossible.

Until we come with a more modern architecture, please don't consider that each and every monticello commit is OK to take as is.
Eliot has short release cycles, and he does generally commit on .SVN repository when there is a MC version ready with enough added value and enough stability. That's not at each and every MC version.

It's far from perfect, and maybe won't scale once a few more people add noise.
But in the interim, my advice is to synch the production on .SVN release and associated MC version, not on MC.
Running tests for the two are different jobs, that's a way to mitigate the fact that we have a single branch.

cheers

Reply | Threaded
Open this post in threaded view
|

Re: About my short term goals

stephane ducasse-2
 

On 19 Mar 2016, at 16:57, Nicolas Cellier <[hidden email]> wrote:

Hi,
I feel like I did not explain my short term goals.
This lack of explanation may let my recent commit be viewed as gratuitous breakage.

They are not. What I'm after is:

- reduce the number of C Undefined Behaviours that we depend upon
  my own vm brand can be compiled without the -fwrapv workaround, it's doable.

Excellent I love that

- eliminate ever more C compiler warnings
  Eliot did really a great job these last two years
  maybe we're not yet ready to compile with -Wall -Werror, but we are approaching

Excellent that too. 
I think that it will improve quality. 

- simplify the slang source when possible

Would be nice. 
- connect the 32 bits limbs trick for accelerating large integer arithmetic

About this last point, I'm now thinking about a different strategy for the hypothetical BIG-ENDIAN machines: swap bytes while fetching/storing limbs instead of using native order tricks.
It's more robust and not really expensive nowadays.
This way, the code that would fetch largeInteger bytes would still work unchanged.
Also no need to hack ImageSegment and image version number.

I'm thinking of using the approach of this kind of references:
http://www.boost.org/doc/libs/1_60_0/boost/endian/detail/intrinsic.hpp
https://blogs.oracle.com/DanX/entry/optimizing_byte_swapping_for_fun
http://hardwarebug.org/2010/01/14/beware-the-builtins
http://stackoverflow.com/questions/105252/how-do-i-convert-between-big-endian-and-little-endian-values-in-c

So, once again, apologies for the hiccups,

there is no problems about hiccups this is life.
there are problems not taming then with computer power and not engineer time. 

there might be a few more, even if I'll try my best to take it seriously and carefully, it's currently too expensive to guaranty non regression. With a single dev branch, it's more than expensive, it's impossible.

Until we come with a more modern architecture, please don't consider that each and every monticello commit is OK to take as is.
Eliot has short release cycles, and he does generally commit on .SVN repository when there is a MC version ready with enough added value and enough stability. That's not at each and every MC version.

It's far from perfect, and maybe won't scale once a few more people add noise.
But in the interim, my advice is to synch the production on .SVN release and associated MC version, not on MC.
Running tests for the two are different jobs, that's a way to mitigate the fact that we have a single branch.

cheers


Reply | Threaded
Open this post in threaded view
|

Re: About my short term goals

David T. Lewis
In reply to this post by Nicolas Cellier
 
Nicolas,

Thank you very much for this explanation. You have been doing really
valuable work with numeric methods, and it is much appreciated.

In any bleeding edge development stream, occasional hiccups are to be
expected, expecially given the nature of the work that you are doing.
The fact that it happens so rarely is an indication of the quality of
your efforts.

Dave

On Sat, Mar 19, 2016 at 04:57:41PM +0100, Nicolas Cellier wrote:

>  
> Hi,
> I feel like I did not explain my short term goals.
> This lack of explanation may let my recent commit be viewed as gratuitous
> breakage.
>
> They are not. What I'm after is:
>
> - reduce the number of C Undefined Behaviours that we depend upon
>   my own vm brand can be compiled without the -fwrapv workaround, it's
> doable.
> - eliminate ever more C compiler warnings
>   Eliot did really a great job these last two years
>   maybe we're not yet ready to compile with -Wall -Werror, but we are
> approaching
> - simplify the slang source when possible
> - connect the 32 bits limbs trick for accelerating large integer arithmetic
>
> About this last point, I'm now thinking about a different strategy for the
> hypothetical BIG-ENDIAN machines: swap bytes while fetching/storing limbs
> instead of using native order tricks.
> It's more robust and not really expensive nowadays.
> This way, the code that would fetch largeInteger bytes would still work
> unchanged.
> Also no need to hack ImageSegment and image version number.
>
> I'm thinking of using the approach of this kind of references:
> http://www.boost.org/doc/libs/1_60_0/boost/endian/detail/intrinsic.hpp
> https://blogs.oracle.com/DanX/entry/optimizing_byte_swapping_for_fun
> http://hardwarebug.org/2010/01/14/beware-the-builtins
> http://stackoverflow.com/questions/105252/how-do-i-convert-between-big-endian-and-little-endian-values-in-c
>
> So, once again, apologies for the hiccups, there might be a few more, even
> if I'll try my best to take it seriously and carefully, it's currently too
> expensive to guaranty non regression. With a single dev branch, it's more
> than expensive, it's impossible.
>
> Until we come with a more modern architecture, please don't consider that
> each and every monticello commit is OK to take as is.
> Eliot has short release cycles, and he does generally commit on .SVN
> repository when there is a MC version ready with enough added value and
> enough stability. That's not at each and every MC version.
>
> It's far from perfect, and maybe won't scale once a few more people add
> noise.
> But in the interim, my advice is to synch the production on .SVN release
> and associated MC version, not on MC.
> Running tests for the two are different jobs, that's a way to mitigate the
> fact that we have a single branch.
>
> cheers