Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #15504 > unrolled thread

Dealing with higher order operations coupled with primitives

Back to article view | Back to comp.lang.java.programmer

Contents

  Dealing with higher order operations coupled with primitives "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-21 22:08 -0500
    Re: Dealing with higher order operations coupled with primitives Gina Engli <gengli239777@gmail.com> - 2012-06-21 23:17 -0400
      Re: Dealing with higher order operations coupled with primitives "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-22 15:13 -0500
    Re: Dealing with higher order operations coupled with primitives markspace <-@.> - 2012-06-21 21:32 -0700
      Re: Dealing with higher order operations coupled with primitives Gina Engli <gengli239777@gmail.com> - 2012-06-22 02:31 -0400
        Re: Dealing with higher order operations coupled with primitives Fred Greer <fggreer@nospam.invalid> - 2012-06-22 06:36 +0000
          Re: Dealing with higher order operations coupled with primitives Gina Engli <gengli239777@gmail.com> - 2012-06-22 02:43 -0400
            Re: Dealing with higher order operations coupled with primitives Lew <lewbloch@gmail.com> - 2012-06-22 12:45 -0700
              Re: Dealing with higher order operations coupled with primitives Sixteen of Seventeen <sseventeen@gmail.com> - 2012-06-22 18:24 -0400
                Re: Dealing with higher order operations coupled with primitives Lew <noone@lewscanon.com> - 2012-06-22 19:59 -0700
                  Re: Dealing with higher order operations coupled with primitives Sixteen of Seventeen <sseventeen@gmail.com> - 2012-06-22 23:16 -0400
                    Re: Dealing with higher order operations coupled with primitives Lew <noone@lewscanon.com> - 2012-06-22 22:13 -0700
                      Re: Dealing with higher order operations coupled with primitives Borg Queen <queen@unimatrix.zero> - 2012-06-23 01:18 -0400
                        Re: Dealing with higher order operations coupled with primitives Lew <noone@lewscanon.com> - 2012-06-23 07:59 -0700
                          Re: Dealing with higher order operations coupled with primitives Borg Queen <queen@unimatrix.zero> - 2012-06-23 12:12 -0400
      Re: Dealing with higher order operations coupled with primitives "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-22 15:28 -0500
        Re: Dealing with higher order operations coupled with primitives Gina Engli <gengli239777@gmail.com> - 2012-06-22 18:25 -0400
    Re: Dealing with higher order operations coupled with primitives Roedy Green <see_website@mindprod.com.invalid> - 2012-06-22 00:33 -0700
      Re: Dealing with higher order operations coupled with primitives "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-22 15:31 -0500
    Re: Dealing with higher order operations coupled with primitives rossum <rossum48@coldmail.com> - 2012-06-22 13:00 +0100
      Re: Dealing with higher order operations coupled with primitives markspace <-@.> - 2012-06-22 07:45 -0700
        Re: Dealing with higher order operations coupled with primitives Lew <lewbloch@gmail.com> - 2012-06-22 12:45 -0700
          Re: Dealing with higher order operations coupled with primitives markspace <-@.> - 2012-06-22 13:34 -0700
            Re: Dealing with higher order operations coupled with primitives Lew <noone@lewscanon.com> - 2012-06-22 20:04 -0700
      Re: Dealing with higher order operations coupled with primitives "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-22 15:22 -0500
        Re: Dealing with higher order operations coupled with primitives Lew <lewbloch@gmail.com> - 2012-06-22 14:27 -0700
    Re: Dealing with higher order operations coupled with primitives "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-06-22 15:14 -0500

Page 2 of 2 — ← Prev page 1 [2]

#15516

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.

[toc] | [prev] | [next] | [standalone]

#15522

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

[toc] | [prev] | [next] | [standalone]

#15530

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.

[toc] | [prev] | [next] | [standalone]

#15537

On 06/22/2012 01:34 PM, markspace wrote:
> 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."

I read "this abstraction" as applying to his funky 'fun.apply()' idiom, not to 
autoboxing. Are you sure that referred to autoboxing?

Even if it did, and the grammar of his post suggests otherwise, there aren't 
any numbers there at all, and no clue if idiomatic Java would permit the 
optimizer to eliminate such overhead if it does exist.

Nothing is confirmed there, no matter how you slice it.

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

"Seems" is weasel wording for "you interpreted it that way". There's no 
seeming without an observer. I didn't interpret it to have anything to do with 
autoboxing. You did. OP - would you please tell us if you have measured the 
effect of autoboxing?

I'm not going to argue with someone who has an equal chance with me of 
misunderstanding your vague and unclear, unsubstantiated and ununderstandable 
claims.

> 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.

SHOW US THE CODE, OP!

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#15527

On Fri, 22 Jun 2012 13:00:02 +0100, rossum wrote:

> On Thu, 21 Jun 2012 22:08:37 -0500, "Aaron W. Hsu" <arcfide@sacrideo.us>
> 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.

I will be posting a more complete set of examples which demonstrates the 
issues I have later today, once I have trimmed them all down to proper 
size, but I should mention that I am not trying to use Java as an end-user 
here, but as the means to defining the core runtime data structures and
language primitives for use as the core vocabulary for a compiler that 
I am writing, which compiles another language to JVM.

Thank you for pointing out that boxing might not matter, though in all 
my experiences, it does.  I'll post actual code soon, though, to see whether 
this is just ignorance on my part.

-- 
Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

[toc] | [prev] | [next] | [standalone]

#15531

Aaron W. Hsu wrote: 
> Thank you for pointing out that boxing might not matter, though in all 
> my experiences, it does.  I'll post actual code soon, though, to see whether 
> this is just ignorance on my part.

A number of things affect how much autoboxing affects performance.

Let the code spin up 10000 times with the JVM in "-server" mode and watch your 
performance issues melt away.

I am being a little fey with that remark, but you have to let the optimizer 
do its thing before you judge.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15526

On Fri, 22 Jun 2012 03:43:16 +0000, Stefan Ram wrote:

> Usually, one will not get best results when trying to impose
>   the style and coding patterns of one programming language onto
>   another.

This is to implement a runtime for a language I am designing 
which will compile either to the JVM or some JVM language, 
most likely.

-- 
Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web