OK, let's start at the beginning :).

Multiple cores help you in two ways:

1. If your application is multi-threaded. For example, when we developed WMA audio codec at Microsoft, we designed it so that when encoding in stereo (e.g. CD ripping), each channel runs as a separate thread so two cores can be used to speed it up. If we had not done that, the second core would do you no good. As it is, going beyond 2 cores doesn't help you either as that is the limit of multi-threading in that codec.

The way that is done is that the application must be explicitly written to run in multiple threads. That is a difficult task as if you have to concurrent threads in a program, they can corrupt each other's data. And when that happens, finding out where and how it occurred can be quite challenging. For this reason, most of the applications you run are single threaded.

2. If you run multiple concurrent applications which are CPU bound. That way, the operating system schedules each task to run in a different core. If your application is I/O bound (e.g. mostly waits on hard disk) then this doesn't help you either. In the above CD ripping example, most systems today are I/O bound, waiting for the CD drive to feed it data so multi-threading is kind of wasted on fast CPUs.

We can dismiss #2 here as compiling a program is usually a sequential task. The source code is parsed, assembly/object code is generated and then everything is linked.

For #1, since neither one of us works for Crestron, we can't say how their application is written. However, we can monitor what it does as it is running. My laptop is a dual-core system. If the SIMPL Windows is threaded into two or more threads and it is CPU bound, it should be able to max out my entire CPU. But it doesn't. Here is what the CPU load looks like:



As you see the total CPU used is only 53%.  That is the equiv of one core out of two being in use.  Therefore, we know with high certainty then that Crestron compiler is not multi-threaded and adding cores to my system would do no good.  But to prove the point further, let's now run the same load on my Core i7 Desktop with 8 cores (half virtual):



As expected, the load now drops to 1/8 of the maximum available (100/8 = 12).  So we have pretty conclusive proof that Crestron tools are single-threaded and do not benefit in any way from additional cores.

Your best bet then is to get the fastest speed in one of those cores.  In other words, if you have a choice of quad core 2 GHz CPU and a dual core 2.8 GHz, all else being equal, the latter will run this load faster.


None of that is really material here :).  32-bit or 64-bit has no relevance to number of cores.  Rather, it impacts how much memory you can have in your computer which also doesn't matter here as the tools don't need 8 Gigabytes or anything close to it to run this load.  You can see that from my desktop stats which had nothing but Crestron tools running and you see that it is only using 2 Gigabytes.


I did not advocate buying a single core CPU as those are ancient animals.  Instead, as I explained, you need to focus on the speed of those cores, not how many there are.  So pay attention to clock frequency of the CPU (including what it jumps to when under load).  That is what is going to determine your speed in *this* application.

WHATTT!!! My first conversion from Composer to SB usually takes about 20-25 minutes for a typical system with a PTX3, PTL4 some keypads, 4 zones of audio and a few dimmers.

From there, building goes a little quicker but can still be 10-20 minutes each time. Feels like 30, I haven't timed recently, but I'm just using the low end Dell that came with the Demo. Its really nothing to brag about.

Sofa
during training my laptop was twice as slow as the free dell they gave out. Can you imagine?

Based on what I'm readying, it really sounds like a SSD would help and faster CPU, probably just a good Dual Core.

I really only do programming on the laptop, so i don't think I would SSD+HDD, plus I jus don't have an extra $1300 to drop on a laptop right now. HOwever, I do see value in investing some money if it will save me time ultimately.

I really haven't paid attention to SSD's. Can I just swap out a standard laptop HDD with a 2.5" SSD?

I stand corrected. And there is no point in me trying to theorize about facts if you have the means to do real world tests. Which of your systems compiles faster? Is there a noticeable difference in SIMPL performance from one machine or the other that can be attrbuted to anything other than RAM or CPU architecture?

I have more questions but I'm guessing you have more to do than watch CPU cycles with a stop watch.

I rarely use SB for anything but when I do it is usually a 5 or 6 panel system. The most recent system was an AES and AAE with 6 4L panels and a few ML for local TV controls. Nothing fancy and we needed to hit a very tight price point so programming labor wasnt allocated for anything other SB programming (4 hours programming labor - yes, it was done in less and was easy enough to do in SB even with some custom logic).

