I think there are two reasons:
(1) The 64 bit OS gets involved in the graphics operations and draws the marching waveforms faster.
(2) The spice engine writes a *.raw file. The 64 bit OS does the write faster.
It could also be that some onrelated difference in the machines is the cause. I have not run the two OSs on the same machine.
I hope this isn't a stupid answer
-- -- kensmith@rahul.net forging knowledge
"Douglas Mota" schrieb im Newsbeitrag news: snipped-for-privacy@g49g2000cwa.googlegroups.com...
Hello Douglas,
there may be only small differences in speed between all the OS. Nobody has given any number so far in this discussion. So please be aware that we talk here about a few percent difference.
We have collected benchmark results of three smaller SPICE-circuits in the database of the LTspice-Yahoo-group.
Here the result in a few sentences.
The benchmark results are in the section "Database"
Back to the OS discussion. If you experience a great difference with a certain simulation, then the only reason for this can be the available cache memory for the programm code and the data during this simulation. Maybe this was the case when somebody thought it's faster under Linux. I can tell you it's impossible in general, because the processor runs exactly the same code, instruction by instruction, regardless of the operating system. Only the I/O is different between the OS, but this is only a small fraction of the simulation task.
My statement: There is absolutely no speed advantage to use LTspice under WINE with Linux . I am conviced that a simulation can't be faster there, when we look over many circuits in average. The good thing is from what I see is that it's not slower. So you have the choice with the OS.
Somebody in this group came up with the idea to use the processors on the graphics card for the calulations. This is useless, because you need 64bit floating point for SPICE. Otherwise a lot of circuits will not run, because of the high dynamic range and resolution required in the matrix solver.
Best regards, Helmut
If your using an AMD 64-bit processor, the memory transfer rate is !!way!! better than the old AMD Athlon CPUs and better than the newest variants of the P4. Memory handling can account for a very large difference in execution speed for some programs.
If your comparing different machines, beware that memory speed (not the sticker speed, but actual measured memory transfer rates), size of RAM, sustained hard drive writing speed, and background tasks (like virus scanners) can have significant effects on program execution time. Even BIOS version will affect memory transfer rates as seen on my Tyan K8W motherboard. When comparing program execution times, you need to benchmark various things, and then find out which component(s) affect the execution time. It is not enough to say that the processor or OS made up for all the time difference.
When comparing processors, you need to normalize the clock rate to some number, like 1 GHz. Then you can see the relative efficiency of the processes. AMD marketing came up with totally lame numbering system that was designed to mislead the public. Use the actual clock freq, not AMD's whacked out number scheme.
Interesting things I have found out about running a moderately complex PSpice simulation on different machines:
1) AMD Athlon solved twice (assuming same CPU clock freq) as fast as the old P4s, about 1.7x faster than the newer P4s. The PIII ran about 1.3x faster than the old P4.2) AMD Athlon and Opteron are very close in execution time on Windoze
2000.3) Memory speed had very little effect on execution speed on the PSpice sim we were using.
4) Hard drive speed had a noticeable effect since a large data file is written out.My colleague benchmarked some Xilinx development tools and found that things ran almost twice as fast on the Opteron system than his old Athlon system, both using Win2k. This was mainly attributed to memory speed. The Athlon memory transfer rates were less than half the rated speed of the memory due to their really funky north bridge chip.
-- Mark
In article , qrk wrote: [...]
I don't have any viruses to scan for but on a Windows machine I have seen virsus software slow disk IO way down.
How about I normalize to 3.3GHz? Then I don't have to do any math to compare the 2 machines.
[ observations on PSpice ..]Since spice tends to take a lot of floating point operations, it is the speed of that part that matters so these sound reasonable.
That surprises me a little.
If the floating point operations take multiple machine cycles this is reasonable.
Yes and the type of disk structure also matters too I'll bet.
-- -- kensmith@rahul.net forging knowledge
Hi Helmut, -"...you need 64bit floating point for SPICE..." Is it true even for 32bit Spice versions? Are there 64bit Spice versions? -"...a lot of circuits will not run, because of the high dynamic range and resolution required in the matrix solver...." Since I don't know nothing about this subject, there's my question: so the processor on the graphics card does't have this required processing power? Only the PC's CPU has it?
I'd really like to study and understand in depth the way Spice works, including to learn enough to be able to modify the source code of some of its modules. Could you please suggest me some material? It also could be some web links and/or key words for searching in Google.
Thanks a lot!
In article , Douglas Mota wrote: [....]
Beware that there are different meanings to the term "64 bit".
Most modern CPUs have a "bus width" that is commonly being refered to when people say "16 bit", "32 bit" or "64 bit" when refering to a CPU chip. The "bus width" in the number of bits the CPU can transfer in one action. Basically, it is the number of wires going from point A to point B.
Like it is posible to do multidigit math "long hand" on paper, a CPU can process numbers larger than the "bus width". You can do 64 bit math in a
8 bit processor this way. It won't be as fast but the results will be exactly the same when it is done.The x86 processors have a special section for dealing with the "floating point" numbers. This section looks like it has an internal "bus width" of
80 bits. It may not really be 80 bits, since internally it could do two 40 bit transfers to get 80 bits from here to there.While the numbers remain inside the "floating point unit" they remain in the 80 bit form. When they are stored, they are rounded off to 32 or 64 bits as required.
You may have hit on something here. Just for purposes of discussion: Assume that the graphics card only does 16 bit operations. Also, lets assume that it does these operations at a 700GHz rate. Such a processor would be able to outpace a 3.3GHz Pentium when doing 64 bit math. Obviously, I just made up the 16bit at 700GHz values.
You can find the source code for some of the older versions of spice on the web. The highly tweeked stuff that various companies provide is not available. I assume by "modify the source code" you mean "modify the source code in a useful way". To get to ths point the quickest, I suggest you pick one part of the processing such as ".op" and dig into it in detail.
Spice 3f4 source
-- -- kensmith@rahul.net forging knowledge
Douglas Mota wrote: : I'd really like to study and understand in depth the way Spice works, : including to learn enough to be able to modify the source code of some : of its modules. Could you please suggest me some material? It also : could be some web links and/or key words for searching in Google.
Here's the premier open-source SPICE. Linux native, with Mac and Widows ports. Incorporates XSpice and Cider. Bugs which are present in older SPICEs floating around the web are absent in ngspice since it has been worked on continuously for several years.
Happy hacking!
Stuart
"Douglas Mota" schrieb im Newsbeitrag news: snipped-for-privacy@f14g2000cwb.googlegroups.com...
Hello Douglas,
This 64bit floating point math has nothing to do with the operating system. It only menas that you use 64bits of memory for each variable or constant. The calculations have to be also accurate for 64bit of course. It's simply the type (double) in most programming languages.
I have never tried to do that. For me it's enough that Mike works in this area. :) Insiders will know of whom I speak.
Best regards, Helmut
Stuart Brorson wrote: : Douglas Mota wrote: : : I'd really like to study and understand in depth the way Spice works, : : including to learn enough to be able to modify the source code of some : : of its modules. Could you please suggest me some material? It also : : could be some web links and/or key words for searching in Google.
: Here's the premier open-source SPICE. Linux native, with Mac and : Widows ports. Incorporates XSpice and Cider. Bugs which are present : in older SPICEs floating around the web are absent in ngspice since it : has been worked on continuously for several years.
:
Also, if you are interested in analog circuit simulation in general, you could take a look at Gnucap. Gnucap is a reasonably complete open-source analog simulator which is a little more sophistocated than SPICE. The code is also a lot cleaner, and so may be easier to understand. Again, it's open source, so you can see and explore the internals.
Here's the URL:
Rather than the 0.34 release, grab the latest snapshot available under "development releases".
HTH,
Stuart
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.