"There are X number of people in the world", followed by a list?;p
Re:Ada was designed for multiple CPUs
on
The Return of Ada
·
· Score: 2, Insightful
However, one particular feature of Ada seems more suited to current hardware than other languages: it was designed to allow many computers/CPUs to communicate via the rendezvous.
"I can do it in C" was the line we always used when our Ada teacher said anything "could be done in Ada but nothing else".
"Rendezvous" was built into Ada explicitly but other standards have given it directly or through libraries to everything else. It's just thread synchronization that you can emulate/simulate/do in many other languages with similar code... semaphores, mutexes, events/conditionals, etc. but perhaps with a little more explicitness by the programmer.
The first thing to remember is that no (higher level) language gives magical properties to a computer. If one language can do it, I can guarantee that at least one other can tap into it as well... Machine Language being the easiest example because even magical Ada gets compiled into ML or interpreted by ML at one point or another... if it can be done, it can be done in ML. C is just a step up from Assembly/ML (we used to joke that C was portable Assembly).
You *might* can say that Ada was the first to actually have it as a construct defined in the language specification (I dunno the history of it, there may have been a language before Ada with it designed in) but even by Ada's heyday (mid- to late 80s), we could do it in C.
which means at least observationally accurate physics, even if you couldn't count on it being perfect down to the splinter.
Exactly. Use equations that approximate it well enough for game play through the eyes of a player instead of using the most accurate equations. Also, limit collision effects so that the matrices don't get so big. Ever wonder why you haven't seen a cube of jello in most games and most things are rigid bodies (something that doesn't really exist in the real world)? Why not vehicles that get deformed properly in crashes and have their performance modelled accurately? Instead, you get some 'tacked on' visual crash damage and your top speed/acceleration/handling is degraded by X/Y/Z amounts... which is 'good enough' for a game.
Of course they wouldn't make up physical constants... the point I was making is that they don't, perhaps, solve matrices of partial differential equations to determine the interaction of everything in the system. Instead, they may use 'shortcuts' that are 'good enough'. The algebraic equations that you may have learned and used in highschool physics to determine simple things like momentum and speed are approximations that are typically 'good enough' for most calculations (they assume acceleration is a constant when in the real world, it never is). The "real" equations are calculus based, for example.
6. CCP obviously not playing their game. Putting the new high level missions in lowsec so people can get griefed, not providing any sort of mission that could involve an entire player corp along with a reward commensurate with the risk and number of people involved.
This is obviously incorrect. It's well known that CCP devs and such play and control the highest-end corps in the game (at least one has been caught giving his corp things created with dev powers). Plus, most of the devs were UO players and loved the griefing so they do things that increase the amount of griefing that can happen... particularly if they can do the griefing;)
The embedded GPU would need to be able to do floating point, double precision preferred.... which even the high end cards from a short time ago couldn't do (the double precision part).
Yup... I have friends who have thrown chairs at their TV (literally) because of something that happened in a MMO. Also hitting desks and injuring their hands, etc. It really depends on the person... I think it's more associated with how people deal with losing... in one case, one friend HATES to die in any game, it's like a personal insult. Even FPS games he hates to die. He's the one who threw his chair across the room and hit his TV when he died playing EQ once.;)
To add to your post, the folks at Cinebench were very happy transitioning from 32-bit land to 64-bit land (x86-64) because they were able to get rid of a lot of cruft and make use of the registers and such to achieve a significant speedup with their 64-bit version over their 32-bit version.
Also, in 32-bit land, you can use blocking algorithms to get by memory limitations. Not all operations must be done over the entire file, requiring all the data be in memory at the same time so it isn't like 32-bit can't do what 64-bit can memory-wise.
Well... "setup/configure" of a home network these days consists of plugging the power cable into the router and plugging all the computers into it with patch cables and connecting that to the cable 'modem'. Starting OSS projects is not difficult... make a repository on SourceForge. Contributing isn't that hard either... minimal contribution is simply reporting bugs. 5 programming languages is easy if they are all, for example, similar to C (C++/Java/C#/etc). Don't get me wrong, it's cool that you have done stuff at a fairly early age.
I started, for example, in middle school as well (~1980), but this was when not many people had home computers at all (that was before C64s, even). By the time I had graduated highschool, I had programmed in 3+ languages (6502 Assembly, BASIC, Pascal). Had there been networking, I would have done that as well, but dialup to BBSs was pretty much all we had (and null modems to connect computers together).
Back in the day, we also did a bit of work with hardware. I had been making my own cables for some time before I was 18. In '86, I started college and started playing around on the Internet with servers and such. I also built a computer from a handful of chips, some wires, and a breadboard (Z80 with some support chips/logic, communicated over serial to a PC) for fun (not class related - in higher level classes, we did these things again for class with a 68k but it was also still tons of fun).
Computers and playing with them was a lot more fun back then, IMO. Programming them and making the hardware you used (from cables to controller boards/etc) was the norm. These days, it's actually pretty simple in comparison, IMO... 'playing' with computers is basically using them and maybe programming them. The most hardware interaction anyone gets is plugging in a new video card, a new HDD, or plugging in a wire to a USB port. Maybe, if you're considered an 'enthusiast', you'll assemble your own, but that's really just plugging a bunch of boards together... not actually 'building' one like the 'enthusiasts' did back then:)
I'm sure my experiences aren't so different from many other/. readers. I bet if you ask all of us what our first 'big/real' program we wrote was, the majority would answer that it had something to do with D&D. Mine, for example, was a character generation program and it used *all* the RAM of my machine... 4K, so I got a 16K expansion module and kept going and filled up all 20K! and was stored on a cassette tape! Man... things were so fun back then.
With the $10,000 prize, they could have picked whatever machine they thought was the easiest/fastest to hack (which they obviously did) and bought several MacBook Airs with the prize money.
Guess what? There are *a lot* of companies coming to Red Hat, right now, *asking how to participate in open source projects.* So Jim is not talking pie-in-the-sky here; he's talking about capitalizing on momentum that already exists. There's pretty much zero coercion involved here.
Then why is RH whining about prying internal code from companies? Sounds like RH wants people to give them more software/features for free so RH can sell it and make money.
I've been writing multithreaded and parallel (MPP/MIMD) code for 20 years or so and there were plenty of people writing those kinds of codes long before I started. It's not exactly a new thing.
Anyway, we bring our own tools to new jobs. Our software programs that we customize and modify that will maximize our productivity. Tools like text editors, spreadsheet macros, graphics and CAD design programs. I'm going to spend forty hours learning CADbozoCAD when most of the industry uses BozoCAD, just because your company got it a 10% discount? Fuck that!
It's amazing that you can see past the end of your nose with your shortsightedness. Suppose all the company's equipment runs with CADbozoCAD and not BozoCAD? You are not only creating more work for yourself, because you have to convert to what the company uses because you're too ingrained in your own ego and superiority to learn something different (or maybe you're just unable to do that). Also, anything you produce is worthless to the company because they will be unable to maintain it and will have to redo everything you've done when the time comes to 'fix' anything. You are a lose-lose proposition for any company you work for.
Perhaps your attitudes are why you've been relegated to joining a temp placement organization instead of being able to find a permenant position?
Effortless parallelization for certain models of parallel programming, not all I'd wager. Producer/consumer, thread pools, etc, sure (task parallel). Data parallel is difficult because most of the problem there is partitioning the data properly and the inherent issues with synchronization (talking about MPP/MIMD type programs) and notification (message passing, for example), particularly when the data set is too large to fit in a single process or even on a single machine.
There's also the issue that clock speed isn't just running up a clock. It's distance (yeah, there are some things more than that, but it's basically how far the signal can travel at a given speed and be stable before it's latched). The distance the signal has to travel through the longest pipeline stage is the fastest that the clock can run without violation of setup/hold times and such. A single gate switch time is a bit faster than 3GHz or whatever we see. The thing is, the signal has to travel a ways through all those gates and stuff before it can be latched for the next pipeline stage.
Using the same process that Intel is using right now for Core2 parts, you could design a processor that runs much faster than 3GHz (hello P4) or you could design one so complex that it can only run at a few MHz because the longest paths prevent it. Run the clock too fast and the signal just doesn't have time to make it to the finish line, and then the best you can hope for is a hard crash. At worst, you can produce garbage from a calculation that get propagated right along. The problem is, sometimes it's difficult to notice when that happens.
This is probably more due to Intel's implementation of SMT in P4 than it was because of SMT in general. Ideally, you have two (or more) instruction streams that can be multiplexed on the granularity of execution units not being full from one stream and L1 cache misses. Think of for every clock cycle, the dispatcher optimally selecting instructions/micro-ops/macro-ops/whatever from both instruction streams such that all execution resources are busy (or as close as it can get... no FPU instructions in either stream ready for dispatch obviously leaves those resources idle, for example).
In theory, this means having a full pipeline with all execution units busy all the time (or very near it). Intel's P4 implementation had issues with Replay logic. Basically, it would burn lots of cycles and resources re-executing somewhat speculatively the same instruction over and over until it could actually finish, filling the pipeline with replayed instructions (ones it is already attempting executing) rather than executing new instructions from the two SMT streams. Nehalem shouldn't have this issue if they don't have the pathological Replay (helped because of shorter pipeline length) and many more execution resources than the P4 has.
Just because Intel's first implementation of SMT was bad isn't an indicator that the entire technology is bad:)
I've never had a client approach me and say that they were willing to pay a certain amount, what could they do for me... usually, they say what they want and get a quote. You quote what you think they'll pay and if they aren't, then you don't get the job. You rarely, if ever, know how much they're *really* willing to pay.
Slashdot Mirror
Unpossible... ABBA's drummer died a few weeks ago :(
...threatened to go into the business of selling clothes hangars real cheap to compete with Monster Cables.
Kind of like the:
;p
"There are X number of people in the world", followed by a list?
"I can do it in C" was the line we always used when our Ada teacher said anything "could be done in Ada but nothing else".
"Rendezvous" was built into Ada explicitly but other standards have given it directly or through libraries to everything else. It's just thread synchronization that you can emulate/simulate/do in many other languages with similar code... semaphores, mutexes, events/conditionals, etc. but perhaps with a little more explicitness by the programmer.
The first thing to remember is that no (higher level) language gives magical properties to a computer. If one language can do it, I can guarantee that at least one other can tap into it as well... Machine Language being the easiest example because even magical Ada gets compiled into ML or interpreted by ML at one point or another... if it can be done, it can be done in ML. C is just a step up from Assembly/ML (we used to joke that C was portable Assembly).
You *might* can say that Ada was the first to actually have it as a construct defined in the language specification (I dunno the history of it, there may have been a language before Ada with it designed in) but even by Ada's heyday (mid- to late 80s), we could do it in C.
Exactly. Use equations that approximate it well enough for game play through the eyes of a player instead of using the most accurate equations. Also, limit collision effects so that the matrices don't get so big. Ever wonder why you haven't seen a cube of jello in most games and most things are rigid bodies (something that doesn't really exist in the real world)? Why not vehicles that get deformed properly in crashes and have their performance modelled accurately? Instead, you get some 'tacked on' visual crash damage and your top speed/acceleration/handling is degraded by X/Y/Z amounts... which is 'good enough' for a game.
Of course they wouldn't make up physical constants... the point I was making is that they don't, perhaps, solve matrices of partial differential equations to determine the interaction of everything in the system. Instead, they may use 'shortcuts' that are 'good enough'. The algebraic equations that you may have learned and used in highschool physics to determine simple things like momentum and speed are approximations that are typically 'good enough' for most calculations (they assume acceleration is a constant when in the real world, it never is). The "real" equations are calculus based, for example.
You asserted something. The reply asked you to prove it. The burden of proof is on you, not the reply.
This is obviously incorrect. It's well known that CCP devs and such play and control the highest-end corps in the game (at least one has been caught giving his corp things created with dev powers). Plus, most of the devs were UO players and loved the griefing so they do things that increase the amount of griefing that can happen... particularly if they can do the griefing
The embedded GPU would need to be able to do floating point, double precision preferred.... which even the high end cards from a short time ago couldn't do (the double precision part).
Not only that but it's probably not even accurate physics. It's not a physics simulator, it's a game.
That was done so long ago, it's got petrified dinosaur snot on it!
So they fit four razor blades, with spacing, where it used to be the width of a single razor blade (like 2mm)? ;)
So less of a drain on the economy since heart attack is sudden and final while old age is a long time span filled with many ailments and medications ;)
Yup... I have friends who have thrown chairs at their TV (literally) because of something that happened in a MMO. Also hitting desks and injuring their hands, etc. It really depends on the person... I think it's more associated with how people deal with losing... in one case, one friend HATES to die in any game, it's like a personal insult. Even FPS games he hates to die. He's the one who threw his chair across the room and hit his TV when he died playing EQ once. ;)
To add to your post, the folks at Cinebench were very happy transitioning from 32-bit land to 64-bit land (x86-64) because they were able to get rid of a lot of cruft and make use of the registers and such to achieve a significant speedup with their 64-bit version over their 32-bit version.
Also, in 32-bit land, you can use blocking algorithms to get by memory limitations. Not all operations must be done over the entire file, requiring all the data be in memory at the same time so it isn't like 32-bit can't do what 64-bit can memory-wise.
Well... "setup/configure" of a home network these days consists of plugging the power cable into the router and plugging all the computers into it with patch cables and connecting that to the cable 'modem'. Starting OSS projects is not difficult... make a repository on SourceForge. Contributing isn't that hard either... minimal contribution is simply reporting bugs. 5 programming languages is easy if they are all, for example, similar to C (C++/Java/C#/etc). Don't get me wrong, it's cool that you have done stuff at a fairly early age.
:)
/. readers. I bet if you ask all of us what our first 'big/real' program we wrote was, the majority would answer that it had something to do with D&D. Mine, for example, was a character generation program and it used *all* the RAM of my machine... 4K, so I got a 16K expansion module and kept going and filled up all 20K! and was stored on a cassette tape! Man... things were so fun back then.
I started, for example, in middle school as well (~1980), but this was when not many people had home computers at all (that was before C64s, even). By the time I had graduated highschool, I had programmed in 3+ languages (6502 Assembly, BASIC, Pascal). Had there been networking, I would have done that as well, but dialup to BBSs was pretty much all we had (and null modems to connect computers together).
Back in the day, we also did a bit of work with hardware. I had been making my own cables for some time before I was 18. In '86, I started college and started playing around on the Internet with servers and such. I also built a computer from a handful of chips, some wires, and a breadboard (Z80 with some support chips/logic, communicated over serial to a PC) for fun (not class related - in higher level classes, we did these things again for class with a 68k but it was also still tons of fun).
Computers and playing with them was a lot more fun back then, IMO. Programming them and making the hardware you used (from cables to controller boards/etc) was the norm. These days, it's actually pretty simple in comparison, IMO... 'playing' with computers is basically using them and maybe programming them. The most hardware interaction anyone gets is plugging in a new video card, a new HDD, or plugging in a wire to a USB port. Maybe, if you're considered an 'enthusiast', you'll assemble your own, but that's really just plugging a bunch of boards together... not actually 'building' one like the 'enthusiasts' did back then
I'm sure my experiences aren't so different from many other
With the $10,000 prize, they could have picked whatever machine they thought was the easiest/fastest to hack (which they obviously did) and bought several MacBook Airs with the prize money.
Then why is RH whining about prying internal code from companies? Sounds like RH wants people to give them more software/features for free so RH can sell it and make money.
Yup, those are the two I focused on as well... drop those to zero and you cut the price by $6.80, which is 42% of the cost of the thing.
I've been writing multithreaded and parallel (MPP/MIMD) code for 20 years or so and there were plenty of people writing those kinds of codes long before I started. It's not exactly a new thing.
It's amazing that you can see past the end of your nose with your shortsightedness. Suppose all the company's equipment runs with CADbozoCAD and not BozoCAD? You are not only creating more work for yourself, because you have to convert to what the company uses because you're too ingrained in your own ego and superiority to learn something different (or maybe you're just unable to do that). Also, anything you produce is worthless to the company because they will be unable to maintain it and will have to redo everything you've done when the time comes to 'fix' anything. You are a lose-lose proposition for any company you work for.
Perhaps your attitudes are why you've been relegated to joining a temp placement organization instead of being able to find a permenant position?
Effortless parallelization for certain models of parallel programming, not all I'd wager. Producer/consumer, thread pools, etc, sure (task parallel). Data parallel is difficult because most of the problem there is partitioning the data properly and the inherent issues with synchronization (talking about MPP/MIMD type programs) and notification (message passing, for example), particularly when the data set is too large to fit in a single process or even on a single machine.
There's also the issue that clock speed isn't just running up a clock. It's distance (yeah, there are some things more than that, but it's basically how far the signal can travel at a given speed and be stable before it's latched). The distance the signal has to travel through the longest pipeline stage is the fastest that the clock can run without violation of setup/hold times and such. A single gate switch time is a bit faster than 3GHz or whatever we see. The thing is, the signal has to travel a ways through all those gates and stuff before it can be latched for the next pipeline stage.
Using the same process that Intel is using right now for Core2 parts, you could design a processor that runs much faster than 3GHz (hello P4) or you could design one so complex that it can only run at a few MHz because the longest paths prevent it. Run the clock too fast and the signal just doesn't have time to make it to the finish line, and then the best you can hope for is a hard crash. At worst, you can produce garbage from a calculation that get propagated right along. The problem is, sometimes it's difficult to notice when that happens.
This is probably more due to Intel's implementation of SMT in P4 than it was because of SMT in general. Ideally, you have two (or more) instruction streams that can be multiplexed on the granularity of execution units not being full from one stream and L1 cache misses. Think of for every clock cycle, the dispatcher optimally selecting instructions/micro-ops/macro-ops/whatever from both instruction streams such that all execution resources are busy (or as close as it can get... no FPU instructions in either stream ready for dispatch obviously leaves those resources idle, for example).
:)
In theory, this means having a full pipeline with all execution units busy all the time (or very near it). Intel's P4 implementation had issues with Replay logic. Basically, it would burn lots of cycles and resources re-executing somewhat speculatively the same instruction over and over until it could actually finish, filling the pipeline with replayed instructions (ones it is already attempting executing) rather than executing new instructions from the two SMT streams. Nehalem shouldn't have this issue if they don't have the pathological Replay (helped because of shorter pipeline length) and many more execution resources than the P4 has.
Just because Intel's first implementation of SMT was bad isn't an indicator that the entire technology is bad
I've never had a client approach me and say that they were willing to pay a certain amount, what could they do for me... usually, they say what they want and get a quote. You quote what you think they'll pay and if they aren't, then you don't get the job. You rarely, if ever, know how much they're *really* willing to pay.