[geran]

I got a method that looks like this:

Code:
public int[][] nextState(int[][] state){
   int[][] n_state = new int[6][7];
   for(int r = 0;r < 6; r++){
      for(int c = 0;c < 7; c++){
         n_state[r][c] = state[r][c];
      }
   }
   //do something with n_state
   return n_state;
}

Is there a faster way to copy state to n_state, something similar to memcpy in c.

memcpy(n_state,state,sizeof(state));

I dont want to set the reference to n_state, e.g n_state = state.

I need a fast method to solve this problem.

If you need it to be fast, don't use java. Seriously.

In C, arrays are allocated contiguously, allowing you to do a straight copy of a block of data. In Java, they are not allocated contiguously.

In Java, you are using the fastest method to do what you want to do.

[Kristoff]

Originally posted by hayesk:
If you need it to be fast, don't use java. Seriously.

Please.

those "Java is slow" comments only show your ignorance.

Java Controlled Inverted Pendulum (seek 22 minutes in to see just how slow.)

For the original poster, did you try System.arraycopy?

[geran]

nice clip... =)

[Kristoff]

It was cool to watch in person.

But seriously...the whole "java is slow" thing is so tired.
Every time I hear someone say it, I know I can turn off my ears because the rest of what they have to say probably lacks credibility as well.

Here's a more formal investigation--although the clip is a pretty good demonstration.

[itistoday]

Like Kristoff said, try System.arraycopy, and maybe state.clone() would work?

[Kristoff]

