Is this Intel i7 machine good for LTSpice?

If I understood that article correctly, they are discussing the relative performance of the SIMD (vector processing) instruction performance between vendors.

Unless your application (e.g. LTSpice) has been compiled with a good compiler to use those SIMD extension instructions that article might not be of much use.

At one time several years ago AMD had indeed a better non vectored FP performance compared to Intel, but this situation changes with each generation of chips.

The same is true for floating point performance. I recall when the 486 came out with built in floating point acceleration many benchmarks didn't show an appreciable speed up on apps like spread sheets because most of the program time was spent doing things other than the floating point calculations. I believe most programs fit this category as well, with the programs where enhanced floating point performance making a real difference being in the small minority.

I haven't looked at the stock in a while, so I don't know how much money they are losing, but I really can't see AMD being in business in 5 to 10 years if they don't find the next new thing to give them an opportunity to make a little profit. Intel is sitting on their pile of cash at the high end and all the various ARM makers are cutting the profit out of the bottom end. AMD sure as heck isn't going to be able to make money in CPUs.

Looking at their profit for the last few years they have been loosing money pretty hard in 2012 and less so in 2013. 2014 is showing a small loss to date. I guess if they can keep bleeding slowly enough they can hold on for a while.

Does AMD have anything worthwhile in the pipeline?

ECC *has* to be slower. It involves calculating check bits from the word being stored and saving them. Then on the read all the bits are calculated to see if there is an error and to correct it. That takes some time on both the write and the read. It may not be a lot, but it takes time.

Lol, I have killfiled the person you are responding to, but I can tell your response is appropriate...

On Tue, 11 Nov 2014 20:21:22 -0500, rickman Gave us:

It is hard calculated as the array is filled. It takes no additional time, and no code is involved at the OS level. The access speed for THAT RAM is exactly that. All overhead already considered. What you can and or do run it at is what it runs at.

There is no, "this non-ECC such and such MHz RAM is faster than this same speed rated ECC RAM because it has ECC delays".

Nope. Yer makin' s*it up... again.

What you believe is false, mostly that is.

You should really do your home work before posting here.

Back in the 486 days, the majority of software that was being used didn't support the FPU because it didn't exist on many PC's. Then you had the option in the math libs to have it detect the presents of a FPU and the lib would then call the FPU instructions. A lot of DOS based programs also did this trick.

This detouring didn't help with the speed performance but it did show a faster operating program when ever there was floating point math involved.

It was only later when the Pentium's came along is when new software and updates demanded that you have FPU support, because there was no longer support for software FP, with the exception of some custom forms of floating point that can only be supported in software.

Of course the first Pentium's had the problem of a bug in the FPU due to some missing silicon. I wrote a command line app just to test for that bug and found many PC's that had those CPU's in it.

I am sure you knew all of this, correct?

Yeah sure.

Jamie

On Tue, 11 Nov 2014 21:41:53 -0500, "Maynard A. Philbrook Jr." Gave us:

You mean the 386 days. The 486 had it integrated in.

Software authors were most definitely writing to use it. Titles out at the time lacked, but that did not last long at all.

ECC,

do a

ould

It doesn't have to be significantly slower. The processes of creating the c heck bits, and of using them to calculate a corrected output can in princip le be handled by look-up tables - which get a bit big - and in practice are handled by logic networks which are almost as fast.

The process of getting stuff out of memory is slower, because memory cells have to be tiny, so the electric charge involved is equally tiny.

The last time I looked - which was a very long time ago - the costs were in extra components, extra board area, extra pins, extra bus tracks and extra bus drivers. Extra propagation delay didn't really come into it.

The actual data bits can be stored as they arrive, calculating the check bits take some time, but they can be written into memory cells which will occur slightly later. With multiple write cycles in succession, storing the check bits from the previous write can overlap with writing the actual data bits of the next write.

Doing a partial memory word update, e.g. writing only a single byte into a 64 bit (8 byte) memory word is costly, since first you have to read the 7 unmodified bytes, combine the new byte, calculate the ECC for 8 bytes and write 8 bytes+ECC or at least the new byte+full ECC. With cache between the processor and main memory, memory writes should use the full memory words, so this is not be an issue today.

