Marketing, producing products your users want do matter. Part of that is convincing your users they want to do that... There's a much more fundamental thing going on here. It's the same force that killed the dominance of the Mainframe, and the Mini.
Machines are fast enough now to do everything most consumers want to do with them.
Let's extrapolate what that really means: 1) Surf the web - Fine on 5 year old hardware (Even with stuff like Flash) 2) Watch video - Fine on a 5 year old box 3) Write something - Fine on a 5 year old box 4) Compute something - For most users fine on a 5 year old box.
Do you see the pattern here? The average user can do everything they want to do. Which gets to the crux of it. The real problem is that their isn't some new killer application that causes such a stir most users want to upgrade. The same thing happened to the mainframe and the mini. Once mini's were fast enough people used them to do many things (not all things) mainframes did. When the killer micros were fast enough users used them to do many things that mini's did.
What's going on is that we lived through a period where there were tangible benefits in upgrading. The truth as much as some might argue about it is that users bought into needing multitasking, they could see that editing some document or image (or video) was tangibly better on a faster machine.
What did that? Think about the mid 80's to 90's and even early 00's. There was the GUI. 90's we had the Web. Do you remember how insanely saturated EVERYTHING was with the web? It was www this and www that and web this and web that. In the 00's there was video. Hey you can watch video on your machine over broadband.
The machine running Windows 95 really was better for surfing the web than their WFWG 3.11 machine. The windows XP really was more reliable than the Windows 98 machine if you wanted to install random crap.
What's happened is that there's no real new apps that the average consumer cares about.
Now, if someone comes out with a killer app that needs a machine of PC levels of capability and piles of consumers are convinced they need it then the PC will take off. Microsoft has made Windows 8 look like a tablet OS to the average consumer, who based on sales figures is not convinced at all that they really want a tablet OS on their PC.
The PC won't die, just like the Mainframe didn't die and yes we still run piles of Mini's (Servers). It's just that your PC may be the size of a raspberry pi. For some people it will be the size of a regular PC or Laptop. Guess what - if you have to stick a decent sized screen on it and a keyboard it's going to be at least some size. That's until you either wear VR style glasses (No need for a big screen) and don't have motion estimation stuff so good and cheap you can just waggle your fingers in the air like you are typing on a virtual keyboard.
Win 8 so bad you're going Linux with Win in a VM?
on
Windows 8 Killing PC Sales
·
· Score: 4, Interesting
I haven't run Win 8 and lots of folksI know haven't either. We aren't MS haters - we're pragmatists and pretty much comprise a group of users who have used every MS OS (OK Nobody ran ME) since DOS. If a company can produce a product so crappy that it does that it really makes you wonder what the hell is wrong with management.
The $64000 question is what does MS do now? The best I can think of is make the Win 8 'Aqua' style interface better - hell throw the Windows 7 UI in there. That way they could keep working on the tile based stuff but not alienate everyone.
Unfortunately they've pretty much managed to alienate a huge number of users.
I use Linux entirely for work, and Win 7 on my machines at home when I'm not running Linux. I'm thinking about a new laptop for home but don't want Windows 8. I think I'm actually going to just do Linux on that laptop now steam is available for Linux. If I need Windows I'll run it in a VM. I'm curious who else has come to the same conclusion. Windows in a VM and Linux as your main OS because Win 8 seems so crappy.
I agree... and the interplay of Avon with the other Characters made that show. He was the bastard who is right most often, and the only one who could be talk to ORAC sanely..
> Isn't the floor written on that big board near the elevator?
Oh ah, well I suppose it could have been
> So how did you get here?
I just walked up the stairs and stopped on each floor to see if I saw the company name
> But we are on the 32nd floor?
Yes, it did seem to take a while, especially the knocking
> The knocking?
Well, yes, some of the doors were locked, so I had to knock to ask someone if this was 'AX7121 Systems'
> But, didn't it occur to you when they said NO, to ask them if they knew which floor AX7121 Systems was on?
Ah, yes I did, that caused me to go back down to the 7th floor three times.
>What?
I went back down to the 7th floor three times
>What?
Well someone said you were on the 7th floor, in total I went to the 7th floor 4 times, the 9th floor 3 times, and the 13th floor twice
>But if you had checked the 7th floor on the way up didn't it occur to you that we probably couldn't suddenly move in and appear there so you didn't need to recheck it?
Uh, well now you mention it, but I wanted to use a SAFE algorithm
> Hang on a minute I read your resume, you said you have a 4 year degree in computer science
Yes, I do, I graduated from #blah blah# last summer
> Did you guys ever cover elevator seeking problems?
Oh yes, we did - lots of work on that, it's related to reflection in Java, I know all about that!
> How is it related to reflection in Java?
I could reflect from my Elevator instance to find out what kind of elevator it is, and then I could call the.goToFloor method with a flor
> How would that have helped?
Well, I could have ridden the elevator instead of using the stairs, which would have sped things up lots and made the algorithm more efficient
> Are you joking?
Why would you ask that? It would definitely speed up the algorithm a little bit don't you think?
> I have a terrible pain in the side of my head, by the way, what is your name?
I apologize to the 'recent' fans, I really *really* wanted to like the 'new' episodes but they sucked. Horribly. I mean terrible horrible waste of all that ILM CPU cycles on digital effects and acting crap.
The reboot of Star Trek was awesome even die-hard trekkies I know who hated it on first viewing got to love it. Well that's all of them except the TNG kids who well let's face it - they just aren't cool and are namby-pamby overly politically correct crap.
So yeah, maybe he can fix it because pretty much after Empire Lucas clearly lost the plot entirely - I mean Ewoks and Jar Jar sucked so badly it was sad.
Just because something is different doesn't make it bad or wrong.
For all we know the guy he's complaining about is a demon APL programmer. Or a guy who was partitioning FORTRAN so it ran decently on a super. Or maybe the guys an oldtime LISP dude and all the languages he's coding in makes him lament the loss.
Tracks Suck. Tubes Suck. They are one massive long single point of failure.
One day I was riding on the Acela and I realized the fatal flaw with high speed land transports. Your moving fast and there's no buffer. Now imagine doing 4000 mph. One part of that tube is bad - or there's an earthquake or a cave-in and guess what? Your doing 4000 mph straight towards a large piece of earth that moved into your path. Even a tornado doesn't compare to that. You could fly your 2000 mph aircraft right through the eye-wall of a hurricane and it's almost certainly more survivable than that 4000 transit-pod.
Oh, and in an aircraft you wouldn't have to fly right into the hurricane because you can divert. We know where hurricanes are. We know where thunderstorms are so we can avoid them too. How would you avoid an earthquake?
I'd much rather have a nice buffer of air which even in it's most turbulent state is infinitely more forgiving than solid earth.
Step 1. Close the Leet Javascript serverside apps page you were reading. Step 2. Wait for the Mark 1 computer to reload it's pipelines. Does it seem like it's working well now? Great! Go on to step 3. Step 3. Open Wikipedia. Pick a processor architecture. Intel x86, x64, MIPS, ARM, SPARC, PPC,... Step 4. Read the page. Notice in many cases different companies make chips that are the same Architecture. Notice how many different IMPLEMENTATIONS of those architectures exist. Are they all the same? No. Just like javascript interpreters there are differences. Step 5. Only attempt if your Mark 1 computer is working properly: Investigate timing attacks against microprocessors. Hint look at multicore cache information leakage. Step 6. Only for the polymaths! Now consider, if you wrote some code that managed to determine what code was running in another core due to a shared cache and timing analysis, would that work on all implementations. Hint notice that some implementations don't share caches.
Step 7. Give up. Context switch back to Javascript. Boy writing server side apps in Javascript is a GREAT IDEA. and Hey a new idea pops to mind - javascript is AWESOME - why not use it for the code in pacemakers, or autopilots, or antilock brakes! Wait! Maybe that new architecture is really a way to make a new vulnerability in javascript! Oh wow! Better post that now before someone else beats you to it!
Ask yourself - what is 'great' code. If you haven't seen 'great' code then you need to read more code. It exists. You will know it when you see it.
If you haven't already exposed yourself to languages that embrace re-factoring as a way of life you should. One of the best is Forth. Good Forth is like poetry. Chuck Moore has written several things about software and they are well worth consideration.
Good code I've read has usually got the following in common:
- It's correct - It does what it says it does and sounds like it does. - It is side effect free. - It has been re-factored extensively. - It is as short as it can be without making it more difficult to understand or introducing structures which are fragile or do bad things if you don't use the correct magical incantations which may be non-obvious.
Here's a couple of concrete things you can do with your existing code:
Imagine you wrote a 1000 line program.
Ask yourself can this be a 999 line program? When you get to the 999 line program, ask the same question.
Eventually you will reach a point where you can't reduce the length of the program without making it less clear. At that point ask yourself, can I re-factor it in a larger sense to make it MORE clear while keeping it correct.
Ask yourself if each method, function, class does what it says it does, and sounds like it should do. Check the program is still correct. Is the program robust? How does the code behave when its inputs are changed. If it's production code that will get hammered on then maybe you should add a comment about the time and size complexity.
One of the worst places to find bad code is API's. Experienced programmers know it's truely difficult to write a good API for a non-trivial program that stands the test of time. A good API isn't just sticking a bunch of public methods like so many people think it is. Find an API that's stood the test of time. Read up on it. If the programmer has written about the design decisions then read up on them.
Finally, think critically about what you KNOW and don't KNOW. Learn something new. Don't just skim it, read it and study it till you grok it. It can be something others take for granted say floating point. Read up on floating point arithmetic. Read about its pitfalls. You'd be amazed how many people who say they are good programmers don't understand precision, accuracy or that floating point numbers are imprecise.
a machine with custom graphics chipset and custom sound like the Atari 800 / C64 / Amiga. Something open that could be programmed, that ran a fast light OS, and not with the GPU added as an after thought. Something with no spinning disks, just solid state.
Something that could make computing fun again like it used to be 20-30 years ago.
The real fact is that the waste from a reactor is actually an upside. The processes described above, and by prior posters are much preferable to spewing radioactive material out into the atmosphere like coal plants do
The parent(s) are correct. Rocket launches are usually vertical and rapidly start 'pitching' the nose down so the flight is parallel with the earth. The main reason here is drag, but it's also important to understand that traditional bell nozzles are optimized for a specific atmospheric pressure (or lack thereof). That's why there has been so much interest in aerospikes (e.g. X-33)
A few comments about Skylon.
- Not hauling all that heavy oxidizer along is helpful. O2 is much heavier than H2 (See periodic table)
- The Specific Impulse of Jet engines is much greater than chemical rockets. The SSME's have an ISP about 1/5th that of a jet engine. Even the NERVA Nuclear Thermal Rockets had ISP/s about half that of a jet.
- You need to get to about 8 Km/s for orbit. The speed of sound from 10 Km to 30 Km is about 300 m/s. So you get:
A12/SR-71 (J57) was cruising at ~1Km/sec Kingfisher (Marquard Ramjet) ~ 1.5 Km/sec
That still leaves you 7Km/s of velocity you need. If you figure the Sabre can get 2Km/sec of velocity, using atmospheric oxygen and then use the same engine (hint saves weight and cost) while burning on board oxygen it's pretty cool.
It's actually a pretty cool design, and I wouldn't be surprised at all if this technology hadn't already flown in a black project. The holy grail is a design that takes off horizontally and uses atmospheric oxygen as it accelerates and transitions through jet, ramjet, scramjet, rocket.
You certainly need a 'critical mass' for a new architecture to sell, but it's not all doom and gloom for the other players. We mostly don't write in assembler nowadays. We use compilers. If a good compiler is produced, and made available at a reasonable cost, and a vendor believes a port will be profitable in terms of amortizing the full lifecycle cost of the port then they may port.
To generalize - consider architecture A with resources rA applied to it achieves a performance (either raw or per watt) of pA. If a competitor can create an architecture B that with resources rB give similar performance, and rB is considerably lower than rA then the producer of rA has to absorb the delta of rA to rB or the market has to be such that the delta is outweighed by other factors.
Embedded != Desktop. Embedded engineers are already used to using many different architectures and lighting up different tool chains. They aren't stuck on x86 like many people are.
Disruptive technology may really shake things up. There are chips out there that solutions using them may out perform ARM in power usage by over a couple of orders of magnitude. I used to think the MSP430 was low power. Than I saw the GA144. That thing is awesomely low power.
Exactly! Historically, Intel does not have a great track record at succeeding in the marketplace with new architectures.
If we just go with Intel:
i432 Super Object Oriented - lots of transistors, super CISCy. Very slow too, but probably could have been sped up decently (half the problem was the compiler and lack of caches) i860 - Very fast for it's day as long as you don't need to respond to a trap or interrupt... Evil to program. Great for an accelerator but not a great general purpose CPU i960 - This one was really nice, but started competing with x86 and got killed. (Some of the people from the i432 Itanium.- We all know how that's worked out.
Intel tried to get everyone off x86 with Itanium. This didn't happen, partly because AMD and MICROSOFT got together and did x86-64. That isn't to say that the folks at Intel aren't great - and they don't make great CPU's. They just seem to have a problem with almost like a 2nd system effect.
So what's kept Intel alive during all the above failures? x86 lock in. There's a strong argument to be made for source based distributions, and I'm sure that's the nightmare of any chip maker. All that needs to happen is for someone to come out with a decent compiler for your new architecture (not necessarily easy but doable), the code (which hopefully running on many architectures is fairly portable) to be recompiled and kerbam.
That's like what NexGen guys were going to do with the Nx586. Wakeup in x86 mode, but allow a programmer to say 'Give me the underlying architecture'.
I would never count Intel out though. Many people thought that Intel was toast during the march of the RISCs. PPC came out, there was the Power PC reference machine. We were all going to run OS/2, Taligent, Pink and Apple OS on it. For a while there the fastest NT boxes were MIPS then Alpha. Then Intel came out with the P6 and it was so much faster than the P5 that they kept everyone on x86.
Intel labs surely has x86's that blow the socks off anything out there. So don't count them out.
I have a soft spot in my heart for ARM because of how it came to be. Google Roger Wilson and history of ARM and you will read a great story of a few people with very few resources making an awesome processor. They got their inspiration from Bill Mensch and the folks at the Western Design Center. This was after Acorn tried all the main players in the future CPU's for performance and thought they all sucked. e.g. 68K, NS16032/32016 etc etc.
I thought about this some more and came to the same conclusion re external memory. I was trying to weigh the relative merit of very fast very small (Say 4K instructions) channel processors that can stream memory into the larger SRAM banks. The idea would be DMA on steroids. If your going to build a DMA controller and have the transistor budget then replacing a DMA unit with a simple in-order fast core might be a win, especially if it was fast enough that you could do bit vector stuff / record packing and unpacking down in the channels. The caveat being you need to keep the timing consistent so if that became difficult I would go back to just straight DMA.
The downside of adding lots of channels with the necessary drivers for memory is you'll end up needing more pins and then driving those pins, so power distribution becomes a factor. I think there's real benefit in surfacing the timing of the channel/memory processors details to compilers. Having compilers able to schedule things taking into account the performance of the larger memory.
I really like your idea of a common fast scratch space with deterministic timing for locking. I think that's a great idea and would hugely improve things on commodity CPU's.
Looking at the above you end up with a picture of basically a Crayesque machine. It occurs to me that if you added FP to the channel processors then you can start thinking about them like vector pipelines, I'm not sure that makes sense, it seems like doing DMA first, then maybe a simple in-order integer processor and then maybe FP would be a growth path for channels.
I wish I knew more about the limitations of putting SRAM on a die. Doing some searching it looks like Tukwilla's L3 cache of 24 MB is http://forums.anandtech.com/showthread.php?t=2093673 I think thats at 1.6 Ghz so 25 ns. If you could cool it at least as well as the ETA guys and get say 4x your down to ~6 ns for that 24 MB.
One real trade-off question to me would be at that point, how long would it take to do RDMA / use a channel processor to fetch from a different CPU versus talk to a bunch of external DRAM? At which point your deterministic timing goes out the window so maybe DRAM is the way to go...
Some of the new ARM cores are getting interesting. I do wonder how much market share from x86 ARM will win. Your right about the DDR specs smelling like QAM. They are doing a great job at getting more bandwidth but the latency stucks worse than ever. When it gets too much we will finally see processors distributed in memory and Cray 3/SSS here we come...
I keep thinking more and more often that Amdahls 'wafer scale' processor needs to be revisited. If you could build a say 3 centimeter square LN2 cooled CPU that had a few hundred MB of on-chip SRAM that would be an improvement. You wouldn't need to have signal pins, just power pins, Replace the memory pins with interconnect pins - you might as well, and then cram a bunch of them into cube - Cray 3 style.
I'm sure there would be a market for even a single chip fairly typical current x86 like that, let alone a bunch of them It should still be an order of magnitude lower latency than external stuff. It wouldn't solve the problem, but after you've built the 3 cm square chip - figure out how to do it with a 4 cm square chip that's LN2 cooled,
If you didn't want to do x86 you could tailor the instruction set to add a bunch of useful synchronization stuff, and most critically you'd want the processor to be deterministic with regards to timing - so the compilers could know that if you accessed the emory at the edges of the chip it was slower. If you got rid of all the cache you could even try explicitly handling dependencies with predicate registers. I'd have to think more about if the predicate registers versus cache makes sense but it seems like it would make things way easier for the compiler.
You could say it would be a design that was designed to remove all the latencies trying to drive all those memory and address lines fast - and kindof like a transputer...
It's the same problems as the async CPU people go through, except everyone is wearing rose-colored-spectacles and acting like there still playing with nice synchronous clocking.
The semantics become horrible once you start stringing together bazillions of commodity CPU's. Guaranteeing the dependencies are satisfied becomes non-trivial like you say even for a single multi-core x86 processor . You end up either with heavy duty synchronization that is reliable and slow or risk the chance of garbage and all kinds of synchronization hell. 1uS infiniband messages are several thousand clock cycles...
The only caveat I would add is if people really got honest and just built big piles of transfer-triggered architecture stuff then many of the timing problems would be solved - but they don't...
What bugs me is that there are plenty of scientists that hate the MPP boxes because their codes that do real stuff simply don't parallelize well, yet every time someone says fastest on TOP 5000 and manages to string even more commodity CPU's together with even worse latency the press say 'new breakthrough''.
Parallel computers are great, and parallel algorithms research is fine, and it should continue to be worked on, but someone needs to be figuring out how to build a damn fast GaAs box (or something else with better electron mobility than silicon) that has scalar performance that kicks serious ass. Hell even if someone was doing what the ETA people tried to do, and use commodity CMOS and seriously cool it to get a speedup would be start..
These modern machines which consist of zillions of cores attached over very low bandwidth and high latency link are really not supercomputers for a huge class of applications. Unless your application exhibits extreme memory locality and hardly any interconnect bandwidth / can tolerate long latencies.
The current crop of machines is driven mostly by marketing folks and not by people who really want to improve the core physics like Cray used to.
BANDWIDTH COSTS MONEY, LATENCY IS FOREVER
Take any of these zillion dollar plies of CPU's and just try doing this: for ( x=0; x.lt. bounds; ++x ) {
humungousMemoryStructure [ x ] = humungousMemoryStructure1 [ x ] * humungousMemoryStructure2 [ randomAddress ] + humungousMemoryStructure3 [ anotherMostlyRandomAddress ] ; }
It'll suck eggs. You'd be better off with a single liquid nitrogen cooled GaAs/ECL processor surrounded by the fastest memory you can get your hands on all packed into the smallest place you can and cooled with LN or LHe.
Half the problem is that everyone measures performance for publicity with LINPACK MFLOPS. It's a horrible metric.
If you really want to build a great new supercomputer get a (smallish) bunch of smart people together like Cray did, and focus on improving the core issues. Instead of spending all your erfforts on hiding latency, tackle it head on. Figure out how to build a fast processor and cool it. Figure out how to surround it with memory.
Yes,
Customers will still use commodity MPP machines for the stuff that parallelizes. Customers will still hire mathematicians, and have them look at ways to Map things that seem inherently non local into spaces that are local. Customers who have money and the mathematicians couldn't help will need your company and your GaAs/ECL or LHe cooled fastest SCALAR / Short Vector box in the world.
Slashdot Mirror
Marketing, producing products your users want do matter. Part of that is convincing your users they want to do that... There's a much more fundamental thing going on here. It's the same force that killed the dominance of the Mainframe, and the Mini.
Machines are fast enough now to do everything most consumers want to do with them.
Let's extrapolate what that really means:
1) Surf the web - Fine on 5 year old hardware (Even with stuff like Flash)
2) Watch video - Fine on a 5 year old box
3) Write something - Fine on a 5 year old box
4) Compute something - For most users fine on a 5 year old box.
Do you see the pattern here? The average user can do everything they want to do. Which gets to the crux of it. The real problem is that their isn't some new killer application that causes such a stir most users want to upgrade. The same thing happened to the mainframe and the mini. Once mini's were fast enough people used them to do many things (not all things) mainframes did. When the killer micros were fast enough users used them to do many things that mini's did.
What's going on is that we lived through a period where there were tangible benefits in upgrading. The truth as much as some might argue about it is that users bought into needing multitasking, they could see that editing some document or image (or video) was tangibly better on a faster machine.
What did that? Think about the mid 80's to 90's and even early 00's. There was the GUI. 90's we had the Web. Do you remember how insanely saturated EVERYTHING was with the web? It was www this and www that and web this and web that. In the 00's there was video. Hey you can watch video on your machine over broadband.
The machine running Windows 95 really was better for surfing the web than their WFWG 3.11 machine. The windows XP really was more reliable than the Windows 98 machine if you wanted to install random crap.
What's happened is that there's no real new apps that the average consumer cares about.
Now, if someone comes out with a killer app that needs a machine of PC levels of capability and piles of consumers are convinced they need it then the PC will take off. Microsoft has made Windows 8 look like a tablet OS to the average consumer, who based on sales figures is not convinced at all that they really want a tablet OS on their PC.
The PC won't die, just like the Mainframe didn't die and yes we still run piles of Mini's (Servers). It's just that your PC may be the size of a raspberry pi. For some people it will be the size of a regular PC or Laptop. Guess what - if you have to stick a decent sized screen on it and a keyboard it's going to be at least some size. That's until you either wear VR style glasses (No need for a big screen) and don't have motion estimation stuff so good and cheap you can just waggle your fingers in the air like you are typing on a virtual keyboard.
I haven't run Win 8 and lots of folksI know haven't either. We aren't MS haters - we're pragmatists and pretty much comprise a group of users who have used every MS OS (OK Nobody ran ME) since DOS. If a company can produce a product so crappy that it does that it really makes you wonder what the hell is wrong with management.
The $64000 question is what does MS do now? The best I can think of is make the Win 8 'Aqua' style interface better - hell throw the Windows 7 UI in there. That way they could keep working on the tile based stuff but not alienate everyone.
Unfortunately they've pretty much managed to alienate a huge number of users.
I use Linux entirely for work, and Win 7 on my machines at home when I'm not running Linux. I'm thinking about a new laptop for home but don't want Windows 8. I think I'm actually going to just do Linux on that laptop now steam is available for Linux. If I need Windows I'll run it in a VM. I'm curious who else has come to the same conclusion. Windows in a VM and Linux as your main OS because Win 8 seems so crappy.
I agree... and the interplay of Avon with the other Characters made that show. He was the bastard who is right most often, and the only one who could be talk to ORAC sanely..
Let's stick these folks who believe in this verification technique underneath the robot as the first patients.
Just do some pointless surgery, open em up, and stitch them back up.
If they survive then trials on other people can start.
Instead of all the pictures... I'd have shown the first game - Rescue On Fractalus, and had the Jaggi smash the cockpit window.
That would have been more fitting.
If they wanted to have some fun with it, change the jaggi into mickey mouse.
http://youtu.be/FbZ-chrOgGg
I mean seriously. This is like:
>Hey there new programmer
Err, Hello?
>Weren't you supposed to be here at 9:30 ?
Umm, yes but I couldn't come up the elevator.
> Why not?
Well I didn't know which floor.
> Isn't the floor written on that big board near the elevator?
Oh ah, well I suppose it could have been
> So how did you get here?
I just walked up the stairs and stopped on each floor to see if I saw the company name
> But we are on the 32nd floor?
Yes, it did seem to take a while, especially the knocking
> The knocking?
Well, yes, some of the doors were locked, so I had to knock to ask someone if this was 'AX7121 Systems'
> But, didn't it occur to you when they said NO, to ask them if they knew which floor AX7121 Systems was on?
Ah, yes I did, that caused me to go back down to the 7th floor three times.
>What?
I went back down to the 7th floor three times
>What?
Well someone said you were on the 7th floor, in total I went to the 7th floor 4 times, the 9th floor 3 times, and the 13th floor twice
>But if you had checked the 7th floor on the way up didn't it occur to you that we probably couldn't suddenly move in and appear there so you didn't need to recheck it?
Uh, well now you mention it, but I wanted to use a SAFE algorithm
> Hang on a minute I read your resume, you said you have a 4 year degree in computer science
Yes, I do, I graduated from #blah blah# last summer
> Did you guys ever cover elevator seeking problems?
Oh yes, we did - lots of work on that, it's related to reflection in Java, I know all about that!
> How is it related to reflection in Java?
I could reflect from my Elevator instance to find out what kind of elevator it is, and then I could call the .goToFloor method with a flor
> How would that have helped?
Well, I could have ridden the elevator instead of using the stairs, which would have sped things up lots and made the algorithm more efficient
> Are you joking?
Why would you ask that? It would definitely speed up the algorithm a little bit don't you think?
> I have a terrible pain in the side of my head, by the way, what is your name?
Clouseau
Please. All of that TNG crap. I wanted them to die. I wanted the scene to go like this:
Picard> Yes, but the question is *should* we kill them?
Data> Killing is not ethical
Blah>
Blah>
Blah>
Enterprise blown from the stars
Enemy captain> If you're going to shoot, shoot, don't talk
Aw you're just jealous because you live across the ditch.
I wonder what Joss Whedon would do with it? He did a smash-up job on firefly.
I apologize to the 'recent' fans, I really *really* wanted to like the 'new' episodes but they sucked. Horribly. I mean terrible horrible waste of all that ILM CPU cycles on digital effects and acting crap.
The reboot of Star Trek was awesome even die-hard trekkies I know who hated it on first viewing got to love it. Well that's all of them except the TNG kids who well let's face it - they just aren't cool and are namby-pamby overly politically correct crap.
So yeah, maybe he can fix it because pretty much after Empire Lucas clearly lost the plot entirely - I mean Ewoks and Jar Jar sucked so badly it was sad.
He needs to learn:
Just because something is different doesn't make it bad or wrong.
For all we know the guy he's complaining about is a demon APL programmer. Or a guy who was partitioning FORTRAN so it ran decently on a super. Or maybe the guys an oldtime LISP dude and all the languages he's coding in makes him lament the loss.
Tracks Suck. Tubes Suck. They are one massive long single point of failure.
One day I was riding on the Acela and I realized the fatal flaw with high speed land transports. Your moving fast and there's no buffer. Now imagine doing 4000 mph. One part of that tube is bad - or there's an earthquake or a cave-in and guess what? Your doing 4000 mph straight towards a large piece of earth that moved into your path. Even a tornado doesn't compare to that. You could fly your 2000 mph aircraft right through the eye-wall of a hurricane and it's almost certainly more survivable than that 4000 transit-pod.
Oh, and in an aircraft you wouldn't have to fly right into the hurricane because you can divert. We know where hurricanes are. We know where thunderstorms are so we can avoid them too. How would you avoid an earthquake?
I'd much rather have a nice buffer of air which even in it's most turbulent state is infinitely more forgiving than solid earth.
Step 1. Close the Leet Javascript serverside apps page you were reading. ...
Step 2. Wait for the Mark 1 computer to reload it's pipelines. Does it seem like it's working well now? Great! Go on to step 3.
Step 3. Open Wikipedia. Pick a processor architecture. Intel x86, x64, MIPS, ARM, SPARC, PPC,
Step 4. Read the page. Notice in many cases different companies make chips that are the same Architecture. Notice how many different IMPLEMENTATIONS of those architectures exist. Are they all the same? No. Just like javascript interpreters there are differences.
Step 5. Only attempt if your Mark 1 computer is working properly: Investigate timing attacks against microprocessors. Hint look at multicore cache information leakage.
Step 6. Only for the polymaths! Now consider, if you wrote some code that managed to determine what code was running in another core due to a shared cache and timing analysis, would that work on all implementations. Hint notice that some implementations don't share caches.
Step 7. Give up. Context switch back to Javascript. Boy writing server side apps in Javascript is a GREAT IDEA. and Hey a new idea pops to mind - javascript is AWESOME - why not use it for the code in pacemakers, or autopilots, or antilock brakes! Wait! Maybe that new architecture is really a way to make a new vulnerability in javascript! Oh wow! Better post that now before someone else beats you to it!
Ask yourself - what is 'great' code. If you haven't seen 'great' code then you need to read more code. It exists. You will know it when you see it.
If you haven't already exposed yourself to languages that embrace re-factoring as a way of life you should. One of the best is Forth. Good Forth is like poetry. Chuck Moore has written several things about software and they are well worth consideration.
Good code I've read has usually got the following in common:
- It's correct - It does what it says it does and sounds like it does.
- It is side effect free.
- It has been re-factored extensively.
- It is as short as it can be without making it more difficult to understand or introducing structures which are fragile or do bad things if you don't use the correct magical incantations which may be non-obvious.
Here's a couple of concrete things you can do with your existing code:
Imagine you wrote a 1000 line program.
Ask yourself can this be a 999 line program? When you get to the 999 line program, ask the same question.
Eventually you will reach a point where you can't reduce the length of the program without making it less clear. At that point ask yourself, can I re-factor it in a larger sense to make it MORE clear while keeping it correct.
Ask yourself if each method, function, class does what it says it does, and sounds like it should do. Check the program is still correct. Is the program robust? How does the code behave when its inputs are changed. If it's production code that will get hammered on then maybe you should add a comment about the time and size complexity.
One of the worst places to find bad code is API's. Experienced programmers know it's truely difficult to write a good API for a non-trivial program that stands the test of time. A good API isn't just sticking a bunch of public methods like so many people think it is. Find an API that's stood the test of time. Read up on it. If the programmer has written about the design decisions then read up on them.
Finally, think critically about what you KNOW and don't KNOW. Learn something new. Don't just skim it, read it and study it till you grok it. It can be something others take for granted say floating point. Read up on floating point arithmetic. Read about its pitfalls. You'd be amazed how many people who say they are good programmers don't understand precision, accuracy or that floating point numbers are imprecise.
I keep meaning to dig into FPGA's more. They do look like loads of fun - thanks for the links BTW!
a machine with custom graphics chipset and custom sound like the Atari 800 / C64 / Amiga. Something open that could be programmed, that ran a fast light OS, and not with the GPU added as an after thought. Something with no spinning disks, just solid state.
Something that could make computing fun again like it used to be 20-30 years ago.
You do realize that Thorium is Nuclear too right?
The real fact is that the waste from a reactor is actually an upside. The processes described above, and by prior posters are much preferable to spewing radioactive material out into the atmosphere like coal plants do
The parent(s) are correct. Rocket launches are usually vertical and rapidly start 'pitching' the nose down so the flight is parallel with the earth. The main reason here is drag, but it's also important to understand that traditional bell nozzles are optimized for a specific atmospheric pressure (or lack thereof). That's why there has been so much interest in aerospikes (e.g. X-33)
A few comments about Skylon.
- Not hauling all that heavy oxidizer along is helpful. O2 is much heavier than H2 (See periodic table)
- The Specific Impulse of Jet engines is much greater than chemical rockets. The SSME's have an ISP about 1/5th that of a jet engine. Even the NERVA Nuclear Thermal Rockets had ISP/s about half that of a jet.
- You need to get to about 8 Km/s for orbit. The speed of sound from 10 Km to 30 Km is about 300 m/s. So you get:
A12/SR-71 (J57) was cruising at ~1Km/sec
Kingfisher (Marquard Ramjet) ~ 1.5 Km/sec
That still leaves you 7Km/s of velocity you need. If you figure the Sabre can get 2Km/sec of velocity, using atmospheric oxygen and then use the same engine (hint saves weight and cost) while burning on board oxygen it's pretty cool.
It's actually a pretty cool design, and I wouldn't be surprised at all if this technology hadn't already flown in a black project. The holy grail is a design that takes off horizontally and uses atmospheric oxygen as it accelerates and transitions through jet, ramjet, scramjet, rocket.
You certainly need a 'critical mass' for a new architecture to sell, but it's not all doom and gloom for the other players. We mostly don't write in assembler nowadays. We use compilers. If a good compiler is produced, and made available at a reasonable cost, and a vendor believes a port will be profitable in terms of amortizing the full lifecycle cost of the port then they may port.
To generalize - consider architecture A with resources rA applied to it achieves a performance (either raw or per watt) of pA. If a competitor can create an architecture B that with resources rB give similar performance, and rB is considerably lower than rA then the producer of rA has to absorb the delta of rA to rB or the market has to be such that the delta is outweighed by other factors.
Embedded != Desktop. Embedded engineers are already used to using many different architectures and lighting up different tool chains. They aren't stuck on x86 like many people are.
Disruptive technology may really shake things up. There are chips out there that solutions using them may out perform ARM in power usage by over a couple of orders of magnitude. I used to think the MSP430 was low power. Than I saw the GA144. That thing is awesomely low power.
Exactly! Historically, Intel does not have a great track record at succeeding in the marketplace with new architectures.
If we just go with Intel:
i432 Super Object Oriented - lots of transistors, super CISCy. Very slow too, but probably could have been sped up decently (half the problem was the compiler and lack of caches)
i860 - Very fast for it's day as long as you don't need to respond to a trap or interrupt... Evil to program. Great for an accelerator but not a great general purpose CPU
i960 - This one was really nice, but started competing with x86 and got killed. (Some of the people from the i432
Itanium.- We all know how that's worked out.
Intel tried to get everyone off x86 with Itanium. This didn't happen, partly because AMD and MICROSOFT got together and did x86-64. That isn't to say that the folks at Intel aren't great - and they don't make great CPU's. They just seem to have a problem with almost like a 2nd system effect.
So what's kept Intel alive during all the above failures? x86 lock in. There's a strong argument to be made for source based distributions, and I'm sure that's the nightmare of any chip maker. All that needs to happen is for someone to come out with a decent compiler for your new architecture (not necessarily easy but doable), the code (which hopefully running on many architectures is fairly portable) to be recompiled and kerbam.
That's like what NexGen guys were going to do with the Nx586. Wakeup in x86 mode, but allow a programmer to say 'Give me the underlying architecture'.
I would never count Intel out though. Many people thought that Intel was toast during the march of the RISCs. PPC came out, there was the Power PC reference machine. We were all going to run OS/2, Taligent, Pink and Apple OS on it. For a while there the fastest NT boxes were MIPS then Alpha. Then Intel came out with the P6 and it was so much faster than the P5 that they kept everyone on x86.
Intel labs surely has x86's that blow the socks off anything out there. So don't count them out.
I have a soft spot in my heart for ARM because of how it came to be. Google Roger Wilson and history of ARM and you will read a great story of a few people with very few resources making an awesome processor. They got their inspiration from Bill Mensch and the folks at the Western Design Center. This was after Acorn tried all the main players in the future CPU's for performance and thought they all sucked. e.g. 68K, NS16032/32016 etc etc.
I thought about this some more and came to the same conclusion re external memory. I was trying to weigh the relative merit of very fast very small (Say 4K instructions) channel processors that can stream memory into the larger SRAM banks. The idea would be DMA on steroids. If your going to build a DMA controller and have the transistor budget then replacing a DMA unit with a simple in-order fast core might be a win, especially if it was fast enough that you could do bit vector stuff / record packing and unpacking down in the channels. The caveat being you need to keep the timing consistent so if that became difficult I would go back to just straight DMA.
The downside of adding lots of channels with the necessary drivers for memory is you'll end up needing more pins and then driving those pins, so power distribution becomes a factor. I think there's real benefit in surfacing the timing of the channel/memory processors details to compilers. Having compilers able to schedule things taking into account the performance of the larger memory.
I really like your idea of a common fast scratch space with deterministic timing for locking. I think that's a great idea and would hugely improve things on commodity CPU's.
Looking at the above you end up with a picture of basically a Crayesque machine. It occurs to me that if you added FP to the channel processors then you can start thinking about them like vector pipelines, I'm not sure that makes sense, it seems like doing DMA first, then maybe a simple in-order integer processor and then maybe FP would be a growth path for channels.
I wish I knew more about the limitations of putting SRAM on a die. Doing some searching it looks like Tukwilla's L3 cache of 24 MB is http://forums.anandtech.com/showthread.php?t=2093673 I think thats at 1.6 Ghz so 25 ns. If you could cool it at least as well as the ETA guys and get say 4x your down to ~6 ns for that 24 MB.
One real trade-off question to me would be at that point, how long would it take to do RDMA / use a channel processor to fetch from a different CPU versus talk to a bunch of external DRAM? At which point your deterministic timing goes out the window so maybe DRAM is the way to go...
Some of the new ARM cores are getting interesting. I do wonder how much market share from x86 ARM will win. Your right about the DDR specs smelling like QAM. They are doing a great job at getting more bandwidth but the latency stucks worse than ever. When it gets too much we will finally see processors distributed in memory and Cray 3/SSS here we come...
I keep thinking more and more often that Amdahls 'wafer scale' processor needs to be revisited. If you could build a say 3 centimeter square LN2 cooled CPU that had a few hundred MB of on-chip SRAM that would be an improvement. You wouldn't need to have signal pins, just power pins, Replace the memory pins with interconnect pins - you might as well, and then cram a bunch of them into cube - Cray 3 style.
I'm sure there would be a market for even a single chip fairly typical current x86 like that, let alone a bunch of them It should still be an order of magnitude lower latency than external stuff. It wouldn't solve the problem, but after you've built the 3 cm square chip - figure out how to do it with a 4 cm square chip that's LN2 cooled,
If you didn't want to do x86 you could tailor the instruction set to add a bunch of useful synchronization stuff, and most critically you'd want the processor to be deterministic with regards to timing - so the compilers could know that if you accessed the emory at the edges of the chip it was slower. If you got rid of all the cache you could even try explicitly handling dependencies with predicate registers. I'd have to think more about if the predicate registers versus cache makes sense but it seems like it would make things way easier for the compiler.
You could say it would be a design that was designed to remove all the latencies trying to drive all those memory and address lines fast - and kindof like a transputer...
Exactly!
It's all easy if you ignore:
Cache-misses.
Pipeline stalls
Dynamic clock throttling on cores
Interconnect delays
Timing skews
It's the same problems as the async CPU people go through, except everyone is wearing rose-colored-spectacles and acting like there still playing with nice synchronous clocking.
The semantics become horrible once you start stringing together bazillions of commodity CPU's. Guaranteeing the dependencies are satisfied becomes non-trivial like you say even for a single multi-core x86 processor . You end up either with heavy duty synchronization that is reliable and slow or risk the chance of garbage and all kinds of synchronization hell. 1uS infiniband messages are several thousand clock cycles...
The only caveat I would add is if people really got honest and just built big piles of transfer-triggered architecture stuff then many of the timing problems would be solved - but they don't...
What bugs me is that there are plenty of scientists that hate the MPP boxes because their codes that do real stuff simply don't parallelize well, yet every time someone says fastest on TOP 5000 and manages to string even more commodity CPU's together with even worse latency the press say 'new breakthrough''.
Parallel computers are great, and parallel algorithms research is fine, and it should continue to be worked on, but someone needs to be figuring out how to build a damn fast GaAs box (or something else with better electron mobility than silicon) that has scalar performance that kicks serious ass. Hell even if someone was doing what the ETA people tried to do, and use commodity CMOS and seriously cool it to get a speedup would be start..
These modern machines which consist of zillions of cores attached over very low bandwidth and high latency link are really not supercomputers for a huge class of applications. Unless your application exhibits extreme memory locality and hardly any interconnect bandwidth / can tolerate long latencies.
The current crop of machines is driven mostly by marketing folks and not by people who really want to improve the core physics like Cray used to.
BANDWIDTH COSTS MONEY, LATENCY IS FOREVER
Take any of these zillion dollar plies of CPU's and just try doing this: .lt. bounds; ++x )
for ( x=0; x
{
humungousMemoryStructure [ x ] = humungousMemoryStructure1 [ x ] * humungousMemoryStructure2 [ randomAddress ] + humungousMemoryStructure3 [ anotherMostlyRandomAddress ] ;
}
It'll suck eggs. You'd be better off with a single liquid nitrogen cooled GaAs/ECL processor surrounded by the fastest memory you can get your hands on all packed into the smallest place you can and cooled with LN or LHe.
Half the problem is that everyone measures performance for publicity with LINPACK MFLOPS. It's a horrible metric.
If you really want to build a great new supercomputer get a (smallish) bunch of smart people together like Cray did, and focus on improving the core issues. Instead of spending all your erfforts on hiding latency, tackle it head on. Figure out how to build a fast processor and cool it. Figure out how to surround it with memory.
Yes,
Customers will still use commodity MPP machines for the stuff that parallelizes.
Customers will still hire mathematicians, and have them look at ways to Map things that seem inherently non local into spaces that are local.
Customers who have money and the mathematicians couldn't help will need your company and your GaAs/ECL or LHe cooled fastest SCALAR / Short Vector box in the world.