On November 13, 2010 at 08:44, Audible Solutions said...
Systembuilder is a very different animal than plain Simpl. It's running the full suite of Crestron programs at the same time but it's also running Axis and lord knows what else beneath the hood to link the database to those Cresetron apps and generating the actual programs the hardware requires to work. It's not a single smw file.
I realize that and I was clear early on that I don't use SB. But for grins, I went ahead and compiled the example system with SB. See more below.
I'm doubtful that a cpu test based on Simpl tells you very much about using Systembuilder.
No reason to be doubtful. I showed how easy it is to determine these things with Perfmon. To wit, I went ahead and ran SB. And once more, it shows that there is almost no concurrency going on. My CPU usage never went above 15% on my Desktop and most of the time hovered at 13 to 14%. So the level of parallelism versus SMPL compiles is negligible. You want SB to go faster, you need the fastest speed you can get for your CPU core.
Systembuilder is not just compiling a simpl Windows program. It's building the graphics files and code from these databases. It's linking the changes you've made to the underlying databases and linking those to templates upon which the source code for a project is being generated. You are compiling source code. Systembuilder is generating the source code from the underlying databases.
That workload does generate I/O but typical of these systems, it is a sequential task. Input is parsed, SMPL code is generated and then compiled. Lots more files are accessed to be sure. But CPU speed dominates just the same as I showed in the SMPL compile.
It seems logical therefore that Systembuilder will place greater demands on a computer than Simpl Windows or VT-Pro by themselves. The basic database in Axis has to be stitched into these other programs, where templates build the basic UI and then the logic in each and every UI has to be woven.
As I just explained, SB is also CPU bound for the most part, not multi-threaded, and doesn't spawn multiple processes either. There is more I/O as it creates more files and accesses more data that way, but as far as I can tell in my example compile above, the dominant portion is a single CPU core being pounded on.
In evaluating the correct CPU for this application you do need to provide a test for a program that is going to run multiple, related applications and other applications that link and stitch these applications together. You may still be correct but, logically, you seem to be testing something very different from Systembuilder and making a conclusion that doesn't seem to relate to it.
Alan
I made no conclusion about SB. I have been very clear about what I have been testing and talking about starting with the second post in this thread. That said, you are right that every workload is different and should be tested. And that OP did indeed want to know about the entire workload in SB. Hopefully the additions in this post take care of that.
