it makes programming easier by making the whole parallel thing a bit more transparent I'd argue that it makes things more opaque, by abstracting away the need to explicitly deal with threads. Instead, you just define "tasks" that can run concurrently, and the toolkit takes care of mapping the tasks to actual threads.
Agreed it does look to take a lot of the grunt work out of writing parallel-processing code. There are supposedly Java and.NET versions under development, it'll be interesting to see if they're able to implement the concepts as cleanly as in C++. My guess is both implementations will be a little "clunky" (cumbersome and less efficient).
Seriously, you blame Intel for not having any L3 cache when their L2 cache is twice the size of AMD's total? I wonder if bandwidth and contention will take a toll. Obviously, having more cache won't help if you can't access it efficiently. However, it will help with inter-core data sharing. That should help to partially mitigate AMD's L3 cache (since that's one of its main advantages). However, since a CPU can only share cache with one other processor, it won't be as flexible as AMD's approach. You also won't see consistent results, since (presumably) processor scheduling will be dynamic, and there's no guarantee that two cooperating threads will be executed by two cores that share the same cache every time. And the cache-sharing advantage only works with two threads; any more, and you'll be going out to main memory to share data. And that's a long walk, nowadays...
magine if web browsers were anal retentive and refused to display anything with the slightest syntax error If they'd been this way from the start, then there wouldn't be any problem. HTML would be just like a programming language: break the rules, pay the price.
Imagine if your blog suddenly became undisplayable because commenter number 32 input some broken HTML Commenter #32 wouldn't have been able to input some broken HTML. If it was really important to keep HTML valid, then blog software would have correctness-checking, and submitting borked HTML would result in "The comment you entered did not pass HTML validation. Please check any HTML tags you may have entered and correct any errors."
Imagine that the slightest syntax error from Google Analytics, Google AdWords, or anything else you embed into your site could make your site completely unavailable. I imagine that anybody supplying ads would make damn sure their HTML was valid, since the clients don't care whose fault it is, they just want their ads to show up.
Sure, I know we can't suddenly flip a switch and declare that all HTML must be valid and well-formed from now on, I'm just saying that if we'd treated HTML the way we treat programming languages, we'd be in much better shape today. Too bad HTML tags weren't defined as a bunch of PostScript macros....
Why can't devices negotiate for how much voltage / current they need? They do — via the wall wart.
I wouldn't be surprised if someone proposes a standard for low-voltage DC distribution in the home. You'll wind up with dual-socket outlets, with your standard AC socket and two to four 12V sockets. Maybe use a multi-bladed plug to determine how much current the device can sink (each blade signifies 500ma, so a four-bladed plug can sink 2A). Somebody else has probably already thought this out in detail, so I'll just wait for someone to post a link to a complete spec...
I didn't read TFA, but I find it hard to believe that there's enough spectrum available to permit a dozen or so racks of 1U servers to communicate with UHF signals. Especially if (as is becoming common) they're hooked up to both a SAN and a router. Couple the bandwidth required for both signals with frequency separation requirements (so signals don't interfere with each other) and pretty soon you've got signals spread across more spectrum than one antenna can handle effectively. Then what? Do you install multiple transceivers, each handling a slice of the spectrum? Put multiple antennas on a single box and try to multiplex them (yeah, good luck with that)? Divide your data center into "zones" with some kind of shielding to prevent signal bleed?
This sounds neat for near-field applications (everything on your desk can talk to everything else), but I can't imagine it would scale well enough for something like a data center.
That's all part of the consulting game, but you have to play fair. Offer a fixed-price contract with no early termination penalty, or provide an escape clause that pays some fair amount if the contract is terminated early. I've known a couple of projects that badly burned some consultants, because management knew the project was going to fail, but they still put the contract out light on the rate but heavy with incentives. And what really sucks is, you'd like to say "Boy, you'll never catch me working for someone like that", but when they're one of the major players in town, you know you may have to play. Unless you're happy writing VB front ends to Access databases...
Ultimately, the actual value of the articles in mags like CIO.com are marginal at best Not so! Without these articles, how would CIOs sound clued-in when they gathered around the luau table during that big "experience sharing" conference at an island resort? How else would they know when to nod sagely while someone else relates their tale of SAP implementation? Or when to raise their eyebrows in appreciation of one of their peers' business savvy when they hear about how one of them deftly juggled a crisis during cutover from their legacy system to the new web-based one when they discovered that there had been no requirement for reconciling order counts at COB? I mean, something's got to get you through that awkward moment between when you first arrive and when you finish your third Hurricane...
My feeling is most of these "successful" projects were small-team, hands-off affairs. It's easy to do good work when you have a fixed goal (or set of goals), a responsible team and nominal oversight. The big projects fail because they take long enough that people change their minds (so requirements don't stay fixed) and because there's too much communication overhead (the old "management wants status reports more often, because we're falling behind" situation).
It strikes me as more likely that the CIPAV is deployed through a browser exploit (or perhaps even "legitimately" as an ActiveX control or BHO, people will install anything) Yeah, that was my impression too. Especially from the emphasis that the CIPAV would target "any computer that administers MySpace user account 'Timberlinebombinfo'". I was thinking that MySpace probably got tagged to "update" an ActiveX control on their site ("[X] Always trust content from MySpace.com"). I don't know if they've specifically stated that they won't cooperate with authorities to reveal user's identities, but I would guess in this case it's likely they would have (what with there being a proper warrant and all for someone who's actively threatening to blow up a school).
Actually, that's just what the server should do. The client is only supposed to send DHCPDECLINE if it detects that the network address is already in use. DHCP servers are encouraged to check any address offered (using an ICMP Echo Request) to make sure it is not in use. However, there's also supposed to be a switch to turn this off. DHCP clients are encouraged to check any offered addresses using an ARP packet. If the ARP packet generates a response (indicating that another machine already has the offered address), then the client should respond with DHCPDECLINE. Therefore, if the server isn't checking addresses before it hands them out, it stands to reason that it would mark them as "unavailable" if a client responds that the address is already in use. Unfortunately, the side effect would seem to be that a misbehaving piece of hardware could indeed eat all available addresses. I'd suggest that the remedy for that is to have the server check any declined address, and only mark it "in use" if it got a response.
I also doubt the iPhone has enough horsepower to pump out 10Mbps of ARP requests A 486 can swamp a T-1 line, I don't doubt that the ARM processor(s) in the iPhone can max out a 54Mb 802.11/g link. One ARP request is only about 28 bytes, and it's not like there's a lot of computation involved in creating one. I agree, it sounds like there's some kind of misconfiguration, I can't imagine why any device would fire off that many requests unless it was receiving some kind of response that caused it to send a new request. Hmmm, I wonder if it's some kind of timing issue, maybe the phone is receiving multiple responses from multiple APs very closely spaced, and it's triggering some kind of multiple response? IANANE, so I'll stop guessing.
Looks pretty great, but does it back stuff up in a neutral format? My first cell phone was a Nokia, next was an Ericsson, then a Moto flip-phone, then back to a Nokia, now back to a Moto. Half of these switches were because of a sudden failure of the phone (either theft or a 3-year-old). So what I'd want would be something that could handle common data (names and phone numbers, at least, calendar entries would be nice, I could give a shit about ringtones, wallpapers and other dweeb-essentials) and load it into any phone. So if I backed up my Moto flip-phone, and my daughter turned it into a caterpillar house (again...) and I replaced it with a Nokia, I could load my backup and at least have my phone list.
Speaking tubes were tried once ("Ahoy! More coolant on the starboard pile, and hoist up control rod three!") but finding reactor operators who knew Urdu was too difficult. Bah! That was just the excuse they used to try to bring in cheap Sanskrit-speaking labor from overseas!
I am sure there has been work on realtime GCs with guaranteed behavior, somewhere,... Look, here's some now! [ Link references IBM's Metronome project, which permits Java apps to provide deterministic scheduling and guaranteed response times down to ~1ms. ]
Those [government] employees have consented in writing to be investigated, watched, and spied on. Actually, I believe that's only true if you apply for a security clearance. Once you receive your security clearance, they're no longer free to monitor you. Of course, if you're working in a job that requires you to have a security clearance, you'll probably be in an environment where everyone is monitored while on-site, but that's done by your employer, and is/was probably something detailed in your employment agreement when you got hired.
I wouldn't be surprised if you were some lowly GS-12 who for some reason needed an ultra-high-level clearance, and you got monitored 24/7. However, I'd imagine that fact would be pointed out to you when you got your clearance, and there probably wouldn't be a damn thing you could do about it...
I guess I missed the obvious part of 'most applications get "time", even if they don't need them [sic]'. Actually, I was trolling for more information about the scheduler, under the guise of poking fun at the OP. And I got it!
3/ Somewhere in the middle of the ensuing discussion on lkml there are complaints that Con wasn't kept in the loop. However, Ingo cites examples where he *did* communicate to Con; by Con's own admission he was very ill (hospitalised) during a critical period. It might also be good to point out that Ingo wrote his code in about three days (sixty-some hours IIRC), so "the loop" didn't really exist that long. It sounds like it was just one of those times when you start to play around with an idea and everything just falls into place and you wind up with something really great instead of the collection of heavily-instrumented test code you thought you'd have.
Right now, most applications get "time", even if they don't need them... so, you are "wasting time" being a "good kernel/waiter" by going to your customer (process), and asking if he needs something more, just to wait for a "no" as answer. Seriously? What, the kernel switches to a process, the process checks its environment and figures out that the event it was waiting for hasn't happened yet, and goes back to sleep? I can't believe that a project as mature as the Linux kernel would use a scheduler like that. That sounds more like the result of trying to squeeze a scheduler into 256 bytes so you can lock it into two cache lines. I mean seriously, it's like cooperative multitasking with preemption...
I know it's a little "old school", but whatever happened to keeping track of which processes were "runnable" (i.e., had something to do) and which processses were waiting (blocking on I/O, waiting for a semaphore, waiting until the kernel gave them a buffer, etc.)? I kind of liked VMS's scheduler, it would boost the priority of processes that were waiting for TTY input (i.e., users), then gradually (over the next couple of context switches) return the priority to the default. That way, even if the system was busy, interactive users got a little more attention, so the system *felt* faster. I'm sure the Linux scheduler has some equally interesting features.
Most developers nowdays go for a really trivial schema and an abstraction layer. At that point the only thing that matters is row speed on simple table operations and there MySQL or in-memory OO database frameworks with a simple backing store wipe the floor. Until, of course, they don't. All it takes is a couple of users who want to actually get information *out* of the database ("How many widgets do we typically sell in Poughkipsie in March? And when I say 'Poughkipsie', I mean the greater Poughkipsie metroplex.") and you're stuck building indexes and making joins in your code. Eventually your code either becomes unmaintainable, or collapses under its own bulk. Agile/XP developers like the DRY axiom: Don't Repeat Yourself. Why write code to do what the database already does?
DBDs when you actually corner them to ask something meaningfull answer with SQL technobabble like in your post. To the average developer it sounds like fortran. And if it looks like fortran, walks like fortran and talks like fortran it gotta be fortran. Um, are you sure you want to be bringing up FORTRAN as a counterexample when discussing performance? I'm not an HPC enthusiast, but I don't recall seeing Java or Python mentioned in the same sentence as Linpack or STREAMS. It's all FORTRAN (77, some 90) or "C/C++" (the C++ is silent). Just another case of "pick the right tool for the job".
From the point of view of a average software engineer SQL and especially stored procedures look like a blast from the past "Those who do not understand Unix are condemned to reinvent it, poorly" — Henry Spencer. Relational databases are based on set theory, and have proven their worth over the last thirty years. Neither the old CODASYL or the new object databases could compete. Anyone who claims to be a "software engineer" and can't understand SQL is a poser. If they can't learn old tech, how are they going to learn new tech? There is an "SQL for Dummies", you know...
unless SQL data representation grows up to modern non-fortran-like OO semantics MySQL will proliferate In that case, why even use MySQL? Fall back to MyISAM and do all the work yourself! Hell, you are anyway, why even stick an SQL abstraction layer in there? Some fast serialization logic and you're good to go. For toy apps (like those presented in programming books), you can get away with stuff like that. When you get into real projects (something that requires more than one developer more than a year to do), hand-rolled "abstraction layers" that can't guarantee consistency or even simple reliability (quick: what does your data layer do with uncomitted writes when the kernel panics?) just don't cut it.
Inserting 20 million rows, all simple inserts, only one primary key (int) with autoincrement for mysql and a sequence for postgres: Avg Mysql time per 1000 inserts: 3 seconds Avg Postgres time per 1000 inserts: 15 seconds (and gets worse over time) OK, now do a seven-table join, including a self-join with a correlated subquery (MySQL does those now, right?). I think everybody knows by now that MySQL is pretty much untouchable as long as all you're doing is simple single-table stuff. Kind of like comparing a pickup truck to a moving van: if all you're doing is moving a couple of boxes around, then the pickup kicks. But when you need to move serious loads, then it's the pickup that gets to sit by the curb...
Sun systems will always be different from the x86 based cores that run MySQL and Oracle Umm, wrong both ways. Oracle runs really well on Sun SPARC hardware (and I suspect MySQL at least runs), and Sun also makes x86-based servers (built with AMD's Opteron chips). It shouldn't be any trouble to benchmark all three on the same hardware.
Well, no technical trouble, anyway — I doubt Oracle would like to have its performance compared to two free-as-in-beer competitors. Even if it comes out on top, people will still be tempted to think "Jeez, with the money I save on Oracle licenses, I can buy a faster server and make up the speed difference"...
I think you're at cross-purposes here. You want a quiet system, but you also want a big graphics card. Most gfx cards today have their own cooling fans (meaning one more noise source in the system). Plus, you want a PCIe x16 card, which means more bandwidth, which implied higher CPU requirements (hey, something's gotta supply those polygon requirements), faster RAM, faster HD (unless you wanna cut your frame rate waiting for textures to load), all of which mean more power, which equals more cooling, which equals more noise. Unless you can come up with some way to cool your system with dry ice or some other high-thermal-differential substance, you're going to have to move larger quantities of a less-efficient medium around.
Slashdot Mirror
Agreed it does look to take a lot of the grunt work out of writing parallel-processing code. There are supposedly Java and
Sure, I know we can't suddenly flip a switch and declare that all HTML must be valid and well-formed from now on, I'm just saying that if we'd treated HTML the way we treat programming languages, we'd be in much better shape today. Too bad HTML tags weren't defined as a bunch of PostScript macros....
I wouldn't be surprised if someone proposes a standard for low-voltage DC distribution in the home. You'll wind up with dual-socket outlets, with your standard AC socket and two to four 12V sockets. Maybe use a multi-bladed plug to determine how much current the device can sink (each blade signifies 500ma, so a four-bladed plug can sink 2A). Somebody else has probably already thought this out in detail, so I'll just wait for someone to post a link to a complete spec...
Maybe your friend's in the back yard, and you're on the second floor. Oh, and the RIAA's at the front door...
I didn't read TFA, but I find it hard to believe that there's enough spectrum available to permit a dozen or so racks of 1U servers to communicate with UHF signals. Especially if (as is becoming common) they're hooked up to both a SAN and a router. Couple the bandwidth required for both signals with frequency separation requirements (so signals don't interfere with each other) and pretty soon you've got signals spread across more spectrum than one antenna can handle effectively. Then what? Do you install multiple transceivers, each handling a slice of the spectrum? Put multiple antennas on a single box and try to multiplex them (yeah, good luck with that)? Divide your data center into "zones" with some kind of shielding to prevent signal bleed?
This sounds neat for near-field applications (everything on your desk can talk to everything else), but I can't imagine it would scale well enough for something like a data center.
That's all part of the consulting game, but you have to play fair. Offer a fixed-price contract with no early termination penalty, or provide an escape clause that pays some fair amount if the contract is terminated early. I've known a couple of projects that badly burned some consultants, because management knew the project was going to fail, but they still put the contract out light on the rate but heavy with incentives. And what really sucks is, you'd like to say "Boy, you'll never catch me working for someone like that", but when they're one of the major players in town, you know you may have to play. Unless you're happy writing VB front ends to Access databases...
My feeling is most of these "successful" projects were small-team, hands-off affairs. It's easy to do good work when you have a fixed goal (or set of goals), a responsible team and nominal oversight. The big projects fail because they take long enough that people change their minds (so requirements don't stay fixed) and because there's too much communication overhead (the old "management wants status reports more often, because we're falling behind" situation).
Actually, that's just what the server should do. The client is only supposed to send DHCPDECLINE if it detects that the network address is already in use. DHCP servers are encouraged to check any address offered (using an ICMP Echo Request) to make sure it is not in use. However, there's also supposed to be a switch to turn this off. DHCP clients are encouraged to check any offered addresses using an ARP packet. If the ARP packet generates a response (indicating that another machine already has the offered address), then the client should respond with DHCPDECLINE. Therefore, if the server isn't checking addresses before it hands them out, it stands to reason that it would mark them as "unavailable" if a client responds that the address is already in use. Unfortunately, the side effect would seem to be that a misbehaving piece of hardware could indeed eat all available addresses. I'd suggest that the remedy for that is to have the server check any declined address, and only mark it "in use" if it got a response.
Looks pretty great, but does it back stuff up in a neutral format? My first cell phone was a Nokia, next was an Ericsson, then a Moto flip-phone, then back to a Nokia, now back to a Moto. Half of these switches were because of a sudden failure of the phone (either theft or a 3-year-old). So what I'd want would be something that could handle common data (names and phone numbers, at least, calendar entries would be nice, I could give a shit about ringtones, wallpapers and other dweeb-essentials) and load it into any phone. So if I backed up my Moto flip-phone, and my daughter turned it into a caterpillar house (again...) and I replaced it with a Nokia, I could load my backup and at least have my phone list.
[ Link references IBM's Metronome project, which permits Java apps to provide deterministic scheduling and guaranteed response times down to ~1ms. ]
Don't most dog breaders live in Korea?
I wouldn't be surprised if you were some lowly GS-12 who for some reason needed an ultra-high-level clearance, and you got monitored 24/7. However, I'd imagine that fact would be pointed out to you when you got your clearance, and there probably wouldn't be a damn thing you could do about it...
I guess I missed the obvious part of 'most applications get "time", even if they don't need them [sic]'. Actually, I was trolling for more information about the scheduler, under the guise of poking fun at the OP. And I got it!
Thanks for flaming!
I know it's a little "old school", but whatever happened to keeping track of which processes were "runnable" (i.e., had something to do) and which processses were waiting (blocking on I/O, waiting for a semaphore, waiting until the kernel gave them a buffer, etc.)? I kind of liked VMS's scheduler, it would boost the priority of processes that were waiting for TTY input (i.e., users), then gradually (over the next couple of context switches) return the priority to the default. That way, even if the system was busy, interactive users got a little more attention, so the system *felt* faster. I'm sure the Linux scheduler has some equally interesting features.
Avg Mysql time per 1000 inserts: 3 seconds
Avg Postgres time per 1000 inserts: 15 seconds (and gets worse over time) OK, now do a seven-table join, including a self-join with a correlated subquery (MySQL does those now, right?). I think everybody knows by now that MySQL is pretty much untouchable as long as all you're doing is simple single-table stuff. Kind of like comparing a pickup truck to a moving van: if all you're doing is moving a couple of boxes around, then the pickup kicks. But when you need to move serious loads, then it's the pickup that gets to sit by the curb...
Well, no technical trouble, anyway — I doubt Oracle would like to have its performance compared to two free-as-in-beer competitors. Even if it comes out on top, people will still be tempted to think "Jeez, with the money I save on Oracle licenses, I can buy a faster server and make up the speed difference"...
I think you're at cross-purposes here. You want a quiet system, but you also want a big graphics card. Most gfx cards today have their own cooling fans (meaning one more noise source in the system). Plus, you want a PCIe x16 card, which means more bandwidth, which implied higher CPU requirements (hey, something's gotta supply those polygon requirements), faster RAM, faster HD (unless you wanna cut your frame rate waiting for textures to load), all of which mean more power, which equals more cooling, which equals more noise. Unless you can come up with some way to cool your system with dry ice or some other high-thermal-differential substance, you're going to have to move larger quantities of a less-efficient medium around.
Since when have toaster ovens been small? Smaller than a shoebox would be good, smaller than a toaster is cool, but a toaster oven?
Wake me when they're smaller than a box of Pop-Tarts (that's an ISO unit of measure, isn't it?)...