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
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
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
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.
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.
st
12 楼
http://developer.java.sun.com/developer/technicalArticles/ALT/RefObj/
but I think you'd better think more about your program....
maybe post the code here? if not too much code involved.
【在 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
but I think you'd better think more about your program....
maybe post the code here? if not too much code involved.
【在 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.
【在 st 的大作中提到】
: http://developer.java.sun.com/developer/technicalArticles/ALT/RefObj/
: but I think you'd better think more about your program....
: maybe post the code here? if not too much code involved.
m*r
17 楼
Thank you all for the kind help. I'll spend some time to get GC work and post
the status here.
bye.
Cao
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
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
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.
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
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);
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-)
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.
相关阅读