J has copy-by-value semantics. By default, all outputs occupy separate
memory spaces from their corresponding inputs. It's a safety net, which,
given that a lot of J programming is exploration, is very nice to have. Put
another way, this is one of the design decisions that contributes to J's
flexibility, responsiveness, and accommodating ("hey, what if?") feel.
That said, for performance reasons, there are a few places where J
implements copy-by-reference (but only where this implementation detail can
be hidden from the programmer, so that it is indistinguishable from
copy-by-value). One such place is the specific formula you captured in (2).
Another is memory-mapped variables (mapped files). Some others are listed
on in the "Special Code" appendix [1], and in the release notes for various
versions of J [2].
Anyway, I'll pass along some advice I was given as a J newcomer: don't
optimize prematurely.
Don't worry about what "could" be slow in J. Build your application in the
clearest, most straightforward way, and try running it against realistic
data sets. If performance is unacceptable, profile it to find the
bottlenecks. If it isn't obvious how to remove the bottlenecks, or the
obvious workarounds are distasteful, ask here, on the Forums (include some
descriptive prose, working code, example inputs and expected outputs, and
possibly some benchmarks on your machine). Probably someone will suggest a
useful rephrasing (perhaps pointing out a special code phrase you hadn't
noticed before). But if not, at the very worst, you will have raised
awareness of a performance issue in J, which increases the chances it will
be addressed in a future version of the interpreter.
-Dan
[1] Special J phrases recognized and optimized by the interpreter:
http://www.jsoftware.com/help/dictionary/special.htm
[2] J release notes:
http://www.jsoftware.com/help/release/contents.htm
-----Original Message-----
From: programming-boun...@jsoftware.com
[mailto:programming-boun...@jsoftware.com] On Behalf Of Blake McBride
Sent: Friday, January 06, 2012 10:56 AM
To: Programming forum
Subject: Re: [Jprogramming] Indexed assignment must be slow?
So you are saying that J treats the following code 1 with a copy, and
code 2 without a copy?
1. y=:44(2})x
2. x=:44(2})x
What about the following code:
x=:55(3})44(2})x
or:
x=:55(3})(some verb returning a scalar)44(2})x
Thanks for your response. It is very helpful!
Blake McBride
On Fri, Jan 6, 2012 at 9:51 AM, Roger Hui <rogerhui.can...@gmail.com> wrote:
> David Mitchell already answered your question.
>
> x i}y is not indexed assign. (Where's the assign?) y=:x i}y *is
*indexed
> assign and is lean and fast.
>
>
>
> On Fri, Jan 6, 2012 at 7:42 AM, Blake McBride <bl...@mcbride.name> wrote:
>
>> This is a very important point. I'd like to get an official response to
>> this.
>>
>> Modifying an existing array could easily be 1,000 times faster than
>> creating a new, modified array. Naturally, this would depend on the
>> size and type of the array. Seeing how 'fast' it is in human or even
>> computer time means nothing! What is important is the relative time
>> between performing a real indexed update to a copy operation. Even a
>> small difference multiplied over a lot of operations can become
>> unbelievable significant. And, we are not talking about a small
>> difference!
>>
>> Imagine an application specific need to maintain a very large array
>> and make a lot of changes to individual elements. A program that does
>> only this on a large dataset could easily by 1,000 times more time
>> consuming. Imagine a situation where one program takes an hour to
>> complete a calculation and another takes 1,000 hours for the same
>> calculation. This is a significant issue.
>>
>> Blake McBride
>>
>>
>> On Fri, Jan 6, 2012 at 9:11 AM, David Mitchell <davidmitch...@att.net>
>> wrote:
>> > I believe that optimization is happening behind the scenes. See the
>> following
>> > tests actually timing indexed assignment, first without replacing the
>> original
>> > array and then replacing the original array:
>> >
>> > ts=: 6!:2 , 7!:2@]
>> > a=:i.1e6
>> > ts'_777 (2 9 43556)}a'
>> > 0.0238083 8.39078e6
>> > ts'a=:_777 (2 9 43556)}a'
>> > 1.00571e_5 2432
>> >
>> > On 1/6/2012 9:54, Blake McBride wrote:
>> >> Greetings,
>> >>
>> >> Going through J I found that:
>> >>
>> >> x=:1+i.5
>> >> x
>> >> 1 2 3 4 5
>> >> 44 (2}) x
>> >> 1 2 44 4 5
>> >> x
>> >> 1 2 3 4 5
>> >>
>> >> It seems that J doesn't actually make an indexed assignment. It seems
>> >> more like it creates a copy of the array with the specified
>> >> modifications. This is actually quite shocking. Index assignment to
>> >> a very large array in most languages is a very fast and simple
>> >> operation. It is also very memory efficient. Creating a modified
>> >> copy of a very large array has a much, much greater time and space
>> >> cost. Further, multiplying this (unnecessary) cost over a great
>> >> number of operations can drastically (and unnecessarily) affect
>> >> performance negatively.
>> >>
>> >> Am I missing something here?
>> >>
>> >> Thanks.
>>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
