Might be cheaper to rig up a reverse KVM, and just have separate keyboards for each language. Sure, it'd take up a lot of space, but it's not my desk...;)
Seriously, though, I think you're one of the few people who would really utilize this keyboard. I think for things like gaming, you'd be better off just getting a game-specific keyboard, and the same goes for most other task-specific arguments: if you don't have to actually change the keyboard on a regular basis, you just need different keycaps, you probably won't be able to justify the cost of one of these.
Personally, I think they'd do well to focus on a standard keyboard and use the OLED buttons for the function keys. Those would change every time you switched applications, but there's no need to have every key re-labelable.
...why not start with one of these? It projects a virtual keyboard onto a flat surface, why not hack it to change the character driver? At least you're not stuck waiting for some breakthrough in manufacturing technology to get a full-sized keyboard...
(Personally, this thing gets my vote for "gadget most likely to actually attract babes in a club". Yes, I understand actually having this category for gadgets makes it extremely unlikely that I ever will attract babes in a club, gadgets or not.)
Hmmm, I'd be kind of surprised if there was much the compiler could do. Support for any architectural features, of course (cache snooping or IPC primitives), but compiling is largely a one-shot deal, your compiler can't know what the execution environment is going to be like when the code actually runs. For core scheduling and affinity, I think you're going to have to defer that to some kind of run-time environment (the OS or maybe some low-level hypervisor of some sort).
I think HP's done some work on dynamic recompilation, where they profile the run-time behavior of a program (across many runs), and then recompile or reconfigure the code somehow to optimize it. When I first heard about this, they would take the profiler data and feed that to the compiler and re-compile the source, using the profile data to steer the optimizer, but the last I heard, HP (or someone) was doing it just with the executable itself. It wasnt dynamic like the Java hotspot compilation, they actually created a new optimized executable.
two threads will switch back and forth on the single-proc machine, and you'll get cache eviction
I'd be kind of surprised to see that in your example case (video processing). I'd rather expect the threads to both be executing the main loop (which I'm guessing would be tight enough to fit entirely into cache), so hopefully they'd share the same cache lines (I-cache, of course). Of course, that presumes that those are the only two threads executing; once you start mixing other processes in the cache then it's all up for grabs (as you said). Still, point taken: most threads probably won't be executing code blocks small enough to cache, and you will have eviction. Maybe that's where the dual-processor machine shines: when the processing is intensive enough that the code won't fit into cache.
just building with nmake, switching from a 2p machine to a 4p machine (2.4GHz to 2.2GHz, even) cut my build time from 11 minutes to 7
Actually, I noticed a speedup on my single-processor machine, going with -j 5. I don't remember the exact numbers, but as you'd expect it wasn't nearly as spectacular as yours. Still, ISTR it was on the order of a 10% or so speedup. Probably due to my slow disk.;)
Does Intel have a C compiler that was designed for miiltiple CPU systems? What about GCC?
I don't think compilers are the issue, compilation is pretty non-parallelizable (code gen depends on parsing, which depends on lexing...), you'll probably get better speedup by just running multiple copies of the compiler on separate source files in parallel (the -j option to make, I believe). Of course, you'll still have to contend with disk bandwidth, so choose your -j value carefully...
If we want to continue to have faster and faster CPUs, then multiple cores is the way to go Ummm....no? Two 1GHz CPUs are not likely to be faster than 1 2GHz CPU. Maybe if you've got two CPU-bound processes, and you don't wind up running into bus bandwidth problems or memory contention issues, maybe you'll get almost the same performance, but I doubt it. Dual-CPU set-ups will typically give you 1.4-1.8 times the speedup of a single-processor system (e.g. http://www.nenastran.com/newnoran/parallel).
As you go on to say: You can only squeeze so many MHz out of a chip (as Intel found out at about 4Ghz). Therefore, you won't be getting faster CPUs. Q.E.D.
Cache and I/O bandwidth will only get you so far. Well, it's a fair distance, but OK...
However, since most operating systems are multi-tasking, having multiple cores is a win Uh huh. Your operating system may be multi-tasking, but your workload isn't. I'm willing to bet that a dual-core processor will feel faster, largely because you'll be able to do things if one process gets bogged down due to disk or network waits. But I doubt a four-core (or pair of dual-core) processors will feel much different. Good for bragging rights, maybe, and could be faster given the right workload (something multi-threaded that takes a dataset that can reside entirely in memory), but for a home user, there's no need for an 80-core (or even an 8-core) processor. Don't confuse the fact that your computer has 50+ tasks listed that it's actually running them all at once. 90% of them are just sitting there waiting for something to do.
And spare me the "If you build it, the code will be written". Parallalizing code is hard, and there aren't likely to be any big breakthroughs just because we have multi-core / multi-CPU system. I remember playing with Concurrent Euclid back when I was an undergrad, and AFAIK we're still using locks, mutexes and signals to enable threads to play nice with each other. If there haven't been any huge advances in the last twenty years, then I'm skeptical that there'll be any in the coming five.
This'll be nice for data centers (you wouldn't even need virtualization!), but it's not for home users.
I saw this big poster of Ron Jeremy, and it said "I love my fucking job! My co-workers suck! I get screwed every single day!" I looked around me at work, and I couldn't say the same. So I knew it was time to leave...
Hours is often the least of it. Photocopying fees, phone calls, postage, faxes, data entry, filing (paper, not court), research -- these are the things that really tend to add up. A large law firm may bill their senior associates in 10-minute increments, but a single ten-minute phone call can cascade into dozens of documents, occupying paralegals and secretaries for hours. So that one phone call may have cost you ten minutes of $1000/hour lawyer time, but the ancilliary costs will run far, far more.
Heh. Back when I was doing time & billing software for law firms, Morrison & Forester was one of our best clients. One of my cow-orkers actually jumped ship to work for them. Nice place to work, from what I hear. One of my former roommates was some kind of administrative assistant at a smaller (well, most law firms are smaller than MoFo) firm got a Rolex "in appreciation" when she left to go back to school. I can't imagine what their employee bonus plan looked like...
I've also heard that you can sell power back to the power company by supply electicity to the grid. The power company is required to pay you for the power you supply. A household could use one of the capacitors to store energy during the night when power is cheap and put it back on the grid in the morning and evening peak usage times.
That's an interesting point. I've heard that often the electric companies will "buy" the power, but what they actually do is just dump it to a big resistor, because of the difficulties matching the phase and frequency of the homeowner's power to the rest of the system. However, since they'd have to use a large DC/AC converter anyway, maybe that would mitigate the issues. I don't know enough about the intracacies of large-scale power grid management, but if this technology becomes widespread enough, it might spur the development of the necessary technology (if it doesn't already exist).
Or more likely, you'd have one per neighborhood (buried under the cul-de-sac, maybe). Since you only need to use it for five minutes, access contention shouldn't be an issue. Size it to charge 2-3 cars at a shot and you should have sufficient capacity (assuming say a 4-hour recharge cycle). Maybe even use it as a "neighborhood UPS": if the main grid goes down, everybody switches to the capacitor. Most power outages in my area are under an hour, an ultracapacitor should be able to power several suburban houses for that long -- unless it's summer and everyone has the A/C running, which is when the power usually goes out...
If you're going to push enough electricity to "drive a four-seat sedan like a Ferrari" in five minutes, you're going to have to move several hundred volts at lots of amps. Hope you don't have to stop for a charge in the rain, there's no way I'd want to be around both water and that kind of current!
on offering a service similar to Salesforce.com? I heard this rumor a good six months ago, but nothing since. Could be it's still in development, but I would have expected MS to trot this one out every quarter or so, just to keep Google (and Oracle) nervous....
Jesus, I remember building an F-111 model when I was a kid, had to have been over thirty years ago. Even if those things were new then, they should have been replaced long ago.
Don't get me wrong, I really enjoy my '58 Hallicrafters SX-101 and my '59 R-392URR, still better at what they were designed to do than many radios sold today, but...they're not aircraft. Certainly not highly-stressed, high-performance aircraft with metal fatigue and parts availability issues.
Is Iran really a dictatorship? That's one of the reasons why I'm so concerned about them, is that they seem like a country united behind their wack-ass president. If I've been fooled by their PR, then I'm actually somewhat relieved. Of course, there is still the fact that they're able to keep high-end US military hardware working without US support. And that whole high-speed torpedo thing...
Heh, I remember that. ISTR that the F-4 was an observer aircraft, and had a fairly high-ranking AF officer (Lt. Colonel?) and a Naval officer (Master Chief?) in the RIO position. Cockpit exchange between the pilot and RIO went something along the lines of:
Pilot: I've got red on both engines. Shall we go? RIO: Yep, looks like we're walking home.
IIRC, they did something similar when they used F-4s to pace the liftoff of the early Mercury (Gemini?) missions. The F-4 would approach the rocket as it lifted off, then turn vertical and actually accelerate alongside it as the pilot performed a visual inspection for any stray connectors or hoses that hadn't detached properly. They actually had escape towers in those days, so if the pilot saw something potentially dangerous, they could yank the capsule off the rocket.
When you have to reinvent the wheel, who do you think is going to produce better average case performance?
So you're asserting that guys who have worked on a given system for years will produce better average-case performance than some guy on a tight deadline? Well, duh, give the straw man a cigar!
OTOH, if you're not "reinventing the wheel" but "cranking out a new and improved wheel", and you're the one who has had "years to tinker with a veriety of implementations" (on a variety of projects), then you certainly can produce better average-case performance than some guys whose goal isn't performance but maybe portability, or ease of maintenance, or backwards compatability. Sure, everybody wants their code to run fast, but if your end goal isn't primarily performance, then you won't wind up with the fastest code. Not to mention that real-time work often affords certain conveniences that general-purpose systems don't have. E.g., you can specify that your code will only work with a given CPU / chipset / whatever, so you don't have to go through some generic driver layer that takes your read request and just turns around and passes it through to a driver that may not be fully optimized because it's constrained to support the generic driver interface. There's a lot of abstraction in most GPOSes today, which is unavoidable if you want to be truly "general purpose", but it's anathema to best possible performance.
Dunno, my first RT experience was a call data collection system running on duplex hardware hooked directly to a phone switch. Each call record represented a "cha-ching!", so we *could* *not* *lose* *any* *data*. We made the hardware as well as the software, and we sweated the details. That's what "real-time" means to me, so maybe it colors my perceptions.
Well, yeah, if you're going to take a general-purpose OS like UNIX and try to make it real-time, you're going to have to deal with the fact that you can't analyze every code path and predict your response time, so you've got to introduce mechanisms to compensate for that. In that case, sure, you've probably got more overhead. The post I was responding to, however, was asserting that a real-time OS would almost always be slower than a general-purpose one. I've worked on a couple of real-time projects, and both of the (microkernal-based) RTOSes we used were much quicker than an equivalent general-purpose OS on the same hardware (I guess that DOS or another single-tasking system might be quicker at a single function, but that's not doing the same work). I suppose you could argue that a microkernal RTOS isn't equivalent to a GP OS, but the OP was asserting that RTOSes in general provided worse response time than GPOSes, which simply isn't true (in my experience).
Figuring out the deadlines is the programmer's job. Code path analysis and worst-case execution time determination are a big part of it. It's all done before the system even boots, so yeah, it's free as far as performance goes.
Slashdot Mirror
Might be cheaper to rig up a reverse KVM, and just have separate keyboards for each language. Sure, it'd take up a lot of space, but it's not my desk... ;)
Seriously, though, I think you're one of the few people who would really utilize this keyboard. I think for things like gaming, you'd be better off just getting a game-specific keyboard, and the same goes for most other task-specific arguments: if you don't have to actually change the keyboard on a regular basis, you just need different keycaps, you probably won't be able to justify the cost of one of these.
Personally, I think they'd do well to focus on a standard keyboard and use the OLED buttons for the function keys. Those would change every time you switched applications, but there's no need to have every key re-labelable.
...why not start with one of these? It projects a virtual keyboard onto a flat surface, why not hack it to change the character driver? At least you're not stuck waiting for some breakthrough in manufacturing technology to get a full-sized keyboard...
(Personally, this thing gets my vote for "gadget most likely to actually attract babes in a club". Yes, I understand actually having this category for gadgets makes it extremely unlikely that I ever will attract babes in a club, gadgets or not.)
I read it as "Time to give the MySQL server a slap"!
Heh. If you do, you should enable mapping it to every key. No more agonizing decisions over "OK" or "Cancel": just "Fuck it".
Hmmm, I'd be kind of surprised if there was much the compiler could do. Support for any architectural features, of course (cache snooping or IPC primitives), but compiling is largely a one-shot deal, your compiler can't know what the execution environment is going to be like when the code actually runs. For core scheduling and affinity, I think you're going to have to defer that to some kind of run-time environment (the OS or maybe some low-level hypervisor of some sort).
I think HP's done some work on dynamic recompilation, where they profile the run-time behavior of a program (across many runs), and then recompile or reconfigure the code somehow to optimize it. When I first heard about this, they would take the profiler data and feed that to the compiler and re-compile the source, using the profile data to steer the optimizer, but the last I heard, HP (or someone) was doing it just with the executable itself. It wasnt dynamic like the Java hotspot compilation, they actually created a new optimized executable.
Actually, I noticed a speedup on my single-processor machine, going with -j 5. I don't remember the exact numbers, but as you'd expect it wasn't nearly as spectacular as yours. Still, ISTR it was on the order of a 10% or so speedup. Probably due to my slow disk.
If we want to continue to have faster and faster CPUs, then multiple cores is the way to go
Ummm....no? Two 1GHz CPUs are not likely to be faster than 1 2GHz CPU. Maybe if you've got two CPU-bound processes, and you don't wind up running into bus bandwidth problems or memory contention issues, maybe you'll get almost the same performance, but I doubt it. Dual-CPU set-ups will typically give you 1.4-1.8 times the speedup of a single-processor system (e.g. http://www.nenastran.com/newnoran/parallel).
As you go on to say:
You can only squeeze so many MHz out of a chip (as Intel found out at about 4Ghz).
Therefore, you won't be getting faster CPUs. Q.E.D.
Cache and I/O bandwidth will only get you so far.
Well, it's a fair distance, but OK...
However, since most operating systems are multi-tasking, having multiple cores is a win
Uh huh. Your operating system may be multi-tasking, but your workload isn't. I'm willing to bet that a dual-core processor will feel faster, largely because you'll be able to do things if one process gets bogged down due to disk or network waits. But I doubt a four-core (or pair of dual-core) processors will feel much different. Good for bragging rights, maybe, and could be faster given the right workload (something multi-threaded that takes a dataset that can reside entirely in memory), but for a home user, there's no need for an 80-core (or even an 8-core) processor. Don't confuse the fact that your computer has 50+ tasks listed that it's actually running them all at once. 90% of them are just sitting there waiting for something to do.
And spare me the "If you build it, the code will be written". Parallalizing code is hard, and there aren't likely to be any big breakthroughs just because we have multi-core / multi-CPU system. I remember playing with Concurrent Euclid back when I was an undergrad, and AFAIK we're still using locks, mutexes and signals to enable threads to play nice with each other. If there haven't been any huge advances in the last twenty years, then I'm skeptical that there'll be any in the coming five.
This'll be nice for data centers (you wouldn't even need virtualization!), but it's not for home users.
I saw this big poster of Ron Jeremy, and it said "I love my fucking job! My co-workers suck! I get screwed every single day!" I looked around me at work, and I couldn't say the same. So I knew it was time to leave...
Heh. Back when I was doing time & billing software for law firms, Morrison & Forester was one of our best clients. One of my cow-orkers actually jumped ship to work for them. Nice place to work, from what I hear. One of my former roommates was some kind of administrative assistant at a smaller (well, most law firms are smaller than MoFo) firm got a Rolex "in appreciation" when she left to go back to school. I can't imagine what their employee bonus plan looked like...
If you're going to push enough electricity to "drive a four-seat sedan like a Ferrari" in five minutes, you're going to have to move several hundred volts at lots of amps. Hope you don't have to stop for a charge in the rain, there's no way I'd want to be around both water and that kind of current!
Given the number of people with wheat allergies, I would think that would be counter-productive.
[24-SEP-2006 16:44:52] Fibrilation detect
[24-SEP-2006 16:44:56] Fuxx0r3d
[24-SEP-2006 16:44:56] Defibrilation start
[24-SEP-2006 16:44:56] Defibrilation complete
[24-SEP-2006 16:45:01] SYSTEM RESTARTED AT 16:45:01 ON 24-SEP-2006
on offering a service similar to Salesforce.com? I heard this rumor a good six months ago, but nothing since. Could be it's still in development, but I would have expected MS to trot this one out every quarter or so, just to keep Google (and Oracle) nervous....
Don't get me wrong, I really enjoy my '58 Hallicrafters SX-101 and my '59 R-392URR, still better at what they were designed to do than many radios sold today, but...they're not aircraft. Certainly not highly-stressed, high-performance aircraft with metal fatigue and parts availability issues.
Heh, I remember that. ISTR that the F-4 was an observer aircraft, and had a fairly high-ranking AF officer (Lt. Colonel?) and a Naval officer (Master Chief?) in the RIO position. Cockpit exchange between the pilot and RIO went something along the lines of:
Pilot: I've got red on both engines. Shall we go?
RIO: Yep, looks like we're walking home.
IIRC, they did something similar when they used F-4s to pace the liftoff of the early Mercury (Gemini?) missions. The F-4 would approach the rocket as it lifted off, then turn vertical and actually accelerate alongside it as the pilot performed a visual inspection for any stray connectors or hoses that hadn't detached properly. They actually had escape towers in those days, so if the pilot saw something potentially dangerous, they could yank the capsule off the rocket.
OTOH, if you're not "reinventing the wheel" but "cranking out a new and improved wheel", and you're the one who has had "years to tinker with a veriety of implementations" (on a variety of projects), then you certainly can produce better average-case performance than some guys whose goal isn't performance but maybe portability, or ease of maintenance, or backwards compatability. Sure, everybody wants their code to run fast, but if your end goal isn't primarily performance, then you won't wind up with the fastest code. Not to mention that real-time work often affords certain conveniences that general-purpose systems don't have. E.g., you can specify that your code will only work with a given CPU / chipset / whatever, so you don't have to go through some generic driver layer that takes your read request and just turns around and passes it through to a driver that may not be fully optimized because it's constrained to support the generic driver interface. There's a lot of abstraction in most GPOSes today, which is unavoidable if you want to be truly "general purpose", but it's anathema to best possible performance.
Dunno, my first RT experience was a call data collection system running on duplex hardware hooked directly to a phone switch. Each call record represented a "cha-ching!", so we *could* *not* *lose* *any* *data*. We made the hardware as well as the software, and we sweated the details. That's what "real-time" means to me, so maybe it colors my perceptions.
Well, yeah, if you're going to take a general-purpose OS like UNIX and try to make it real-time, you're going to have to deal with the fact that you can't analyze every code path and predict your response time, so you've got to introduce mechanisms to compensate for that. In that case, sure, you've probably got more overhead. The post I was responding to, however, was asserting that a real-time OS would almost always be slower than a general-purpose one. I've worked on a couple of real-time projects, and both of the (microkernal-based) RTOSes we used were much quicker than an equivalent general-purpose OS on the same hardware (I guess that DOS or another single-tasking system might be quicker at a single function, but that's not doing the same work). I suppose you could argue that a microkernal RTOS isn't equivalent to a GP OS, but the OP was asserting that RTOSes in general provided worse response time than GPOSes, which simply isn't true (in my experience).
Figuring out the deadlines is the programmer's job. Code path analysis and worst-case execution time determination are a big part of it. It's all done before the system even boots, so yeah, it's free as far as performance goes.