clone would work, but it only copies the references in the case of arrays of objects (it's a shallow copy)
I think you're ok in the case above, because they are arrays of primitives.

[geran]

I decided to keep the code as it was. System.arraycopy worked, but I need search for the top most empty space ( == 0) in the state. So I didnt see any speed increase. the complexity of thr code isn't so big, O(n^2) but n is just 7. I using this in an a connect4 game whit alpha beta pruning so its called many times, but the speed is quit good even if the ply/depth of the tree is 7.

Anyone have any tip on a good eveluate method for Connect4, that is, how to eveluate how good each state is for the player.

Originally posted by Kristoff:
Please.

those "Java is slow" comments only show your ignorance.

Grow up. If you want to disagree, fine. But if you are going to label me as ignorant, you had better give me a good argument.

IMHO, Java just doesn't contain the control of memory that C or C++ allows. Java is good for a lot of things, but tight memory control isn't one of them. If you think I'm wrong, show me otherwise and I'll gladly admit it.

Java Controlled Inverted Pendulum (seek 22 minutes in to see just how slow.)

I couldn't - it wouldn't load. Was it a C / Java comparison of array copying?

For the original poster, did you try System.arraycopy?

What does System.arraycopy do that makes it faster?

In fact, this page: http://www.javapractices.com/Topic3.cjp shows that the for loop (like the original poster used) can be faster in some cases.

To the original poster, stick with what you have or try arraycopy. If you absolutely need something faster, I'd still recommend another language.

[Kristoff]

Originally posted by hayesk:
Grow up. If you want to disagree, fine. But if you are going to label me as ignorant, you had better give me a good argument.

I did. Not my fault you can't see the clip.
Also, the paper I referenced is as good an argument as any.

IMHO, Java just doesn't contain the control of memory that C or C++ allows. Java is good for a lot of things, but tight memory control isn't one of them. If you think I'm wrong, show me otherwise and I'll gladly admit it.

This was in regard to your comments about java being slow, not about memory control.

What does System.arraycopy do that makes it faster?

It's a native implementation.

In fact, this page: http://www.javapractices.com/Topic3.cjp shows that the for loop (like the original poster used) can be faster in some cases.

Cute. But hardly a scientific analysis.
There are so many issues with that "stopwatch" class that prevent it from being a viable utility for measuring elapsed time.
Compile and run it yourself for a variety of array sizes and iterations and it's all over the place. It only points out how bad the stopwatch is.

To the original poster, stick with what you have or try arraycopy. If you absolutely need something faster, I'd still recommend another language.

How helpful..."use another language"

[K++]

Originally posted by Kristoff:
It's a native implementation.

Actually, its faster only because it forgoes Java's need to double check your work and verify that each and every index is a valid one. Hence you'll get no IndexOutOfBoundException. I shouldn't need to explain why testing that for every index of an n*n array would not be too efficient.

I echo the second poster's sentiments however, Java--

[Arkham_c]

I don't know why people still bash Java. It's not slow anymore. They implemented the Quake 2 engine in java and it's over 90% as fast as the optimized-by-gods version from ID.

Besides, anyone doing real work spends 90% of their application time doing IO to files or databases anyway.

[Kristoff]

Originally posted by K++:
Actually, its faster only because it forgoes Java's need to double check your work and verify that each and every index is a valid one. Hence you'll get no IndexOutOfBoundException. I shouldn't need to explain why testing that for every index of an n*n array would not be too efficient.

Actually, you are wrong.

just google for "ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method)" and you'll see that System.arraycopy throws ArrayIndexOutOfBounds exceptions (albeit only when people do dopey stuff).

Originally posted by Arkham_c:
I don't know why people still bash Java. It's not slow anymore.

Nobody is "bashing" Java. I don't know why people get so defensive. Java is slower than C for memory copying. Period. "slower" is a comparison. It does not mean slow. It means, not as fast. The original poster asked for a way to speed it up, so obviously he wanted to optimize it. In my opinion, the only way is with another language. It is the original poster's decision as to whether it is worth switching languages or not.

They implemented the Quake 2 engine in java and it's over 90% as fast as the optimized-by-gods version from ID.

That's great. But remember, that most of that is in the video card. I don't know how much CPU-bound array copying is done in the game.

Besides, anyone doing real work spends 90% of their application time doing IO to files or databases anyway.

Possibly. As I said, the poster asked for a way to speed up memory copying. I gave it to him. If you can show me a faster way to do it in Java, be my guest.

[Arkham_c]

Originally posted by hayesk:
Possibly. As I said, the poster asked for a way to speed up memory copying. I gave it to him. If you can show me a faster way to do it in Java, be my guest.

But the array copy is likely not the goal of the application. From a programming perspective this is a trivial problem. What makes switching to another language unpalatable is that once the array is copied, you would then have to USE that other language to write the application. If that other language is to be faster than Java, then it would have to be C or Fortran, which would result in an ugly, tedious coding process that is FAR more likely to have errors in it (because Java shields you from errors that lower-level languages does not). In most cases, the slight increase in execution speed of java is made up many times over in development time, code maintainability, and cross-platform execution convenience.

You can doggedly say that you were looking only at the specific problem presented, but within the context, you have to assume that Java was chosen for a good reason.

[K++]

Originally posted by Kristoff:
Actually, you are wrong.

just google for "ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method)" and you'll see that System.arraycopy throws ArrayIndexOutOfBounds exceptions (albeit only when people do dopey stuff).

Of course it throws it, after all it can't be a java method without throwing some exception or another but I said for "EACH AND EVERY INDEX", As I was instructed, that level of checking is skipped when your use arraycopy(). So next time your gonna go say I am wrong do a little more than just gogoling for information the javadoc clearly states.

http://java.sun.com/j2se/1.5.0/docs/...%20int,%20int)

By telling it the length before hand you forego the need to check EACH AND EVERY index, instead it checks the length that you passed it, but if you were bad enough to do that, then optimizing your application should not be your first concern.

Since you seem to need a helping hand, let me show you the relevant paragraph:

Otherwise, if any of the following is true, an IndexOutOfBoundsException is thrown and the destination is not modified:

- The srcPos argument is negative.
- The destPos argument is negative.
- The length argument is negative.
- srcPos+length is greater than src.length , the length of the source array.
- destPos+length is greater than dest.length , the length of the destination array.

[Kristoff]

K++....wtf?

Read your post again:

Originally posted by K++:
Actually, its faster only because it forgoes Java's need to double check your work and verify that each and every index is a valid one. Hence you'll get no IndexOutOfBoundException. I shouldn't need to explain why testing that for every index of an n*n array would not be too efficient.

You said: "It's faster only because it forgoes Java's need to..."

To which I said, you're wrong.

It's faster because it's a native method.

Then you said "Hence you'll get no IndexOutOfBoundException." implying that the method doesn't throw it.

To which I said, essentially, yes you will and offered where to find examples.


What is it with people on these boards trying to change what they said, and stick words in peoples mouth.

I mean, this whole thing started because someone said essentially "if you want it to be fast, don't use java" which is a bunch of crap. After given a couple of examples of where java is shown to be fast (a video clip and a technical paper) , he tried to change his argument to a "Java is not as good as C at memory manipulation."

Maybe I'm just too literal, but I read and respond to what I read. I can't read minds in person or across the internet.

That being said, I still think that "if you want it to be fast, don't use java" is a lame statement on it's face lacking validity.

And, I think that System.arraycopy is faster because it's a native method with all that implies.

[K++]

Okay, I need to spell it out

Originally posted by Kristoff:
K++....wtf?

Read your post again:

I did and it says exactly what I said and meant how i meant to say it.

You said: "It's faster only because it forgoes Java's need to..."
To which I said, you're wrong.
It's faster because it's a native method.

Finishing that sentence, "... double check your work and verify that each and every index is a valid one. " When accessing an array element Java FIRST checks that that index is not out of bounds and if so throws an IndexOutOfBoundsException. I never said arrayCopy() threw no exceptions(), being native doesn't make it faster, though it has access to implementation details that you do not, it is still quite possible to write your own methods faster than native ones, just not in this instance, or perhaps even this language since one of the ways to gain speed is to deal with the memory itself and Java doesn't allow that.

Then you said "Hence you'll get no IndexOutOfBoundException." implying that the method doesn't throw it. To which I said, essentially, yes you will and offered where to find examples.

I should have better worded that, but I hadn't expected someone to lack the ability to comprehend what I was saying, yes it can throw an indexOutOfBoundsException, but it does that before having done anything by checking once and only once rather than for every single index of the array.

What is it with people on these boards trying to change what they said, and stick words in peoples mouth.

I mean, this whole thing started because someone said essentially "if you want it to be fast, don't use java" which is a bunch of crap. After given a couple of examples of where java is shown to be fast (a video clip and a technical paper) , he tried to change his argument to a "Java is not as good as C at memory manipulation."

What is it with people on fora that feel the need to correct other people with incorrect imformation. With that I mean that yes, it can throw the exception, but no, its speed isn't greater merely because it is native, and in my second post explained why that is since you thought google would be a better reference than the javadoc itself.

Maybe I'm just too literal, but I read and respond to what I read. I can't read minds in person or across the internet.

Your not being literal enough as my original post and followup are in complete agreement, and I have gone straight to the horses mouth to make my point whereas your relying on second hand sources.

That being said, I still think that "if you want it to be fast, don't use java" is a lame statement on it's face lacking validity. And, I think that System.arraycopy is faster because it's a native method with all that implies.

You can think it's lame all you want, that doesn't detract from its validity. Java still is not as fast as C, and no benchmark attempts to claim so. If he were writing it in C a quick memcpy() would give him an O(1) copy of his entire array. How can arraycopy() beat that? Java doesn't let us play with memory and even if it did, it doesn't allocate blocks contiguously and depends on the VM. We already know it iterates through thanks to the javadoc, so thats O(n), and in some cases it creates a temp array to hold the elements as it copies them. For all the reasons I have stated, arraycopy() is faster than doing it yourself, not merely because it is native.

Notice the literal meaning there: faster because of several factors, though one is contributing to, it is not the sole reason for its performance.

P.S. If I need to break it down further than its obvious that Java IS the language for you and you should stay with what your capable of.

[Kristoff]

No, let me break it down for you:

1) System.arraycopy is a native method.

