MS + DotNet MultiThreading with objects creation

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
  04 April 2013
Yeah I know
__________________
The GPU revolution will not be rasterized! - http://www.jdbgraphics.nl
 
  04 April 2013
Originally Posted by gazybara: Hey Jonathan,
your attach method is very fast!

you do wrong test for the performance...

the ProBoolean attach method is much slower then smart poly attach and much more expensive for memory use.

here is true test:

 fn makeNodes offset:[0,0,0] wirecolor:orange clean:on = 
 (
 	if clean do delete objects 
 	nodes = #()
 	for y=0 to 9 do for x=0 to 9 do
 	(
 		b = box width:10 length:10 height:10 widthSegs:10 lengthSegs:10 heightSegs:10 pos:([x*12,y*12,0] + offset) wirecolor:yellow
 		append nodes (converttopoly b)
 	)
 	s = box width:20 length:20 height:20 pos:([-20,0,0] + offset) wirecolor:wirecolor
 	#(converttopoly s, nodes)
 )
 
 fn clusterAttach source nodes =
 (
 	k = 1
 	insertitem source nodes 1
 	count = nodes.count
 	attach = polyop.attach
 	while nodes.count > 1 and not keyboard.escpressed do
 	(
 		attach nodes[k] nodes[k+1]
 		deleteItem nodes (k+1)
 		k += 1
 		if (k+1) > nodes.count do k = 1
 	)
 	nodes[1]
 )
 
 fn booleanAttach source nodes =
 (
 	ProBoolean.createBooleanObject source undefined 4 1 0
 	for k=1 to nodes.count while not keyboard.escpressed do
 	(
 		ProBoolean.SetOperandB source nodes[k] 4 0
 	)
 	converttopoly source
 	source
 )
 
 max create mode
 (
 	d = makeNodes offset:[0,0,25] wirecolor:brown clean:on
 	gc()
 	t1 = timestamp()
 	m1 = heapfree
 	booleanAttach d[1] d[2]
 	format "boolean >> time:% memory:%\n" (timestamp() - t1) (m1 - heapfree)
 )
 (
 	d = makeNodes offset:[0,0,0] wirecolor:orange clean:off
 	gc()
 	t1 = timestamp()
 	m1 = heapfree
 	clusterAttach d[1] d[2]
 	format "cluster >> time:% memory:%\n" (timestamp() - t1) (m1 - heapfree)
 )
 

Last edited by denisT : 04 April 2013 at 02:45 PM.
 
  04 April 2013
Originally Posted by denisT: you do wrong test for the performance...

the ProBoolean attach method is much slower then smart poly attach and much more expensive for memory use.

here is true test:
. . . . . . . .

Yeah,yeah DenisT fast attach method.
But why is this method slower then cluster. You use insertItem and deleteItem array methods and again is faser then simple for - loop.
fn attachSelections source nodes returnAs:#EMesh = -- 
(
	local poAttach = polyop.attach 
	for i = nodes.count to 1 by -1 do poAttach source nodes[i]
	if returnAs != #EPoly then convertToMesh source else source
)
fn clusterAttach source nodes =
(
	k = 1
	insertitem source nodes 1
	attach = polyop.attach
	while nodes.count > 1 and not keyboard.escpressed do
	(
		attach nodes[k] nodes[k+1]
		deleteItem nodes (k+1)
		k += 1
		if (k+1) > nodes.count do k = 1
	)
	nodes[1]
)

	gc()
	t1 = timestamp()
	m1 = heapfree
	nodes = (selection as array) ; converttopoly nodes
	source = nodes[nodes.count]
	nodes.count = nodes.count-1
	--clusterAttach source nodes
	attachSelections source nodes returnAs:#EPoly
	format "cluster >> time:% memory:%\n" (timestamp() - t1) (m1 - heapfree)
__________________
Looking in the right side. [bgaTools]
 
  04 April 2013
Originally Posted by denisT: you do wrong test for the performance...
the ProBoolean attach method is much slower then smart poly attach and much more expensive for memory use.


Your test is rigged There is no need to convert to poly here.. so without that:

boolean >> time:31 memory:19328L
OK
cluster >> time:153 memory:19392L
OK
__________________
The GPU revolution will not be rasterized! - http://www.jdbgraphics.nl
 
  04 April 2013
Originally Posted by jonadb: Your test is rigged There is no need to convert to poly here.. so without that:

boolean >> time:31 memory:19328L
OK
cluster >> time:153 memory:19392L
OK


this is not true again... you don't need to convert to poly, but you must update the pro boolean object. so we have to include this time to calculation as well. ok. change converttopoly to completeredraw for example...
 
  04 April 2013
Originally Posted by gazybara: Yeah,yeah DenisT fast attach method.
But why is this method slower then cluster. You use insertItem and deleteItem array methods and again is faser then simple for - loop.