For you guys trying to figure out what you need in a machine to do your job, look at gaming machines. I realize that some people will protest and say that I am wrong and that you dont need that much horsepower. I call bullsh*t. When you buy tools, be it hand tools or power tools, do you buy the best money can buy or the throw away crap in the bargain bin by the check out at Lowe's? I'm willing to bet you buy the best tools money can buy because you HAVE to have them work each and every time. Well, if you have moved into the world of programming you need to go out and buy the best damn tools money can buy. Does that mean you need to go drop $8k on a Falcon Northwest Fragbook DRX? No but it does mean that you need to look at machines in the $1800+ range. You will need to buy an adapter for serial communications as well and that should come from Quatech and will cost around $140 or so. Then you need a case that is durable, a human sized travel mouse, mouse pad, USB thumb drives, various memory cards for processors (assuming Crestron here), cables for loading processors and remotes, etc. You HAVE to have good tools to do your job. Go for the big ass screen with the highest resolution you can get and make sure you look for a machine with discrete video RAM, instead of the onboard crap in the low end machines.

To put this in perspective for you, I can run SB, 5 copies of SIMPL, Photoshop, Fireworks, Outlook, Excel, Word, PowerPoint, Pandora or iTunes and surf the net using IE (just like I am now) without any issues. No slow down at all. The longer I have to wait to accomplish a task the less efficient I am as a programmer. This is equivelant to an installer trying to put on a compression connector with two pairs of channel lock pliers. It can be done but wouldnt it make more sense to buy the correct tool and just be done with it?

Av genius
Can you discuss acceptable specs for us. Your logic makes all the sense in the world.
Processor i7 820qm? Is an i5 sufficient?
Ram what is the level of diminishing returns?
Hard drive is7200rpm fast enogh or is solid state worth it?
I know this equivalent asking what is the best remote but can someone narrow it down please?

This is what I use for programming.

[Link: rog.asus.com]

The thing is big and heavy, but you cant ever have too much screen resolution. The most important thing for me is getting the job done. I like to be able to see 4 symbols open at a time in simple along with my program tree, and the symbol library. I like to build an X pannel in VT pro without having to scroll around on the screen. Just because your laptopp has a large screen doesnt meen that you have a high resolution screen.

I make my money programming, I use what helps me get my job done fast. I also connect a samsung 32" 1080p monitor t the laptop via HDMI as a second monitor. I run the VT program on the laptop and them simpl program on the 32". Having the i7 may not help the fact that simpl is single threaded program, but I also have multiple other programs running at the same time. I know you do to. Just look to the bottom right of your screen and see what isrunning in the background. All of those things use processing cycles, so the Multi core processors will appear faster.

Last but not least, if you dont want to complie for 20 to 30 minutes, learn Simpl. your compile time will be less than a minute. I tell everyone this because of the compile times but also because you can have so much more of a custom system. If you build the same type of systems often enough with similar pieces you should be able to cut your programming time down to next to nothing.

I will also agree that SSD is the easiest way to see an improvement in speed when using Crestron software. Since moving Simpl to an SSD, start up time wint from 39 seconds to 18 seconds. Thats twice as fast!

Not an option. Hell, They won't even let me take Advanced System Builder. Besides that, I don't have the time to invest. So far, i can do everything I need to do in SB. However, since I'm still learning, i find myself still forgetting or missing small things and having to set 30 minutes just to change one or two minor things. I'm working on this and trying to get better at making check lists, but still.

The desktop but surprisingly, the difference is not much. Here are the stats when compiling the sample Crestron program: pro2 cen-track demo v1_0_8.smw

Laptop: Sony Z-series, Core 2 Duo Processor running at 2.66 GHz, Hard Disk storage, windows 7 x-64

First run: 9.36
Second run: 5.88
Third run: 5.64
Forth run: 6.41

Desktop: Core i7, 860 Processor running at 2.80 GHz, SSD for boot drive but sample program residing on 1 TB WD Hard Drive

first run: 5.77
2nd run: 5.27
3rd run: 5.32
4th run: 5.22