These days the read returns correct results in a huge majority of cases, so why not just send out the speculative data and after ECC check declare it valid by a separate signal from memory to CPU. However, if the ECC check fails, the memory needs to calculate the correct data and indicate that the data word is now valid. Then the memory must calculate the new correct data+ECC and store it into that memory cell to deal with soft errors (i.e. flush the memory cell). Of course, if there is a hard error, this does not help, since the correction must be repeated on each read access to that cell, slowing it up considerably.

With hard errors in some memory pages, this can be a considerable delay and the OS should be able to map out these bad pages as in disk drive bad block replacement.

No, only some of them did.

That isn't true though. Most software that was aiming for any kind of serious performance and needed floating point had two versions one linked with an emulator and another linked with inline code.

Disabled (possibly NBG) in the SX models.

Full spec i486 mostly had the FPU on chip as standard.

On 12 Nov 2014 10:06:12 GMT, Jasen Betts Gave us:

No. They ALL did. They were ALL made as "DXs" and those that failed production testing ended up becoming a "new line" (the SX) if that was the only thing not working. It was a way to recover die losses, which were high at the time.

Den onsdag den 12. november 2014 18.01.49 UTC+1 skrev DecadentLinuxUserNumeroUno:

afaiu they started that way but eventually they made a new die without the FPU

-Lasse

only the DX versions.. you seem to forgot the SXes

Jamie

On Wed, 12 Nov 2014 17:49:12 -0500, "Maynard A. Philbrook Jr." Gave us:

The SX started out as FAILED DXs.

Very late in life, they actually fabbed them deliberately.

Failed Die tested FPUs which had fully working x86 units otherwise are what started it, and there was no reason for a dedicated artwork, because the failures were now being used, and THAT was a direct profit increase, and loss reduction.

YOU failed to read.

No, you failed at trying to twist it around in your favor.

Not only that, you are simply now commenting from what others have already said, before you. It does not matter if they were failed or intentional. The fact remains that a large amount of software did not force the use of a FPU, some of it didn't even attempt to detour in software if there was one present. Years ago I wrote a sat tracking program that optionally would switch to the FPU if one was present, there was a speed up but it wasn't what I called worth a fist full of money to get a CPU or add on FPU for it.

Jamie

On Wed, 12 Nov 2014 19:29:41 -0500, "Maynard A. Philbrook Jr." Gave us:

No. The first 486 fabs ALL had it, and the off-the-die failure rates were so high that they were talking about what sort of loss that represents. Then the engineering folks noted that the main body of failures were just the FPU core, and that the units could be released as a non-FPU included device, because the rest all worked.

A huge saving was realized. They eventually DID make an actual SX fab line, but that was NOT the initial plan.

The initial plan was the selling boost that an integrated FPU core meant to everyone, even the real estate frugal MOBO makers. They were never going to look back.

I failed at nothing. Go READ it. It is the same as what I say here. So what did I twist?

Lol, I find it amusing that you think a lookup table is faster than logic. A lookup table is a bunch of logic for doing the operation with a fixed pattern of bits. Doing the same operation in discreet logic is almost certainly faster and almost certainly much smaller.

I don't know how you define "significantly slower". So I can't argue that point.

I did some searching and found a review of several benchmarks on memory performance that found a small difference. The wikipedia page says there is a speed penalty because of the additional logic, but that most modern ECC has the controller in the CPU chip which at best hides the delay. So depending on how you define "significantly slower", you can say you are right.

I guess the last time I checked was longer ago. I worked on an array processor with ECC memory controller in a separate chip. The ECC happened in it's own clock cycle and so did not affect the clock frequency, but that added latency to the memory access. However this was a micro programmed machine so the algorithm anticipated all the various delays to get the right data in the right place at the right time. The ECC delay was incorporated into the operation of the machine.

FP

floating

well,

The 386/486 DX parts had internal core clock speed doublers. Later even higher multipliers. The 386SX had a 16-bit data bus width.

Wow. The way i remember things going it that the 486 added the MMU (and caches) first. Bringing the FPU onboard came later, maybe with the Pentiums.

I remember the FDIV bug rather well.