Re: Dealing with higher order operations coupled with primitives
 

On 6/22/2012 5:00 AM, rossum wrote:

> By all means eleminate boxing if you boxing program runs too slowly,
> but until you have written it, tested it and profiled it to show that
> boxing is the problem then you have no reason to avoid boxing.


Just to interject gently here: It seems to me that the OP has stated
that he did experiment with Objects, and confirmed that the overhead was
too high for his purposes.

Re: Dealing with higher order operations coupled with primitives
 

markspace wrote:
>rossum wrote:
>> By all means eleminate boxing if you boxing program runs too slowly,
>> but until you have written it, tested it and profiled it to show that
>> boxing is the problem then you have no reason to avoid boxing.
>
> Just to interject gently here: It seems to me that the OP has stated
> that he did experiment with Objects, and confirmed that the overhead was
> too high for his purposes.

Just to reply bluntly here, but what the OP stated was,
"since I do not want to incur the boxing overhead of Objects",
not that he had measured that overhead or even knew that it was real.

He's confirmed nothing insofar as he's told us.

--
Lew

Re: Dealing with higher order operations coupled with primitives
 

On 6/22/2012 12:45 PM, Lew wrote:
> markspace wrote:
>> rossum wrote:
>>> By all means eleminate boxing if you boxing program runs too
>>> slowly, but until you have written it, tested it and profiled it
>>> to show that boxing is the problem then you have no reason to
>>> avoid boxing.
>>
>> Just to interject gently here: It seems to me that the OP has
>> stated that he did experiment with Objects, and confirmed that the
>> overhead was too high for his purposes.
>
> Just to reply bluntly here, but what the OP stated was, "since I do
> not want to incur the boxing overhead of Objects", not that he had
> measured that overhead or even knew that it was real.
>
> He's confirmed nothing insofar as he's told us.
>


About 1/3 of the way through his post he says:

"Here if there are many parts to arg, I may fun.apply(tmp, arg.get(...))
many many times. In my benchmarks, this seems to be much slower than
what I could get without this abstraction. I am trying to reduce this
overhead as much as possible."

That and everything below it seems to imply actual prototyping,
especially later on where me mentions comparing benchmarks between Java
and C.

OTOH his code is kind of sloppy. For example, his implementation of his
recursive sum overflows Java's int and gives the wrong answer. This
might be a reason why his Java is fast, if other languages are dealing
with infinite precision and promoting ints to a higher precision format.