You obviously don't really understand what that means, or you wouldn't keep on arguing the obvious. Why in the hell would a native method-- implemented to copy an array --need to bother checking indices for validity?

You state the absurdly obvious and proclaim some greater level of understanding.

Here's something to think about. How would you write a native method to copy an array? Would you even care anything about the array (other than pertaining to the memory it occupies)?

Have you ever looked at the Java source code?

I understand how arraycopy was implemented--from your posts, you might not. To say that arraycopy is faster because it skips index checking is not exactly a false statement, it's just that it misses the point. As a native method, all arraycopy really cares about is the address of the source, address of the destination, and the length. As a native method, arraycopy doesn't use Java to do it's job at all. So, stick a feather in hayesk's cap about C's efficiency of manipulating memory.

So, having said that, I guess I miss your point. Because I know you knew all that already. So please break it down for me further.

EDIT: I just re-read your last post...you don't know what "native method" is, do you?

Specifically the part where you say: "If he were writing it in C a quick memcpy() would give him an O(1) copy of his entire array. How can arraycopy() beat that".

What do you think the native method implementation of arraycopy does?

Do you know what JNI is?

[itistoday]

Originally posted by Kristoff:
Do you know what JNI is?

That's a very good point, I didn't even realize that. The original poster can, if he wants, write this and similar functions entirely in C and use them with Java. His application would perform that memory-intensive function quickly, but it would no longer work on other platforms. If this is a really big deal to him, then he can implement a native implementation for every platform it will be running on, and he'll get the best of both worlds: Java's compatability, and C's low-level memory management.

[Kristoff]

but of course he wouldn't have to write this function because that's what System.arraycopy is--a native implementation.

[itistoday]

Originally posted by Kristoff:
but of course he wouldn't have to write this function because that's what System.arraycopy is--a native implementation.

but of course I was just explaining what JNI was to those who didn't know. More info here.

[BLAZE_MkIV]

If the function gets called repeatedly then wouldn't getting rid of repedative allocations by moving the allocation of the new array out of the function spead things up considerably?

[K++]

Where the hell did my last paragraph go?? And why doesn't it show who edited it out??

[QUOTE]Originally posted by Kristoff:
No, let me break it down for you:

