ZDBSP 1.9: Obviously ZDBSP 1.8 Wasn't the End

[entryway]

did you build your own ZDBSP 1.9 with GCC or use the one I provided?

I have both.
VC++ build (1.9) - 2.715 seconds
GCC build (1.9.1) - 2.625 seconds
Intel build (1.9.my) - 2.335 seconds

I'd be interested in seeing its assembler output for the ClassifyLine functions

zdbsp_Intel ReleaseSSE with optimization for PetiumM
(It slower than sse2 release on my PentiumIV)

[randi]

Here's what I get on my Athlon 64 3500+ (best times from several runs):

GCC: 1.958 seconds
GCC, with SSE2 turned on for every file: 2.052 seconds
Pentium M optimized: 2.041 seconds
Pentium IV optimized: 2.141 seconds
Pentium IV SSE2 optimized: 2.042 seconds

It's all very close, but the regular GCC build manages to beat them all. Ironically, it's tuned for a Pentium Pro, not an Athlon 64. I'm also a bit surprised that the full SSE2 GCC version ended up being slower on my machine, since it was faster than the straight x87 builds on earlier versions.

I wonder what I would happen if I used the Intel compiler's version of ClassifyLine...

[entryway]

Here's what I get on my Athlon 64 3500+
GCC: 1.958 seconds
GCC, with SSE2 turned on for every file: 2.052 seconds
Pentium M optimized: 2.041 seconds

Not surprisingly that INTEL-specific builds run more slowly on AMD processors

I wonder what I would happen if I used the Intel compiler's version of ClassifyLine...

DLL and optional command line switch [-dll filename]

[Graf Zahl]

Is this fight for microseconds really worth it? Even the least optimal ZDBSP build is faster than anything else there and builds the largest maps I have ever seen in way below 10 seconds. What's the point in shaving off another quarter of a second off it? Nobody will ever notice.

[entryway]

for fun only
of course

microseconds

(2.7-2.3)*100/2.7 = 14% acceleration

[Hirogen2]

If the Intel version is still faster than the GCC version, I'd be interested in seeing its assembler output for the ClassifyLine functions. Since the nodebuilder spends over half its time in that one function, it seems the best place to optimize.

You might be wanting to use gcov for a per-line analysis.
-mcpu=i686 is of course a little different than -mcpu=athlon-xp (my case, no numbers ATM).
As for k8, the linux kernel uses -march=nocona for EM64T, while -march=k8 is AMD64. Someone could try that.

[entryway]

I wrote the program for solving of children's game 15 and have moved solving procedure in DLL (can be chosen from the GUI)

---

and have compiled it by means of many compilers (intel8, intel9, vc6, vc7, gcc, delphi) for comparison of speed. I can share it if you want to test

[randi]

Even the least optimal ZDBSP build is faster than anything else there and builds the largest maps I have ever seen in way below 10 seconds.

Heh heh. Want to see it go slow? Add -p20000 or some other big number and watch it take MUCH, MUCH longer to save only a couple hundred segs on big maps.

Speaking of fastness, I tried compiling on an 800 MHz PowerMac G4, and Warm was nearly three times faster than ZDBSP at generating nodes. But because Warm outputs to the console every time it descends a node, its overall time was slightly slower than ZDBSP's. It turns out MacOS X has really slow console output.

[Bio Hazard]

It turns out MacOS X has really slow console output.

Why am I not the least bit suprised?

[Hirogen2]

It turns out MacOS X has really slow console output.

Why am I not the least bit suprised?

Possibly because it uses framebuffer (at least OpenDarwin does / not sure how the "xterm" speed in Cocoa is)
Possibly because the kernel is a MACH/BSD offspring.
Possibly no 2D acceleration.
That is why you should always test with ">/dev/null".

[Softie]

Is Warm open source? I did google it but never found anything useful.

[Jive]

Someone generous enough to explain to me (yes, I know, I'm a nerd...) the difference between ZDBSP and GlBsp(X) (http://glbsp.sourceforge.net/) ?
The latest version of GlBsp(X) is 2.20 and is dated 16th September 2005.
So, it seems to me that it's outdated, when I see that you are all talking about improvements and debug of ZDBSP, when the author of GlBsp(X) (Andrew Apted) is claiming that his tool is stable.
Sorry about it, because I'm quite new with Zdoom, and my question is quite surely typical of a newbie...

[Neil]

It turns out MacOS X has really slow console output.

The default Terminal is really flashy and slow, yes. there's always xterm though if you want speed, heh.

[shinobi.cl]

Just wanted to note something

I have zdbsp1.8, and when i compile the nodes in a map of mine with it i got the following behavoir

http://youtube.com/watch?v=C874IXi3JkU

Well.. i've compiled the map with glBSP and the problem dissapeared...

But in the bad side, the file size increased due to the GL info.

this is the file (of course, now compiled with glBSP)
http://shinobi.cl.googlepages.com/shinFFA_SW.zip

The map in the video is E1M5

[Graf Zahl]

If you had read the title of this thread carefully you might have noticed that 1.9 is the current version. Please recompile your nodes with this latest version and report back.