CompuServe Thread

Erik, DeskStation's phone is 1800-793-3375 fax is 913-599-4024. Don't let the area code scare you, we're not in Topeka, but we do have some friends there. drp

Erik, For some reason your last message to me was blank. Please resend. drp

<<You could make after-hours rendering farm software that could tap the power of the dozens of PCs that sit idle every night at any large office…>> They're not idle in our "large" office. Our guys are up there working to make our MIPS systems more affordable, easier to configure with standard PC-like components and capable of running great software like Lightwave 3D. 🙂 drp

John – I think you might be missing the point a bit. (Correct me if I'm wrong Don, but…) Don's company is in the business of making MIPS based systems, not application software. They're not interested in exploiting unused Intel processing power out there. They're interested in providing HUGE performance gains that cannot be realized with ANY Intel based systems today, even SMP Pentium ones.

Thanks for straightening me out on couple of my off-handed remarks about Chicago. Yes, I agree it has many of the same features currently in NT and shares the Win32 API. Yet, Chicago does not have the security features of NT which implies that it does not share the same file system. It's hard to imagine why this is so and how it can become anything more than a desk top OS if its true. Yes it may rule the the client but NT will rule many of the high-end desk tops as well as the departmental and data center servers (NTAS). As for running Cairo, I don't know if you were at the last PDC (Professional Developer's Conference) in Anaheim last December but there were machines running Cairo: DeskStation's and a Compaq Pentium. In fact, more than 100 of the 150 or so developers in the Cairo group are runnig on MIPS systems right now. Further, the "tightly coded" Chicago is having the same battle-of-the-bulge as NT. As Daytona will decrease the memory needs of NT from 12MB to 8MB for Intel and from 16MB to 12MB for MIPS, Chicago is currently having trouble running in 8MB. AND, without ready access to "Doublespace" A.K.A. "Stacker" Chicago is going to chew up some hefty drive space as well. The closer these two are in system resource needs the better it bodes for NT . . . IMHO. As far as the "significant development efforts" of Chicago vs. NT the rumor is that Chicago borrows heavily from the former IBM/Microsoft OS/2 3.0 efforts. And, as long as Microsoft must give IBM everything it does on Chicago because of its OS/2 heritage I stand by my prediction that Cairo will spell the end of Windows as we know it.

>>>Also, the possibility to open power up for use with other rendering software (e.g. VistaPro, AdPro). From previous posts, I believe this would change the entire concept of the hardware, and also falls under the ultimate judgement of NewTek. Wishful thinking on my part….<<< Stephen, Thanks for your input. If I may suggest something that might in the long run help us all: If there's a software package, or a third-party add-in/add-on product that you really want, let us know. If you know the vendor yourself, ask them to give us a call. The more useful we can make these systems the more useful they become to you. You might even be willing to pay us a little for the added value. Wishful thinking on my part…. drp P.S. The "entire concept of the hardware" has already changed and as far as we're concerned we control our own destiny with things other than Lightwave. So, wish all you want. And let's us know what you think we should do whenever you want.

"If Newtek could do it ($) then why can't you guys? There's no middle man?" If you're talking about price, the reality is that NewTek hasn't done it. Jerry

I'd love to do it. Just like Newtek promised. In reality it cost more for the 4 processor cards inside than what the Screamer was supposed to sell at; that's before you start counting all the other stuff inside and lots of memory. We will get you there. Not right now, but just as soon as memory prices come BACK to under $30/megabyte and the processor wars really heat up. We'll pass those things through in the form of more powerful, more feature-rich system products. Tell me what you want in terms of packaging, i.e. pizza boxes, rack mountables, wheeled black boxes, stuff like that.

>>>P.S., please comment about your statement a few messages back that said something like, "MIPS…well, If that's what you want to call em…" What did you mean by that? Teach us about speed!<<< The problem with MIPS as a rating system is that it doesn't account for differences in the system architecture in which the processor is used. In order for an instruction to be executed it has to be there for the processor exactly when it needs it. Unforunately, most memory systems can't support that. In fact, few memory systems do. In microcoded CPU's like intel's many of the "instructions" are half or one-fourth the complexity of a RISC CPU instruction. (In a way, CISC instructions are less complex than RISC instructions, which makes the number of instructions for a CISC CPU greater than for a Reduced Instruction Set Computer). The operative word here is "set." RISC vendors complain about the CISC guys using MIPS as a metric because their simple instructions are not comparable to the more complex (this is really counter-intuitive) instructions of a RISC CPU. Yet, in a way, none of this is as important as the actual processor/memory architecture of the system design. If you peek inside an Indigo, you see processor modules. On these modules is the CPU, yes that's thing under the humungous heatsink, some logic ASIC's and high-speed cache memory. RISC CPU's prefer a separate instruction and data memory architecture rather than the unified secondary caches of intel-based PC's. This separation gives the processor an address space for instructions and a different address space for data. In our architecture, the secondary cache is again divided into 2 banks of "interleaved" instruction space and another 2 banks of "interleaved" data space. What is interleaved? Well, the R4000 series of MIPS processors are 64-bit devices. That means that the system address and data buses are each 64-bits wide. SO, in order to give the processor a 64-bit intruction every clock cycle you have to have the caches be 128-bits wide. This way, on one cycle the processor fetches the instruction from the first bank of 64-bit wide instruction cache and on the next cycle it fetches from the other bank. Your probably wondering why you don't just make the caches 64-bits wide and throw something at the processor on each cycle. Well, the problem with that is that in order to keep up with a processor ready to fetch its next instruction once every 50Mhz or so you would need cache RAMs with a clock to output of 10ns or less. These are very expensive. Interleaving allows you to use less expensive 17ns RAMs to effectively accomplish the same task. Its a more involved design but its far less expensive. What does this have to do with an Indigo? Well, an Indigo uses those fast RAMs in a non-interleaved cache memory scheme. Thus, Indigos cost a great deal more to build. SO you're wondering what all this mumbo-jumbo has to do with ratings based on Millions of Instructions Per Second. Think about it. If a processor is not always, always capable of fetching the next instruction when its ready, without delay, then a wait-state is inserted. A wait-state lets the processor tick a clock cycle or two while it waits for the cache memory to ready the next instruction or the data results of a previous operation. If the data ain't there the processor keeps on ticking but it isn't doing anything. In fact, no processor, even a RISC processor with infinite secondary cache, is going to execute an instruction in every clock cycle. Its just a theoretical model. Optimizing compilers help to schedule events to take advantage of each clock cycle, but even they can't do it all the time. The greatest dependencies are the speed, or interleaving of the cache memory system, the depth of that cache memory system and the scheduling optimizations of the compiler. Our architecture is fast because we do bank-interleave the cache. We also run the cache memories at twice the system clock. Further, we have studied the optimal cache sizes for the variety of things our computers do. Our first study was done doing raytracing, which in your business is much like what the Screamer was designed to do. That's why we believe our systems will make a great renderer and why we'll be able to continue to optimize our architecture for your purposes. This is not all there is on this subject. In fact, I'm no engineer. But I think this explains why MIPS is a poor metric for judging system speeds.

There's plenty of problems with that idea… it implies that you've got one central rendering engine that can perform every trick and feature that's possible in the scene, motion and geometry portions of every 3D program. There's no one 3D program that does everything that every other 3D program does… You idea about convincing 3D companies to make render engines is a much more realistic goal. 3D Studio does this already: the same executable can be run without the GUI on a network of PCs. So their "license" really covers the user interface, you are free to run any number of copies of the renderer. Similarly, Newtek could simply include a GUI-less render engine that runs on any Amiga. Or for that matter, the renderer could run on any other platform… 32-bit DOS, WinNT, Unix, SGI, etc. The Screamer render engine depends on TCP/IP 'rcp' at this point for sharing files. They could use any mechanism, really.