Ok, maybe not 20 years old, but 17 years old. Software I wrote in 1996 is still used today to verify chips built in the team I'm in at work. And that code compiles just fine. I haven't developed actively on it in about 14 years. No substantial tweaks to keep it current, either. I don't think it will compile as a 64-bit executable, but given that even Firefox is available as a 32-bit executable by default tells me that that's not a "historical" mode.
I was speaking with a team at work. They're talking about finally replacing some 30+ year old code in their code base with more modular, modern code. Sure, the whole package around it has continued to evolve, but some pieces date back to the first Reagan Administration. High level languages made that sort of continuity possible.
Now granted, the team whose code I'm referring to is a compiler team. Maybe, just maybe, they put more faith in compiled high level languages than your average programmer.;-) But, their work on high level and low level optimization has paid off again and again. We have a kick ass compiler, and I say that as a hard-core assembly programmer whose job was to set the bar them. (I don't expect a compiler to beat me on assembly code I spent a month on. But, I expect a programmer using C/C++ with intrinsics and directives to get to 95% faster than I could in hand-coded assembly. That last 5% is what we call "diminishing returns," folks.)
LLVM started outside of Apple. Apple hired some key LLVM developers, and put several of their own on it too. They've kept it public because enough people outside Apple are still contributing, and sure, that's great. So far everyone benefits. If Apple decided to stop publishing their LLVM updates and took it private, FreeBSD would have to fork it or move to another compiler.
But none of that is specific to FreeBSD, and none of those fund core FreeBSD development (which could happen just as easily with GCC or another compiler if LLVM were unavailable). Your point, again?
I personally find it more valuable to periodically examine the compiler output, and understand if there are particular idioms in my code which lead to bad code generation. For example, when I'm constructing a particular set of abstractions (say, a C++ template library), can the compiler peel them back and give me efficient code?
I still write assembly code when I need to (especially on small embedded systems, or on the Intellivision), but most of the time I just don't have the time. Also, most code's performance just doesn't matter. My time truly is the limited resource. I've had to learn that perfect is the enemy of good, and so to pick my battles wisely.
MenuetOS is impressive, but I doubt I would ever be able to use it, because I won't ever have the subset of peripherals, motherboards, etc. required to run it. And, because its development is entirely in assembly code, I suspect hardware will continue to change faster than it does.
I remember the last time I bet on an assembly-written horse (WordPerfect). It was the fastest, it was solid, and it got trumped, hard, when the world changed faster than it could.
I'm not sure why you think x86 is at all opcode compatible with the 4004. It's not even opcode compatible with the 8085. (You could translate 8085 code to 8086 with a special translator, but it wasn't guaranteed to be perfect.) The 4004 had a very weird instruction set, actually. Probably had something to do with the fact that you had to manually manage the memory bus and chip selects from the CPU, as opposed to more generic memory busses found on, well, just about anything outside the microcontroller world that talks to a JEDEC memory.
Otherwise, most of the CPU complexity that currently shows up is due to the fact that the CPU speed far outstrips the memory bus speed, thus all of the concern about "local" memory caches and pipelined instruction ordering. If you could create a much faster memory bus, CPU designs could be simplified considerably from a software developer POV.
This is the infamous memory wall, and lets face it, no processor vendor has figured out how to bypass physics and "just make memory faster." The problem was identified as far back in the 1940s, long before Intel even existed or Shockley's team at Bell Labs had invented their transistor. Consider this quote from Von Neumann himself:
Ideally one would desire an indefinitely large memory capacity such that any particular ⦠word would be immediately available. ⦠We are ⦠forced to recognize the possibility of constructing a hierarchy of memories, each of which has greater capacity than the preceding but which is less quickly accessible.
A. W. Burks, H. H. Goldstine, and J. von Neumann
Preliminary Discussion of the Logical Design of an Electronic Computing Instrument (1946)
But hey, I'm sure you've got some ideas. Why not get some VC money and make the next processor that will beat them all?
As I recall, FreeBSD provided some of the key underpinnings to Mac OS X and iOS. Surely Apple can spare some of its $90B back to the effort. $1M is a rounding error compared to $90B...
Yeah, pretty much. There's also a variety with three balls mounted in parallel. Sure, you'll pull loads slightly off center with such a hitch if you use the balls to either side, but not enough to make a big difference, apparently.
Whereas here in Texas, they won't file a police report unless there's an injury or death, it seems like. If you want to make an insurance claim, the cops will give you a form you have to fill out and send to Austin.
No, just significantly harder to filter effectively. Also, there were a rash of troll accounts with names that looked like the various Slashdot editors, only using accented variants of letters, such as 'tÍmothy'. All those shenanigans added up to where we are today.
Yeah, I was going to say, 40ms seems a bit out there. If you consider a touch typist typing 100WPM, that's about 8.3 characters/second, or about 120ms / character. You may think 40ms is fast enough to accommodate that, but not really. Typing is bursty by nature, and so many of those consecutive keystrokes will come close together. If you scan too slowly, you might see two keys "become active" on the same scan, and end up reordering them. At 40ms, that seems entirely likely for a touch typist at 100WPM.
So, GGGP was less wrong than stated, but for the wrong reasons. Huzzah! That is a rather strange defense. "I thought I was supposed to go south, when actually I was supposed to go north. But, I misread the roadsign and got on a road that goes northeast, so I ended up not too far from my destination. See? I'm not a bad navigator!"
Anyway, in the interest of actual analysis:
Let's go at the low end: 10kHz. And let's pick a beefier keycode, say "R CTRL", that has a 2 byte scan code. No, we're not going to benchmark the hilarious pause key. Get real. The vast majority of the scan codes are 1 byte anyway.
The time to send a key down event should be 2 bytes * 11 clocks, or 22 clock periods at 10kHz. That's 2.2 milliseconds. The time to send a key-up event should be 3 bytes * 11 clocks => 3.3 milliseconds.
Both of those seem pretty fast. The OS itself, though, and whatever layers there are between the PS/2 connector and the OS, will add their own latency. But in a race between a PS/2 keyboard and a USB mouse? I think they're going to both be well under 50ms in any case. 50ms is 20Hz, which is "Intellivision games from the late 70s" speed.
For me, it was AppleWorks Spreadsheet on an Apple ][e. Slightly newer than a Commodore PET, but the same 1MHz 6502 goodness. And then, SMART Spreadsheet on a 6MHz 286 AT clone. (SMART 1.x, not SmartWare II. SmartWare is still around, believe it or not.)
I think it's probably fine to store non-empty cells as objects, as long as you use something like the Flyweight pattern to avoid carrying too much baggage in each cell. It makes for a fine user interface, I'm sure.
To really get good recalc performance, though, you really need to drag the cell dependence graph out of the grid and treat it like an actual program. Once you do that, you could actually JIT the computation represented by all those cells. If you're really walking the object forest for every recalc, you'll never speed up.
I'd like to see you implement an AND gate with just XORs and NOTs. Use as many as you like...;-)
In all seriousness, you can build all other gates from NANDs. Or from NORs. In fact, that's how the Cray 1 was built, apparently. Tons and tons of ECL NAND gates.
Someone else (who I think I saw here on Slashdot the last time Voyager was mentioned) had a great analogy for what we're likely seeing. I can't take credit for this at all, but I think it makes a lot of sense.
Suppose we're a small probe, making our way off an island, down the beach, and into the ocean. All we have is a wind-speed detector, and a water detector. As we near the water, waves start lapping over us. When they do, our wind-speed detector says "no wind", and our water detector says "we're wet." Have we entered the ocean yet? The answer is "not quite, but we're really darn close."
It doesn't seem surprising to me at all that the boundary neither perfectly uniform, nor stationary in time. I think we'll be in this transition band for a while.
Slashdot Mirror
Ok, maybe not 20 years old, but 17 years old. Software I wrote in 1996 is still used today to verify chips built in the team I'm in at work. And that code compiles just fine. I haven't developed actively on it in about 14 years. No substantial tweaks to keep it current, either. I don't think it will compile as a 64-bit executable, but given that even Firefox is available as a 32-bit executable by default tells me that that's not a "historical" mode.
I was speaking with a team at work. They're talking about finally replacing some 30+ year old code in their code base with more modular, modern code. Sure, the whole package around it has continued to evolve, but some pieces date back to the first Reagan Administration. High level languages made that sort of continuity possible.
Now granted, the team whose code I'm referring to is a compiler team. Maybe, just maybe, they put more faith in compiled high level languages than your average programmer. ;-) But, their work on high level and low level optimization has paid off again and again. We have a kick ass compiler, and I say that as a hard-core assembly programmer whose job was to set the bar them. (I don't expect a compiler to beat me on assembly code I spent a month on. But, I expect a programmer using C/C++ with intrinsics and directives to get to 95% faster than I could in hand-coded assembly. That last 5% is what we call "diminishing returns," folks.)
LLVM started outside of Apple. Apple hired some key LLVM developers, and put several of their own on it too. They've kept it public because enough people outside Apple are still contributing, and sure, that's great. So far everyone benefits. If Apple decided to stop publishing their LLVM updates and took it private, FreeBSD would have to fork it or move to another compiler.
But none of that is specific to FreeBSD, and none of those fund core FreeBSD development (which could happen just as easily with GCC or another compiler if LLVM were unavailable). Your point, again?
I personally find it more valuable to periodically examine the compiler output, and understand if there are particular idioms in my code which lead to bad code generation. For example, when I'm constructing a particular set of abstractions (say, a C++ template library), can the compiler peel them back and give me efficient code?
I still write assembly code when I need to (especially on small embedded systems, or on the Intellivision), but most of the time I just don't have the time. Also, most code's performance just doesn't matter. My time truly is the limited resource. I've had to learn that perfect is the enemy of good, and so to pick my battles wisely.
MenuetOS is impressive, but I doubt I would ever be able to use it, because I won't ever have the subset of peripherals, motherboards, etc. required to run it. And, because its development is entirely in assembly code, I suspect hardware will continue to change faster than it does.
I remember the last time I bet on an assembly-written horse (WordPerfect). It was the fastest, it was solid, and it got trumped, hard, when the world changed faster than it could.
I'm not sure why you think x86 is at all opcode compatible with the 4004. It's not even opcode compatible with the 8085. (You could translate 8085 code to 8086 with a special translator, but it wasn't guaranteed to be perfect.) The 4004 had a very weird instruction set, actually. Probably had something to do with the fact that you had to manually manage the memory bus and chip selects from the CPU, as opposed to more generic memory busses found on, well, just about anything outside the microcontroller world that talks to a JEDEC memory.
This is the infamous memory wall, and lets face it, no processor vendor has figured out how to bypass physics and "just make memory faster." The problem was identified as far back in the 1940s, long before Intel even existed or Shockley's team at Bell Labs had invented their transistor. Consider this quote from Von Neumann himself:
But hey, I'm sure you've got some ideas. Why not get some VC money and make the next processor that will beat them all?
Actually... it's not even like paying programmers. It's more like tipping because you like the service.
Well, there's contributing code back, and there's paying programmers. Donating to FreeBSD would be more like "paying programmers."
As I recall, FreeBSD provided some of the key underpinnings to Mac OS X and iOS. Surely Apple can spare some of its $90B back to the effort. $1M is a rounding error compared to $90B...
We're switching to all digital broadcasts. But, you can hold onto that old analog-only set as long as you like.
But hey, they're strong enough to puncture a Tesla, so there you go. (FWIW, I don't tow a darn thing.)
Yeah, pretty much. There's also a variety with three balls mounted in parallel. Sure, you'll pull loads slightly off center with such a hitch if you use the balls to either side, but not enough to make a big difference, apparently.
One of these, perchance? http://www.harborfreight.com/triple-ball-trailer-hitch-69874.html
Whereas here in Texas, they won't file a police report unless there's an injury or death, it seems like. If you want to make an insurance claim, the cops will give you a form you have to fill out and send to Austin.
Not just based on it. It sounds like they're actually putting their boards into N900 cases, aren't they?
That's some mighty fine editing there, Lou. FWIW, if that was copy/pasted from the original article, they've fixed it over there. Otherwise... wow.
Well, it's not a dump truck!
Something tells me that one of these pods would have quite a bit more kinetic energy to bleed off than an elevator car. 1/2 mv^2 and all..
Quite possibly. *shrug* I find it very difficult to actually care.
No, just significantly harder to filter effectively. Also, there were a rash of troll accounts with names that looked like the various Slashdot editors, only using accented variants of letters, such as 'tÍmothy'. All those shenanigans added up to where we are today.
Has anyone mentioned yet the amazing coincidence that IMDB has him credited as a "W.H.O. Doctor" in World War Z?
Yeah, I was going to say, 40ms seems a bit out there. If you consider a touch typist typing 100WPM, that's about 8.3 characters/second, or about 120ms / character. You may think 40ms is fast enough to accommodate that, but not really. Typing is bursty by nature, and so many of those consecutive keystrokes will come close together. If you scan too slowly, you might see two keys "become active" on the same scan, and end up reordering them. At 40ms, that seems entirely likely for a touch typist at 100WPM.
10ms seems far more reasonable.
So, GGGP was less wrong than stated, but for the wrong reasons. Huzzah! That is a rather strange defense. "I thought I was supposed to go south, when actually I was supposed to go north. But, I misread the roadsign and got on a road that goes northeast, so I ended up not too far from my destination. See? I'm not a bad navigator!"
Anyway, in the interest of actual analysis:
Let's go at the low end: 10kHz. And let's pick a beefier keycode, say "R CTRL", that has a 2 byte scan code. No, we're not going to benchmark the hilarious pause key. Get real. The vast majority of the scan codes are 1 byte anyway.
The time to send a key down event should be 2 bytes * 11 clocks, or 22 clock periods at 10kHz. That's 2.2 milliseconds. The time to send a key-up event should be 3 bytes * 11 clocks => 3.3 milliseconds.
Both of those seem pretty fast. The OS itself, though, and whatever layers there are between the PS/2 connector and the OS, will add their own latency. But in a race between a PS/2 keyboard and a USB mouse? I think they're going to both be well under 50ms in any case. 50ms is 20Hz, which is "Intellivision games from the late 70s" speed.
For me, it was AppleWorks Spreadsheet on an Apple ][e. Slightly newer than a Commodore PET, but the same 1MHz 6502 goodness. And then, SMART Spreadsheet on a 6MHz 286 AT clone. (SMART 1.x, not SmartWare II. SmartWare is still around, believe it or not.)
I think it's probably fine to store non-empty cells as objects, as long as you use something like the Flyweight pattern to avoid carrying too much baggage in each cell. It makes for a fine user interface, I'm sure.
To really get good recalc performance, though, you really need to drag the cell dependence graph out of the grid and treat it like an actual program. Once you do that, you could actually JIT the computation represented by all those cells. If you're really walking the object forest for every recalc, you'll never speed up.
I'd like to see you implement an AND gate with just XORs and NOTs. Use as many as you like... ;-)
In all seriousness, you can build all other gates from NANDs. Or from NORs. In fact, that's how the Cray 1 was built, apparently. Tons and tons of ECL NAND gates.
Someone else (who I think I saw here on Slashdot the last time Voyager was mentioned) had a great analogy for what we're likely seeing. I can't take credit for this at all, but I think it makes a lot of sense.
Suppose we're a small probe, making our way off an island, down the beach, and into the ocean. All we have is a wind-speed detector, and a water detector. As we near the water, waves start lapping over us. When they do, our wind-speed detector says "no wind", and our water detector says "we're wet." Have we entered the ocean yet? The answer is "not quite, but we're really darn close."
It doesn't seem surprising to me at all that the boundary neither perfectly uniform, nor stationary in time. I think we'll be in this transition band for a while.