1) System.arraycopy is a native method.

You obviously don't really understand what that means, or you wouldn't keep on arguing the obvious. Why in the hell would a native method-- implemented to copy an array --need to bother checking indices for validity?[quote]
That is my point but you make it on the basis that it is a native method, the mere fact that you could manually write code to do this faster in java shows that its not all it can be.

Here's something to think about. How would you write a native method to copy an array? Would you even care anything about the array (other than pertaining to the memory it occupies)?

yes, you would care about the array, cuz that memory it occupies is the array.

Have you ever looked at the Java source code?

No, and I doubt you have either unless you work for Sun. So the javadoc remains the best source for definitive knowledge on how Java does or does not do things in a public method.

I understand how arraycopy was implemented--from your posts, you might not. To say that arraycopy is faster because it skips index checking is not exactly a false statement, it's just that it misses the point. As a native method, all arraycopy really cares about is the address of the source, address of the destination, and the length. As a native method, arraycopy doesn't use Java to do it's job at all. So, stick a feather in hayesk's cap about C's efficiency of manipulating memory.

This was my point except again your choosing the mere fact that it is a native method as the end all be all reason why its faster.

So, having said that, I guess I miss your point. Because I know you knew all that already. So please break it down for me further.

EDIT: I just re-read your last post...you don't know what "native method" is, do you?

Specifically the part where you say: "If he were writing it in C a quick memcpy() would give him an O(1) copy of his entire array. How can arraycopy() beat that".

What do you think the native method implementation of arraycopy does?

How do you know that arraycopy() does that? The javadoc doesn't say it, I have no access to source code that would reveal that, and you have offered nothing to show that arraycopy works as you claim. I can only draw conclusions from what I know to be fact and that is the javadoc. As to your assumption that arraycopy does the same thing as memcopy, Java doesn't guarantee contiguous memory allocation, so how can you possibly assume that memcopy and arraycopy could possible be equivalent? I could go into more of the how java works and what Java does AS STATED BY THE JAVADOCS,(those nice things Sun goes to the trouble of spelling out java's API and implementation in) but I am pretty confident you can read them yourself

Do you know what JNI is?

JNI is counter to everything that Java sucks at, and that is cross platform code, by the mere use of it, you lose that. As to assuming that NativeMethods mean use of JNI, JNI bridges to the underlying OSes code whereas NativeMethods bypass Java to deal directly with the VM, so they are not equivalent.

If you want to continue this feel free to offer me something substantial that isn't you rambling and is instead found on java.sun.com to prove or disprove your points.

[Kristoff]

You do have access to the source code, you just don't know it.

System.arraycopy is a native method. Native methods use JNI. They are one and the same.

arraycopy is faster because it uses jni to access a method written in C to access the memory directly--irregardless of the specific details of the array (except as pertains to the memory it occupies--as I said earlier, like address of the source, address of the dest, starting positions and size.)

I have tried to help the original poster, and I have tried to share insight with you and whomever else might be reading the thread.

The original poster said he wanted to speed up copying an array in java. Sun provided a native implementation in System.arraycopy for just that purpose.

Originally posted by Arkham_c:

You can doggedly say that you were looking only at the specific problem presented, but within the context, you have to assume that Java was chosen for a good reason.

I don't have to assume Java was chosen for a reason. Heck, most novice programmers use Java because that is all they know. The original poster can decide for himself. I don't know what app he is writing, maybe arraycopying is of utmost importance to his app. That's why I said "if you need it to be fast."

Java is a tool, C is a tool. You and Kristoff assume it has to be done in Java. Since we don't know what app he is writing and who is going to use it, that could very well be a false assumption.

All the poster asked was how to speed up an array copy. I told him the correct answer - it can't be sped up in Java - that is the fastest it's going to get.

[Kristoff]

But Hayesk, the topic of the thread is "Java Problem" where he asks for ways to speed up copying an array in Java.

It's not "Which language is fastest for copying arrays."

That's why we assume he wants to know the fastest way of copying an array in Java.

Originally posted by Kristoff:
But Hayesk, the topic of the thread is "Java Problem" where he asks for ways to speed up copying an array in Java.

And I answered him - he is already doing it the fastest way. Go back and read my post if you like.

It's not "Which language is fastest for copying arrays."

So what? What if he posted after that asking "well, I need it to be faster, what language is better?" I already answered the question. Do you always answer questions with the bare minimum of information? I anticipated a future question and answered it. Obviously he has some concern for speed, since he asked how to improve his algorithm. It's not an unrealistic assumption.

That's why we assume he wants to know the fastest way of copying an array in Java.

And I told him. He already is doing so. You just took offense to my recommendation to "use C instead if you need it to be faster." I still don't understand why this upset you so much.