Re: help for running CPU intensive progr# Java - 爪哇娇娃
m*r
1 楼
Believe it or not, I've used OptimizeSuite/JProbe/JProfiler for that. I'm pretty sure there's not much space to improve. can the If
m*r
2 楼
The problem is I haven't used C since 1993. Perhaps it's a good chance for me to learn C again. can the If
st
3 楼
not that much different, what's the problem? no way to use dynamic programming? some time the memory size you give java matter a lot, try to increate xmx
【在 m********r 的大作中提到】 : : The problem is I haven't used C since 1993. Perhaps it's a good chance for me : to learn C again. : can : the : If
m*r
4 楼
programming? What does "dynamic programming" mean ? I think Java is a dynamic language, isn't it? It's not just memory problem. It is CPU intensive too. If I can get gc working, then there's no memory problem. A lot of temp objects can be collected I just can not force jvm to. I've increased mx to 512M which is not enough when input >= 20. me
【在 st 的大作中提到】 : not that much different, what's the problem? no way to use dynamic programming? : some time the memory size you give java matter a lot, try to increate xmx
st
5 楼
dynamic programming, IMHO, it's simply a trade off by using memory to save results from previous steps to speed up the process, if possible. you know memory operation is CPU intensive, right? increase it to 1024M?
【在 m********r 的大作中提到】 : : programming? : What does "dynamic programming" mean ? I think Java is a dynamic language, : isn't it? : It's not just memory problem. It is CPU intensive too. If I can get gc : working, then there's no memory problem. A lot of temp objects can be : collected I just can not force jvm to. : I've increased mx to 512M which is not enough when input >= 20. : me
m*r
6 楼
language, If that's the case, I'm doing dynamic programming. Everything is in the memory and the final result is printed to the screen. xmx Yeah. But there's no way around that. I can try that, but the total memory it has is 1024M. I'm really more interested in running it on a faster system with much more memory. Don't know what's the max size JVM can handle yet though.
【在 st 的大作中提到】 : : dynamic programming, IMHO, it's simply a trade off by using memory to save : results from previous steps to speed up the process, if possible. : you know memory operation is CPU intensive, right? : increase it to 1024M?
m*r
7 楼
fast ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is interesting. I didn't ever think about it. If set the object to null will free the memory then I definitely don't need GC here. I'll give it a try now. A faster CPU is still helpful because the running time is like O(a^n). can the If
st
8 楼
only when there's no reference to the object, it's GCed. set this explicityly can save you a lot trouble.
【在 m********r 的大作中提到】 : : fast : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : This is interesting. I didn't ever think : about it. If set the object to null will free the memory then I definitely : don't : need GC here. I'll give it a try now. : A faster CPU is still helpful because the running time is like O(a^n). : can : the
f*h
9 楼
It will grow faster than you ever imagine. Maybe you need to look at the algorithm carefully again.
m*t
10 楼
or Yeah I was going to ask you what the mathematical boundaries of your algorithm are. Well if it's O(a^n), there isn't a lot you can do. You can probably manage to get to 20, or 25, maybe, but you are "mathematically doomed". (I like that phrase! 8-) )
【在 m********r 的大作中提到】 : : fast : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : This is interesting. I didn't ever think : about it. If set the object to null will free the memory then I definitely : don't : need GC here. I'll give it a try now. : A faster CPU is still helpful because the running time is like O(a^n). : can : the
m*r
11 楼
explicityly Do you mean even if I set something=null, gc has to be invoked to free the memory, right? null, or think
【在 st 的大作中提到】 : only when there's no reference to the object, it's GCed. set this explicityly : can save you a lot trouble.
【在 m********r 的大作中提到】 : : explicityly : Do you mean even if I set something=null, gc has to be invoked to free the : memory, right? : null, or : think
m*r
13 楼
null, think algorithm to Yeah I know. It's a brute force algorithm which computes explosive cases. Before a better one is found I just want to see more results.
【在 m******t 的大作中提到】 : : or : Yeah I was going to ask you what the mathematical boundaries of your algorithm : are. : Well if it's O(a^n), there isn't a lot you can do. You can probably manage to : get to : 20, or 25, maybe, but you are "mathematically doomed". (I like that phrase! : 8-) )
m*t
14 楼
Can you divide the algorithm into small parts and run them distributedly? Like the [email protected] project? 8-)
【在 m********r 的大作中提到】 : : null, : think : algorithm : to : Yeah I know. It's a brute force algorithm which computes explosive cases. : Before a better one is found I just want to see more results.
m*r
15 楼
Theoretically it's doable. The problem is it's almost impossible to combine the intermediate results. There'll be a huge amount of intermediate data to be stored, transmitted. It'll become another bottleneck.
【在 m******t 的大作中提到】 : : Can you divide the algorithm into small parts and run them distributedly? : Like the [email protected] project? 8-)
m*r
16 楼
Maybe sometime later I'll explain what I intend to do here. The code is trivial and hard to understand.
Thank you all for the kind help. I'll spend some time to get GC work and post the status here. bye. Cao
g*g
18 楼
There is no way to explicitly invoke GC, although call System.gc will express your desire and likely the gc thread's priority will increase. However, refered objects will never be GCed. Set large unused object to null is a good style every java programmer should follow.
not of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ definitely
【在 m********r 的大作中提到】 : Thank you all for the kind help. I'll spend some time to get GC work and post : the status here. : bye. : Cao
e*g
19 楼
you don't have to use object just because it is java. a small numeric program can be in primitive type completely.
【在 m********r 的大作中提到】 : Thank you all for the kind help. I'll spend some time to get GC work and post : the status here. : bye. : Cao
r*a
20 楼
it is a trick, but it is pretty annoying, hoho, not much different from the deallocation of pointers
【在 st 的大作中提到】 : only when there's no reference to the object, it's GCed. set this explicityly : can save you a lot trouble.
r*a
21 楼
I don't think it is a good style, tho it may be a reasonable practice 这种做法很明显只会使代码变得很凌乱
【在 g*****g 的大作中提到】 : There is no way to explicitly invoke GC, although call System.gc will express : your desire and likely the gc thread's priority will increase. However, : refered objects will never be GCed. Set large unused object to null is a good : style every java programmer should follow. : : not : of : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : definitely
m*t
22 楼
express good There is a difference between "referred objects will never be GCed"(not true), and "reachable objects will never be GCed"(true). IMHO, explicitly setting references to null essentially defeats the purpose of having gc in Java - to relieve programmers from memory management. I've always been a strong believer of Java gc, and I think I'm going to continue to be one, based on its track record with me.
【在 r**a 的大作中提到】 : : I don't think it is a good style, tho it may be a reasonable practice : 这种做法很明显只会使代码变得很凌乱
r*a
23 楼
agree, if the programmer has to remember which variable to set as null for the gc to reclaim memory, why not ask him to reclaim directly? gc sucks, mem leak is hard to avoid
【在 m******t 的大作中提到】 : : express : good : There is a difference between "referred objects will never be GCed"(not true), : and "reachable objects will never be GCed"(true). : IMHO, explicitly setting references to null essentially defeats the purpose of : having gc in Java - to relieve programmers from memory management. : I've always been a strong believer of Java gc, and I think I'm going to : continue : to be one, based on its track record with me.
g*g
24 楼
No, practically you won't have many large unused objects. When I said large, most of the time it's resources like multiple dimension arrays, images, a/v clips, network connections, database connections. These are objects you should take care a bit, especially when they are instance variables which would be reachable throughout of object lifetime. You don't need to remember every object you use, just be aware of those memory intensive ones. It's good pratice and good style. Assign it to null afte
【在 m******t 的大作中提到】 : : express : good : There is a difference between "referred objects will never be GCed"(not true), : and "reachable objects will never be GCed"(true). : IMHO, explicitly setting references to null essentially defeats the purpose of : having gc in Java - to relieve programmers from memory management. : I've always been a strong believer of Java gc, and I think I'm going to : continue : to be one, based on its track record with me.
m*t
25 楼
Wow, wow, hold there a min. Let's be careful - "multiple dimension arrays" and "network/database connections" are totally different in this context. Releasing connections or any other system resources *other than* memory is not only good style but actually mandatory. But arrays that are merelly heap blocks? that's a different story. intensive time If an object is reachable from some other object, that "reacher" object needs to maintain it. If an object only needs to be reachable during one op
【在 g*****g 的大作中提到】 : No, practically you won't have many large unused objects. : When I said large, most of the time it's resources like multiple dimension : arrays, images, a/v clips, network connections, database connections. These : are objects you should take care a bit, especially when they are instance : variables which would be reachable throughout of object lifetime. You don't : need to remember every object you use, just be aware of those memory intensive : ones. It's good pratice and good style. Assign it to null afte
m*r
26 楼
I'm now using below code to invoke GC when necessary. Let's hope it'll work. loopBeforeGC --; if (loopBeforeGC == 0) { loopBeforeGC = LOOP_BEFORE_GC; while (Runtime.getRuntime().freeMemory() < 30000000) { System.out.println("loop: "+loopSize); System.out.println("free memory: "+Runtime.getRuntime().freeMemory()); System.gc(); try { Thread.sleep(300); } catch (InterruptedException e) { e.printStackTrace(); } } } s
【在 g*****g 的大作中提到】 : There is no way to explicitly invoke GC, although call System.gc will express : your desire and likely the gc thread's priority will increase. However, : refered objects will never be GCed. Set large unused object to null is a good : style every java programmer should follow. : : not : of : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : definitely
m*t
27 楼
This is messed up, man. You are programming in Java, for crying out loud... It's all goodbug's fault. 8-)
【在 m********r 的大作中提到】 : I'm now using below code to invoke GC when necessary. Let's hope it'll work. : loopBeforeGC --; : if (loopBeforeGC == 0) { : loopBeforeGC = LOOP_BEFORE_GC; : while (Runtime.getRuntime().freeMemory() < 30000000) { : System.out.println("loop: "+loopSize); : System.out.println("free memory: "+Runtime.getRuntime().freeMemory()); : System.gc(); : try { : Thread.sleep(300);
g*g
28 楼
ugh, this is getting ugly. better check if you can do something else to save some memory in the first place than screw GC in this way. Partition your problem if possible, consider save intermediate result in file, etc. Chances are you'll loop infinitely if you don't have enough GCable memory. And get yourself some physical memory if you really need it, it's less than $30 for 512MB AR. And you can ignore magicfat from this point, if you don't know why, check my signature. //sniff
work. "+Runtime
【在 m******t 的大作中提到】 : This is messed up, man. You are programming in Java, for crying out loud... : It's all goodbug's fault. 8-)
m*t
29 楼
Whatever, man, all I did was telling the truth, nothing more... 8-)
【在 g*****g 的大作中提到】 : ugh, this is getting ugly. better check if you can do something else to save : some memory in the first place than screw GC in this way. Partition your : problem if possible, consider save intermediate result in file, etc. : Chances are you'll loop infinitely if you don't have enough GCable memory. : And get yourself some physical memory if you really need it, it's less than : $30 for 512MB AR. : And you can ignore magicfat from this point, if you don't know why, check my : signature. //sniff : : work.
m*r
30 楼
Don't worry this is not a commercial program and even if it is, all kinds of hack can exist there. no one care. Right now I just need to overcome the memory problem, gc is something worth a try so why not. If I get a infinite loop I can just kill it and change my code. loud...
【在 g*****g 的大作中提到】 : ugh, this is getting ugly. better check if you can do something else to save : some memory in the first place than screw GC in this way. Partition your : problem if possible, consider save intermediate result in file, etc. : Chances are you'll loop infinitely if you don't have enough GCable memory. : And get yourself some physical memory if you really need it, it's less than : $30 for 512MB AR. : And you can ignore magicfat from this point, if you don't know why, check my : signature. //sniff : : work.