• Lumberg (unregistered) in reply to Anthony

    Anonymous:
    This assumes, of course, that the optimizer is stupid. The optimizer is perfectly free to simply translate both statements as 'i = i+1', since the return value is being discarded. If the return value is not being discarded (x = i++ vs x = ++i), the two code segments don't have the same effect so you can't make this substitution anyway, and in any case the actual code generated will be:
    x = i++  ==> x = i; i = i+1
    x = ++i  ==> i = i+1; x = i

    Naturally, if the compiler doesn't know how the increment operator works, it cannot do this optimization, but that's the fault of how the increment operator was written, not a specific issue of ++i vs i++.

    So I guess you expect the compiler to somehow predict whether each and every result it puts on the stack (e.g. the value of "i" before incrementation) gets used. And if it doesn't get used, then there's no need to worry about evaluating said result correctly, right?

    I realize that a lot of compilers do exactly that, but I am less than enthusiastic about it. It seems like a great deal more work for the compiler (and its designers) to "predict the future" than it would be for you to simply use "++i" instead of "i++" if that's what you mean.

    Besides, in a real language like C, your code is not executing in a "sandbox." You can't assume that everything that might be affected by your process' memory is right there in the source code being compiled.

  • Aunt Teller (unregistered) in reply to dubwai
    dubwai:
    kipthegreat:

    Assuming this is Java (which it looks like to me), it is impossible for that to happen.  displayProductInfo will be given a copy of the pointer to prodnums[idx], not the same pointer that the loop uses.  The method would have no knowledge of the array its parameter comes from.  Also, arrays are not dynamic so you can't really remove anything from any array (other than setting it to null.. which, again, displayProductInfo is unable to do).

    This isn't quite right.  The thing about the reference (pointer) being a copy is correct, but there's only one array being pointed to.  It doesn't copy the array, just the pointer.  This method could change array elements.  It can't resize the array, though because the length is not mutable, that part is correct.



    The code snippet does not define the array in question, therefore we and the compiler cannot know whether it is a local or instance variable. If it is an instance variable, the compiler must prepare for another thread changing the array completely (ie, replacing the array with a different length array).

    So, if the array is shared, then the bounds check must be done every time the array is accessed. This kind of try-catch-kludgery will be faster in that case. But if the array is local, then the compiler can move the bounds check outside the loop and then a regular for-loop will be faster.

    How much you ask?

    try-catch with shared array: 115ms
    for with shared array: 120ms
    try-catch with local array: 115ms
    for with local array: 95ms

    This with 10000000 (10 million) integers. Insignificant. No-one should ever use the try-catch-kludgery.
  • Aunt Teller (unregistered) in reply to dubwai
    dubwai:

    hank miller:
    However if displayProductInfo may alter the number of elements in prodnums, than this is the right solution to the problem.

    As already pointed out, that is impossible



    That is completely incorrect. You may assume so but since we do not know where the array is defined, that assumption is not valid. If the array is an instance variable there is nothing that prevents the displayProductInfo or possibly some other thread from accessing the array variable from elsewhere and changing it into a different length array.

    In this case, as I wrote above, the try-catch-kludge would be faster by a completely insignificant margin.

    This pattern does come from Java performance tuning handbooks. I can't believe how many performance tuning books still repeat crap like this. This belongs to the same category as "object creation is slow so objects should be pooled" and "synchronization is slow".
  • heh? (unregistered) in reply to XoK

    int i = x;

    for (; --i != 0;) { statements; }

    I think checking if one number is bigger than second is slower than checking if number is equal to 0.

  • (cs) in reply to heh?
    Anonymous:
    int i = x;

    for (; --i != 0;) { statements; }

    I think checking if one number is bigger than second is slower than checking if number is equal to 0.



    Correct.  Java specificies separate opcodes for comparison with zero, so you save the cost of loading a local onto the stack.  Not a big savings, however.

  • Yegor Parusymov (unregistered)

    I would notice that this way to go through an array is most effective, since check of bounds is included already violate you it or not, but no any additional check applied

    thus i would not lough at the code - it's just cool

  • Alejandro (unregistered)

    The iterator contract in Python relies on that pattern. http://en.wikipedia.org/wiki/Iterator#Python

  • James Moore (unregistered) in reply to A Wizard A True Star

    No, it's not, because you can't delete the reference of a passed object.

  • Petr (unregistered) in reply to emptyset
    emptyset:
    "average intelligence, while good, still implies that half of those surveyed are below its threshold.

    No, this is how a median can be interpreted. Average is statistical function constructed different way, so with different possible interpretation.

    @see http://en.wikipedia.org/wiki/Median @see http://en.wikipedia.org/wiki/Median

Leave a comment on “Array of Hope”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article