Excellent question and reason I listed multiple runs above. The way operating systems work is that when you read a file the first time, it is fetched from storage device and given to the application. But, a copy of the data is kept in memory (assuming you have enough memory). Should any application ask for that data again, the operating system checks the in memory copy and should the data reside there, it will fetch it from that location, rather than incurring a read from the storage device. This is called "caching" and is a wonderful way of keeping a CPU from waiting on slow devices such as hard disks.

In the example of the laptop, you see a sharp speed up after the first run. The storage there is entirely hard disk and slower variety in my laptop. The first time the program is complied, there is some amount of disk reads which are cached and as such, subsequent compiles go faster.

The Desktop system has the Crestron tools and libraries all sitting on SSD. This flash memory based drive, has no mechanical parts so it is able to eliminate the costly seek time and rotational latency. Even though SSDs are fast, they are still not as fast as system DRAM. So Windows still caches their content, showing faster performance still in subsequent runs of about 10%.

Seeing how we sit there working on the same program for a while, we can ignore the first invocation and look average of subsequent compiles. There, we see the desktop handling the job at 5.3 seconds relative to notebook at about 6 seconds. The difference then is about 10% faster which ironically, is pretty close to the ratio of CPU clock speeds!

Now, this data is for this one compile. There may be differences if different programs are compiled. But we can conclude that as long as you have enough RAM to cache your program and all the associated Crestron tools/libraries (likely a few hundred megabytes), the clock frequency of the CPU dominates.

That said, what doesn't come across is that my core i7 system "feels" lightning fast. Even though the rest of the cores don't participate in running SIMPL, they do let me open up the browser, do email, etc. with incredible speed because there are spare CPU cores available to service them. More important than the cores though, is the SSD. The difference that makes in the responsiveness of the system is incredible. Imagine rebooting the system in 10 to 12 seconds. It is almost as fast as most TVs these days! :). You basically never wait on anything. I can't recommend the SSD high enough.

Unfortunately high performance SSDs are expensive but you don't need much of them. As implied above, you need enough of it to host your OS and apps and the rest can sit on large hard disks. Mine is 120 Gigabytes but with everything loaded on my machine including everything Adobe makes from Photoshop to Premier, I am at 47 Gigabytes.


Fire away with your questions. In another life, I used to develop operating systems and one of my specialties was computer performance (see a now heavily outdated book I wrote 20 years ago: [Link: amazon.com]).

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'm doubtful that a cpu test based on Simpl tells you very much about using Systembuilder. 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.


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.

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 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.

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.


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.


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.


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.

BTW, one useful exercise might be for all of us to compile the same example file and post our results plus the machine configuration used. That way, people can see if they buy a faster machine, how much better performance they can expect.

Trick would be using the same project file and have it be representative of what people do with SB. And of course, availability of that file (probably easier then to use the Crestron sample).

1 room system with a MC2W and ST-1700C. Plasma/Denon Receiver/DVD/VCR/DirecTV. I had to recreate this recently for a client whos original program was done in Application Builder years ago.

These are my computers. Both have been restarted and both have the same versions of Crestron software.

Edit: I added in the specs for the HDD and Video Card.

Apple 27" iMac
win 7 ultimate 64 Bit
Apple Spec : 2.8 Ghz Quad Core Intel Core i5
Windows Reports : Intel Core i5 CPU 750 @ 2.66 GHz
4 GB Ram
1TB Serial ATA 7200RPM Drive
ATI Radeon HD 5750 1GB


43 Seconds : For System Builder to open
13 Seconds : For example program to open
22 Seconds : Compile Time (Including Clicking thru messages)

Lenovo W500
Win Vista Pro 32 Bit
Intel Core 2 Duo CPU T9400 2.53Ghz
4 GB Ram
160GB 7200 RPM Drive
ATI Mobility Radeon HD 3650 512 MB

43 Seconds : For System Builder to open
14 Seconds : For example program to open
25 Seconds : Compile Time (Including Clicking thru messages)

Both computers have  about a 2.6 GHz cpu and both seem to be about the same speed.

I don't know of any SB sample programs, I think i'll just throw something quick together and put a link up for everyone to test.