MOV dest = [mem] is a load. That's at least two clocks, more like 3 or 4 (assuming a hit in the TLB, and the L1 - forget it if you miss anywhere, you're talking 100's of clocks). Stores are similar (time to availability in the store queue).
It's been a while, but I seem to remember some code using CMOV (may have been Windows code generated from icc - anything targeting 686 with optimizations should be using it). It should be in any P6 derivative (that's when it first went it). It would be a lot of work just to take it out, and would break compatibility.
PAE is another matter altogether. That is seen as a server feature, so it is disabled via fuses. The hardware is still there...
I'm not sure what you are talking about... if by INC/DEC you mean every arithmetic or logical instruction (ADD,SUB,OR,AND,XOR)... they all take one clock (in execute). Shifts got hammered in P4, they should be back to 1 or 2 clocks now. Multiply, divide, floating point and SIMD instructions will take longer. I think a MUL is about 4 clocks nowadays. DIV is always longer (8-20, figure a table lookup and multiple - floating point adds time for normalize and error check). Crazy stuff like sine and cosine are, of course, longer. Simple SIMD stuff can be one clock (PADD).
That's an interesting idea. I'd like to run the numbers to see how far apart two ships would have to be to see another one edge-on (assuming fleet operations and not one-on-one)...
Airplanes have a constant flow of air to dump heat into. In space, you either need huge surface area (big radar cross section), a big internal store, or low power consumption. But you need big power consumption to move fast and do damage. An internal store will likely be needed for the times when you have to retract your heat spreaders due to enemy fire.
If you can get within 1km, you should be able to get a direct hit. That is, in space 1km is a direct hit. You're much more likely to be a lot further off than that... and your nuke impact will fall off at 1/r^2.
Simple. Take a radar stealth aircraft and fly it from the sun-ward side of the target. You don't need to have IR stealth, just use the sun to blind any sensors that are designed to detect IR.
I don't believe filtering for the sun is that difficult, amateur telescopes have filters for looking at the sun. Any object obscuring the sun should then stand out. I think you can apply the techniques used for observing sun spots...
Better yet, cool the craft to the temperature of the ambient environment and the IR signal from the craft its self becomes extremely hard to detect.
Cooling the craft will take a large amount of surface area, which will drive up the radar cross section.
Because if you can get close, you can get close with a cheaper slug (which gets your enemy equally dead). If you can't get close, missing with a nuke isn't any better than missing with a slug.
Multiple channels and overlapped memory access? The hardware does it automatically. No need to program anything different (well, I guess there is BIOS code somewhere that configures all the channels and bank information - but most people shouldn't see that).
Now, programming a 48 core FPU monster? That is a much harder problem!
That's what each channel is. I forget exactly, but each DDR channel is almost 200+ pins (RDRAM was considered a big win because it is about 80). And pins == money (mainly in die area).
Adding the rest of the core effectively gives you # of instruction pointers == # of FPU. So now, you can run more branchy code (like raytracing and physics simulations).
Slashdot Mirror
Sure. Company D is you and me.
MOV dest = [mem] is a load. That's at least two clocks, more like 3 or 4 (assuming a hit in the TLB, and the L1 - forget it if you miss anywhere, you're talking 100's of clocks). Stores are similar (time to availability in the store queue).
It's been a while, but I seem to remember some code using CMOV (may have been Windows code generated from icc - anything targeting 686 with optimizations should be using it). It should be in any P6 derivative (that's when it first went it). It would be a lot of work just to take it out, and would break compatibility.
PAE is another matter altogether. That is seen as a server feature, so it is disabled via fuses. The hardware is still there...
I'm not sure what you are talking about... if by INC/DEC you mean every arithmetic or logical instruction (ADD,SUB,OR,AND,XOR)... they all take one clock (in execute). Shifts got hammered in P4, they should be back to 1 or 2 clocks now. Multiply, divide, floating point and SIMD instructions will take longer. I think a MUL is about 4 clocks nowadays. DIV is always longer (8-20, figure a table lookup and multiple - floating point adds time for normalize and error check). Crazy stuff like sine and cosine are, of course, longer. Simple SIMD stuff can be one clock (PADD).
And, every x86 since PPro has had CMOV.
That's an interesting idea. I'd like to run the numbers to see how far apart two ships would have to be to see another one edge-on (assuming fleet operations and not one-on-one)...
Airplanes have a constant flow of air to dump heat into. In space, you either need huge surface area (big radar cross section), a big internal store, or low power consumption. But you need big power consumption to move fast and do damage. An internal store will likely be needed for the times when you have to retract your heat spreaders due to enemy fire.
Read the Project Rho stuff (and Attack Vector Tactical) Very smart guys spending a lot of time thinking things out.
The Project Rho pages are some of the best stuff I've read on the subject. Thanks for all you do!
I'm not quite sure how all the physics works out, but everything I've read says there's no stealth in hard sci-fi.
Project Rho
Rocket Punk
Weird, it's working now...
I get a page load error. Did it get slashdotted?
If you can get within 1km, you should be able to get a direct hit. That is, in space 1km is a direct hit. You're much more likely to be a lot further off than that... and your nuke impact will fall off at 1/r^2.
Simple. Take a radar stealth aircraft and fly it from the sun-ward side of the target. You don't need to have IR stealth, just use the sun to blind any sensors that are designed to detect IR.
I don't believe filtering for the sun is that difficult, amateur telescopes have filters for looking at the sun. Any object obscuring the sun should then stand out. I think you can apply the techniques used for observing sun spots...
Better yet, cool the craft to the temperature of the ambient environment and the IR signal from the craft its self becomes extremely hard to detect.
Cooling the craft will take a large amount of surface area, which will drive up the radar cross section.
That isn't going to work for stealth spacecraft which are a trivial engineering problem next to propulsion.
Please describe a stealth system that is usable in space and effective against both IR and radar.
Because if you can get close, you can get close with a cheaper slug (which gets your enemy equally dead). If you can't get close, missing with a nuke isn't any better than missing with a slug.
What is apocapses? I read that as apocalypses...
I mean 1 in 1000 or 1 in 2000 from the general population might be able to understand a functional language really well (.01 * [.1 or .05]).
Is that really the best choice for a language used in writing web pages? (Which should be available to anyone with a little technical savvy)
We shouldn't be expanding the impact of JavaScript. We should be going about replacing it.
I haven't used Haskell. How similar is it to ML?
TFA says "Technology: 65nm CMOS Process". Is that a bug in TFA?
"ARM states that the Cortex-A8 occupies up to 3 mm when fabricated in a 65 nm process." (Source).
Each dual core "tile" is 3mm^2. So only 1 per tile, or 24.
Multiple channels and overlapped memory access? The hardware does it automatically. No need to program anything different (well, I guess there is BIOS code somewhere that configures all the channels and bank information - but most people shouldn't see that).
Now, programming a 48 core FPU monster? That is a much harder problem!
That's what each channel is. I forget exactly, but each DDR channel is almost 200+ pins (RDRAM was considered a big win because it is about 80). And pins == money (mainly in die area).
You can overlap memory accesses to different banks. But the data bus will always be a chokepoint.
SDRAM uses a lot of pins. Four channels would just be too much. That's all.
In this case, 48 cores is already 2x a normal processor die area. 64 would be too much.
Each core has an FPU, so # of cores == # of FPU.
Adding the rest of the core effectively gives you # of instruction pointers == # of FPU. So now, you can run more branchy code (like raytracing and physics simulations).
All IMNSHO (I don't know JS, but I do know a lot of other languages)
How does JS compare to a good, modern language - like Python or D?
"Just like Haskell" is damning praise.
How many people can program? (well, not cargo cult scripting) - 1 in 100?
How many programmers can use a functional language like Lisp, or Haskell? - 1 in 20? 1 in 10?
No, Java is its father.
And it will bring balance to programming by killing all programmers!
Kill Java now! Before it kills us!