the fictitious speed of proboolean attach is because we don't do any mesh updates before the end of attaching. but after that we have to rebuild all normals, ids, smoothing groups, etc. and that's a necessary part of the process. so we have to include update time to calculation.
 
  04 April 2013
Originally Posted by denisT: this is not true again... you don't need to convert to poly, but you must update the pro boolean object. so we have to include this time to calculation as well. ok. change converttopoly to completeredraw for example...


Ahh, my bad.. I found the timings to a bit one the fast side. I wonder how both scale and if there is a tipping point somewhere..
__________________
The GPU revolution will not be rasterized! - http://www.jdbgraphics.nl
 
  04 April 2013
btw.. I was able to optimize it a bit and get rid of the for/next loop by directly feeding it an array of nodes:


fn booleanAttach source nodes =
 (
	ProBoolean.createBooleanObjects source nodes 4 2 1
	completeredraw()
	source
 )


But cluster remains faster by a factor of around 3x to about 1.5x when you increase the node count and then it levels off..
__________________
The GPU revolution will not be rasterized! - http://www.jdbgraphics.nl
 
  04 April 2013
i've discussed fast attach methods many times on this forum... there is no wonder in this subject.
the speed of a method is proportional to number of mesh updates.

let's say we have to attach 8 nodes with 1 poly in its mesh.
poly object updates its mesh after every attachnemt.

so here is a linear method and number of updates:
1 + 1 = 2 updates
2 + 1 = 3 updates
...
7 + 1 = 8 updates
all together is (2+3+4+5+6+7+8) = 35 updates

here is a cluster method:
1 + 1 = 2
1 + 1 = 2
1 + 1 = 2
1 + 1 = 2
2 + 2 = 4
2 + 2 = 4
4 + 4 = 8
all together is (2+2+2+2+4+4+8) = 24 updates

so we can write some formulas that calculates number of updates in our sample:
(the cluster formula is not correct but is good enough to show the difference. anyone free to post the correct one):

fn linearUpdates count = 
(
	count = count/2*2
	local num = 0
	for k=1 to count-1 do num += k+1
	num
)
fn clusterUpdates count = 
(
	count = count/2*2
	local n, a = 2, num = 0
	while (n = count/a) > 0 do
	(
		for k=1 to n do num += a
		a *= 2	
	)
	num
)

what we have:
linearUpdates 8
35
clusterUpdates 8
24

not a big deal, isn't it?

well...
linearUpdates 100
5049
clusterUpdates 100
552
oops... ~9 times difference

linearUpdates 10000
50004999
clusterUpdates 10000
123456
wow! ~405 times difference.

but the funniest thing about everything told above is that we really need only 10000 updates to attach 10000 one poly nodes.
 
  04 April 2013
Originally Posted by jonadb: btw.. I was able to optimize it a bit and get rid of the for/next loop by directly feeding it an array of nodes:


  fn booleanAttach source nodes =
   (
  	ProBoolean.createBooleanObjects source nodes 4 2 1
  	completeredraw()
  	source
   )
  


But cluster remains faster by a factor of around 3x to about 1.5x when you increase the node count and then it levels off..


it gives me the same performance as a boolean attaching by one...
 
  04 April 2013
Originally Posted by denisT: what we have:
linearUpdates 8
35
clusterUpdates 8
24

not a big deal, isn't it?

well...
linearUpdates 100
5049
clusterUpdates 100
552
oops... ~9 times difference

linearUpdates 10000
50004999
clusterUpdates 10000
123456
wow! ~405 times difference.

of course we have to understand that it's not a linear proportion between number updates and speed. poly object does do update smarter than primitive. it has some cached local data which updates faster than newly added.
 
  04 April 2013
Here is a crazy pro-tips thread!
Very interesting, thanks!
 
  04 April 2013
jonadb : Very impressive your script !


Quote: Waht you could do is save your scene 8 times, each with a different name that includes a framerange but before you do that set a startupscript that extracts the frameranges from the filenames and starts the calculation for them after which it automatically saves the file.

So you get 8 files like this:

file_0_200.max
file_201_400.max
etc

Start Max via shelllaunch, each loading a different file.. the startup script kicks in and performs the operation on set ranges and saves when done. Merge results into on file and you're done


Exactly what i'm planning to do I already started , thank you again for your help
 
  04 April 2013
Originally Posted by GreySize: jonadb : Very impressive your script !


Thx! but there was a slight timing measurement issue.. while it is fast, DenisT's clusters script is faster and scales better with large object counts.
__________________
The GPU revolution will not be rasterized! - http://www.jdbgraphics.nl
 
  04 April 2013
Yeah it seems to be the fastest, i'll change the boolean method after the 8*max script launch
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 10:00 AM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.