The problem is what you discussed has NOTHING todo with privacy.
You expect privacy... when you're being private, that is to yourself. When you are in the middle of a public mall or visiting my website you are no longer treading "in private" and therefore have zero expectation to privacy.
It's like bitching that falling in a pool makes you wet. If you don't like being wet stay out of the pool. If your privacy is so important to you then don't mingle in society.
That's what we ended up doing [collaborating to spread cost].
As to why I don't read the book more? Because it's useless generalizations about the software engineering process. This PhD has his head so far up his ass that the entire book is modeled after writing closed source software [e.g. how to manage small teams, not work in the bizarre style].
The book also alludes to many things that it doesn't actually cover in any meaningful detail [like it mentions state diagrams but doesn't describe any of the symbols. It gives two examples of the same process, etc...].
Essentially the book was a "make money" project for some PhD [who can't pronounce "component" btw]. I imagine other students have similar experiences with their textbooks.
In fact the best textbooks I've bought were not part of the syllabus. I bought them because I heard good things and they're actually worth the read.
This isn't always the case. In fact my software eng. class used a book that specifically was hard to find [e.g. not available on amazon, etc]. It was listed as 80$ [out of stock] on all the sites we found....
Our school sold the book for 140$...
And like many posters.... we read maybe 10 pages of the book [that is... details required for our analysis project].
I'll reply to your comment [and hopefully the others will see].
"RISC internally, CISC externally" is the jist of what most people said.
Well mr. autopr0n where do you think the energy to convert from CISC to RISC comes from? Take the Athlon.
ADD EAX,EBX
Actually takes at least 11 cycles in a pipeline that involves 8 cycles of scaning/aligning/decoding.
The only saving grace is that they can do quite a few at once.
The true innovation over the past years has really only been the Transmeta cores. They consume a tenth of what the amd/intel series requires yet still deliver enough performance to be very useful.
Blah blah blah, 64-bit processor....billions of GB of ram....
The real question is have they finally dumped the stupid x86 instruction set in favour of a space/energy/coding efficient RISC set?
I mean yeah it sucks to change ISA but this is what you do. Write a *free* backend to GCC for your ISA and have it merged into the tree. Then pay small group of Gentoo folk to create a port of Gentoo to your ISA.
Net result is a ISA everyone can develop for [re: audience] as well as an OS they can run on it...
Sure it would take time and money but in the end you don't make a bloatware cpu to run the hugeass x86 instructions with all the tacked on do-dahs...
If you already have Office before the XML craze [holy shit, a text file with labels, shit this is like fucking new!!!! fuck text files!!!!] then use it.
Otherwise if you are new to the desktop scene just skip MS Office and use OO.
Fuck, OO is like 1/8th the size, free, portable, etc...
There really is no reason whatsoever to use Office. It's a bloat piece of shitty software.
Trial factoring amounts to starting from the square root and trial factors from there. Which grows into the fermat sieve [requires fewer hard ops but takes the same asymtotic time] then into -rho methods then into quadratic sieves and then into field sieves...
However, as nice and cool as all that shit is none of it accounts for a proof of how hard factoring is. It is quite possible that tommorow a trivial algorithm for factoring is found that renders all IFP systems insecure. It's not likely to happen but it is certainly not impossible and in fact more likely to happen as time goes on.
"The question @ the end of my original post wasn't a sig. Really: how come a puter can multiple two 400 digit #s in seconds, but takes forever to factor them?"
If you knew the answer to that you'd be world famous.
Well obviously you see no problems with RFID. You don't know about their destructive powers. RFID tags for instance can read your brains alpha waves. Control your thoughts and worse yet heard clusters of similarly stupid soccer moms and should-have-died-already-block-the-aisle-and-walk- too-slowly-elderly to one place.
RFID tags have also been known to subvert democracy. For instance, they put RFID tags on all ballots and track who voted for who. Next time you get a knock on a door from a representive you didn't vote for, now you know why.
They're also going to be putting miniature RFID tags in apples and oranges. The idea is that they hope people won't notice and then they can track people as they enter or leave public buildings.
It's actually all part of Bushes "Tough Stance On Terrorism" policy.
Perhaps but 3dnow instructions are mostly directpath. They won't stall all three decoders. So while SSE lets you process twice as much data it incurs at least two additional cycles of penalties (the manual states it can be upto 4 cycles!!!).
The trick would be to mix the appropriate amount of ALU code [e.g. pointer updates, counters, whatnot] between 3dnow instructions.
Both SSE and 3DNOW use formats the normal FPU can read so I'd say it's standard [hint: you can assign an array of two well aligned floats to a 3dnow 64-bit word and use it].
SSE supports both double/float precision [as another poster pointed out]. Heck even the Athlon supports SSE [though I wouldn't use it. Hint: SSE reg == 128-bits and the Athlon CPU can only perform upto 64-bits of read per cycle...]
Yup. E.g. splitting movps -> movlps+movhps does indeed make a performace gain."
I meant VectorPath instructions like DIV, LGDT, etc...;-)
They stall all three decoders. As for alignment the trick is to pack as many instructions into 8-byte aligned windows. According to the manual it fetches 24-byte windows and performs one [or two I forget... PDF is so far away] of scan/early decoding.
So the trick is to organize your code so that each 8-byte segment has as many directpath instructions in it. That will minimize the decode latency [depending on the instructions may minimize issue/execute latency].
The problem though is most ALU opcodes are at least two bytes [except for things like INC/DEC] and worse yet things like
It isn't just branches though. For example, a 32x32=>64 multiplication on the P4 can take upto 14 cycles [iirc] whereas on the Athlon it's 6-cycles. So for example,
MUL EAX,EBX [DIMMMM] ADD ECX,EAX [_D___IE]
So in total takes seven cycles.
The same code on the P4 would take at least 15 cycles. What's worse is consider
MUL EAX,EBX [DIMMMM_] ADD ECX,EBX [_DIE___] INC ESI [_DIE___] DEC EBP [__DIE__] ADD EBX,EDX [__D__IE]
Again this takes seven cycles. Specially since instruction 1 and 2 can go start in cycle two in pipes 1/2.
Compare that to the P4 which only has two ALU pipes [one of which is now stalled for 14 cycles for the MUL to finish].
More specifically the Athlon has three ALU/IEU pipeline pairs, 1 FADD, 1 FMUL and 1 FLOAD pipeline [e.g. you can't do 3 FP muls at once].
The decoder can send upto three instructions into the pipeline per cycle. Actually that's only for directpath instructions [e.g. simple ALU/FP]. Vector instructions stall all three decoders.
The ALU scheduler is fairly strong but it does have several weaknesses. from the manual I can't see that it can resolve dependencies from other pipelines. For instance,
D == decode, I == issue, E == execute [pp.. 227 of the athlon opt manual].
So the fourth instruction will always start on the second cycle despite the fact that ALU1/2 are blocked.
Similarly the Athlon memory ports are a bit weak. There are read/write buffers but you still can only issue two reads or one write per cycle which is annoying.
However, the strength of the Athlon ALU over the P4 ALU is that for the most part it can keep all three pipelines busy even if they are blocked at some stage [e.g. it can decode/issue even if blocked]. It doesn't say in the documentation but I could swear the Athlon can cross-pipe things too. Cuz sometimes I can mess the order of ops [e.g. create a dependecy] and it executes in the same time regardless.
Anyways, yeah it's all about the 3 ALUs and a decent scheduler. Something the P4 does not have.
On what processor? An athlon has a 6-cycle multiplier so I whole heartedly doubt you could beat an optimized Comba multipler for 2048-bit numbers [specially written in assembler].
Maybe on a processor without a multiplier the FFT can beat a straight multiplier for such sizes.
Note that I don't doubt Karatsuba can beat a straight method for sizes 2048 bits (my C bignum code has Karatsuba kicking in for 3000 bit numbers and it's all portable C).
Slashdot Mirror
The problem is what you discussed has NOTHING todo with privacy.
You expect privacy... when you're being private, that is to yourself. When you are in the middle of a public mall or visiting my website you are no longer treading "in private" and therefore have zero expectation to privacy.
It's like bitching that falling in a pool makes you wet. If you don't like being wet stay out of the pool. If your privacy is so important to you then don't mingle in society.
Tom
not really. I meant "bizarre style OSS is developed" as in "not obviously profitable".
Tom
That's what we ended up doing [collaborating to spread cost].
As to why I don't read the book more? Because it's useless generalizations about the software engineering process. This PhD has his head so far up his ass that the entire book is modeled after writing closed source software [e.g. how to manage small teams, not work in the bizarre style].
The book also alludes to many things that it doesn't actually cover in any meaningful detail [like it mentions state diagrams but doesn't describe any of the symbols. It gives two examples of the same process, etc...].
Essentially the book was a "make money" project for some PhD [who can't pronounce "component" btw]. I imagine other students have similar experiences with their textbooks.
In fact the best textbooks I've bought were not part of the syllabus. I bought them because I heard good things and they're actually worth the read.
Tom
This isn't always the case. In fact my software eng. class used a book that specifically was hard to find [e.g. not available on amazon, etc]. It was listed as 80$ [out of stock] on all the sites we found....
Our school sold the book for 140$...
And like many posters.... we read maybe 10 pages of the book [that is... details required for our analysis project].
Tom
I'll reply to your comment [and hopefully the others will see].
"RISC internally, CISC externally" is the jist of what most people said.
Well mr. autopr0n where do you think the energy to convert from CISC to RISC comes from? Take the Athlon.
ADD EAX,EBX
Actually takes at least 11 cycles in a pipeline that involves 8 cycles of scaning/aligning/decoding.
The only saving grace is that they can do quite a few at once.
The true innovation over the past years has really only been the Transmeta cores. They consume a tenth of what the amd/intel series requires yet still deliver enough performance to be very useful.
Tom
Same bullshit...different company..
Blah blah blah, 64-bit processor....billions of GB of ram....
The real question is have they finally dumped the stupid x86 instruction set in favour of a space/energy/coding efficient RISC set?
I mean yeah it sucks to change ISA but this is what you do. Write a *free* backend to GCC for your ISA and have it merged into the tree. Then pay small group of Gentoo folk to create a port of Gentoo to your ISA.
Net result is a ISA everyone can develop for [re: audience] as well as an OS they can run on it...
Sure it would take time and money but in the end you don't make a bloatware cpu to run the hugeass x86 instructions with all the tacked on do-dahs...
Tom
And low in carbs too. I call it the Atkins Article or A.A. for short.
Tom
Did I see a toronto in there? Heheheheehe...
Tom
Meh use tar/bzip2. That gets better compression than 7zip.
Just stop sending them?
Ok, how about all you potential spammers send $6 to my home address:
123 Fake St.
Springfield, Il
12345
United States of America
and U will $ee many monies! No need to spam again!
Sincerely,
Prince Mobutu of the Nigerian Empire.
Because those RFCs are fucking off-topic redundant crap pieces of shit written by stupid liberal motherfuckers like you?
Tom
Most likely it's not a protocol that involves a lot of ACK'ing [e.g. huge packets with FECs]
Tom
If you already have Office before the XML craze [holy shit, a text file with labels, shit this is like fucking new!!!! fuck text files!!!!] then use it.
Otherwise if you are new to the desktop scene just skip MS Office and use OO.
Fuck, OO is like 1/8th the size, free, portable, etc...
There really is no reason whatsoever to use Office. It's a bloat piece of shitty software.
Oh and babbabooey babbabooey howard stern rocks!
Tom
yeah and you fail at the internet.
Take that.
That makes no sense whatsoever.
Trial factoring amounts to starting from the square root and trial factors from there. Which grows into the fermat sieve [requires fewer hard ops but takes the same asymtotic time] then into -rho methods then into quadratic sieves and then into field sieves...
However, as nice and cool as all that shit is none of it accounts for a proof of how hard factoring is. It is quite possible that tommorow a trivial algorithm for factoring is found that renders all IFP systems insecure. It's not likely to happen but it is certainly not impossible and in fact more likely to happen as time goes on.
Tom
"The question @ the end of my original post wasn't a sig. Really: how come a puter can multiple two 400 digit #s in seconds, but takes forever to factor them?"
If you knew the answer to that you'd be world famous.
Tom
Well obviously you see no problems with RFID. You don't know about their destructive powers. RFID tags for instance can read your brains alpha waves. Control your thoughts and worse yet heard clusters of similarly stupid soccer moms and should-have-died-already-block-the-aisle-and-walk- too-slowly-elderly to one place.
RFID tags have also been known to subvert democracy. For instance, they put RFID tags on all ballots and track who voted for who. Next time you get a knock on a door from a representive you didn't vote for, now you know why.
They're also going to be putting miniature RFID tags in apples and oranges. The idea is that they hope people won't notice and then they can track people as they enter or leave public buildings.
It's actually all part of Bushes "Tough Stance On Terrorism" policy.
Tom
Perhaps but 3dnow instructions are mostly directpath. They won't stall all three decoders. So while SSE lets you process twice as much data it incurs at least two additional cycles of penalties (the manual states it can be upto 4 cycles!!!).
The trick would be to mix the appropriate amount of ALU code [e.g. pointer updates, counters, whatnot] between 3dnow instructions.
Tom
MMX doesn't do FP [it's int only].
Both SSE and 3DNOW use formats the normal FPU can read so I'd say it's standard [hint: you can assign an array of two well aligned floats to a 3dnow 64-bit word and use it].
SSE supports both double/float precision [as another poster pointed out]. Heck even the Athlon supports SSE [though I wouldn't use it. Hint: SSE reg == 128-bits and the Athlon CPU can only perform upto 64-bits of read per cycle...]
Tom
"Vector instructions stall all three decoders.
;-)
;-)]
Yup. E.g. splitting movps -> movlps+movhps does indeed make a performace gain."
I meant VectorPath instructions like DIV, LGDT, etc...
They stall all three decoders. As for alignment the trick is to pack as many instructions into 8-byte aligned windows. According to the manual it fetches 24-byte windows and performs one [or two I forget... PDF is so far away] of scan/early decoding.
So the trick is to organize your code so that each 8-byte segment has as many directpath instructions in it. That will minimize the decode latency [depending on the instructions may minimize issue/execute latency].
The problem though is most ALU opcodes are at least two bytes [except for things like INC/DEC] and worse yet things like
00000000 89D8 mov eax,ebx
00000002 8B00 mov eax,[eax]
00000004 8B0418 mov eax,[eax+ebx]
00000007 A100040000 mov eax,[0x400]
0000000C 8B8000040000 mov eax,[eax+0x400]
So really offsets/constants are horrible [the last two instructions are 5 and 6 bytes each].
If you have to step through arrays I think the idea would be to use the middle, e.g.
00000012 03040B add eax,[ebx+ecx]
00000015 81C100040000 add ecx,0x400
0000001B 03040B add eax,[ebx+ecx]
0000001E 81C100040000 add ecx,0x400
Which takes 18 bytes. [four windows]. Another trick is to use a register for the step size...
00000024 BA00040000 mov edx,0x400
00000029 03040B add eax,[ebx+ecx]
0000002C 01D1 add ecx,edx
0000002E 03040B add eax,[ebx+ecx]
00000031 01D1 add ecx,edx
[16 bytes, 3 windows, ignore stalls....
Tom
My second example is slightly off. It would be
MUL EAX,EBX [DIMMMM__]
ADD ECX,EBX [_DIE____]
INC ESI [_DIE____]
DEC EBP [____DIE_]
ADD EBX,EDX [____D_IE]
[use a fixed-width font to read that...] for eight cycles not seven.
[Where D = decode, I = issue, E = execute]
Tom
It isn't just branches though. For example, a 32x32=>64 multiplication on the P4 can take upto 14 cycles [iirc] whereas on the Athlon it's 6-cycles. So for example,
MUL EAX,EBX [DIMMMM]
ADD ECX,EAX [_D___IE]
So in total takes seven cycles.
The same code on the P4 would take at least 15 cycles. What's worse is consider
MUL EAX,EBX [DIMMMM_]
ADD ECX,EBX [_DIE___]
INC ESI [_DIE___]
DEC EBP [__DIE__]
ADD EBX,EDX [__D__IE]
Again this takes seven cycles. Specially since instruction 1 and 2 can go start in cycle two in pipes 1/2.
Compare that to the P4 which only has two ALU pipes [one of which is now stalled for 14 cycles for the MUL to finish].
Tom
More specifically the Athlon has three ALU/IEU pipeline pairs, 1 FADD, 1 FMUL and 1 FLOAD pipeline [e.g. you can't do 3 FP muls at once].
The decoder can send upto three instructions into the pipeline per cycle. Actually that's only for directpath instructions [e.g. simple ALU/FP]. Vector instructions stall all three decoders.
The ALU scheduler is fairly strong but it does have several weaknesses. from the manual I can't see that it can resolve dependencies from other pipelines. For instance,
ADD EAX,EBX [DIE ]
ADD EBX,EAX [D IE ]
ADD ECX,EBX [D IE] - critical path
INC ESI [ DIE ]
D == decode, I == issue, E == execute [pp.. 227 of the athlon opt manual].
So the fourth instruction will always start on the second cycle despite the fact that ALU1/2 are blocked.
Similarly the Athlon memory ports are a bit weak. There are read/write buffers but you still can only issue two reads or one write per cycle which is annoying.
However, the strength of the Athlon ALU over the P4 ALU is that for the most part it can keep all three pipelines busy even if they are blocked at some stage [e.g. it can decode/issue even if blocked]. It doesn't say in the documentation but I could swear the Athlon can cross-pipe things too. Cuz sometimes I can mess the order of ops [e.g. create a dependecy] and it executes in the same time regardless.
Anyways, yeah it's all about the 3 ALUs and a decent scheduler. Something the P4 does not have.
Tom
I'll have to take your word for it. I still don't think on a decent platform with a fast multiplier that the FFT could win at such a small size.
Tom
On what processor? An athlon has a 6-cycle multiplier so I whole heartedly doubt you could beat an optimized Comba multipler for 2048-bit numbers [specially written in assembler].
Maybe on a processor without a multiplier the FFT can beat a straight multiplier for such sizes.
Note that I don't doubt Karatsuba can beat a straight method for sizes 2048 bits (my C bignum code has Karatsuba kicking in for 3000 bit numbers and it's all portable C).
Tom