harnessing 24% of available wave energy near the US at 50% efficiency is equal to all of the hydropower currently generated in the US (~7% of total electricity production).
Holy 1.21 jiggawatts, Batman! 24% of available wave energy "near" the US... How many miles of coastline are there in the USA? How many miles is 24% of that?
No... what is being said that if you make more noise about Microsoft doing this than any other company that does this exact thing, then you are a hypocrit.
There's nothing wrong with calling a company out for doing stuff like this. There is something wrong when you act like Microsoft is the only one that has ever done such a thing.
Well... IANAL, but if you knew someone broke the law and were asked to reveal who that person breaking the law was, aren't you guilty of Aiding and Abetting?
As far as your arguments about "write" and just laws, that doesn't apply here at all other than for you to fuel your "outrage". NDA falls under contractual law. An employee of Apple broke that contract. The web site knows who that is but doesn't want to tell. There is nothing unconstitutional or unfair here, unless you want to say that contractual law is suddenly invalid, in which case every other contract ever written is suddenly invalid.
While mutexes and CriticalSections are basically the same thing, CriticalSections are lots faster than mutexes (which require kernel context switches to manipulate).
I looked at them pretty deeply a few years ago and found no problems. While you may not be able to timeout on it, per se, you can do a loop with a microsleep in it to poll it if you really need that functionality (sleep for a millisecond in the loop), but as you say, this is not a good solution and you should use something else if you expect something to be locked forever and you'll need to timeout while waiting for it. If you have something that is locking a CriticalSection for long periods of time, then your problem is either doing something wierd (that long time of locking is going to be a serious bottleneck) or you are breaking the reason for using CriticalSections (lightweight atomic locking within a process where you know that a lock won't be held for long). Threads/processes that lock mutexes for longs periods of time are usually pathological in my experience.
If you've had problems with programs that used CriticalSections in the past, I imagine that there was something else going on.
Things I've implemented with CriticalSections: threadsafe queues, stacks, linked lists, a weird sort of priority double queue list thing (I'd have to describe the problem we were trying to solve to accurrately describe this thing), producer/consumer task queues, standard global data that required locking, and all sorts of things. I've also implemented these things with mutexes and binary semaphores on both Windows and various Un*xes and Un*x-alikes. I don't hesitate to use CriticalSections where they are a good fit.
It's actually gotten a lot better lately. Sticking to standard APIs is a start. Most of the time, man pages on Linux will tell you if it's Linux only or if Linux behaves a different way... one good example is for gettimeofday, the timezone structure never has and never will be surported by Linux, according to the documentation.
Unfortunately, there are a number of libraries for things that aren't portable. If you are planning to use some libraries to do something, make sure that they are supported on all the targets you think will use the software (sound and graphics being two).
Well... they also left out CriticalSections from Win32, which are really fast mutexes for threaded code (CriticalSections aren't shared across process boundaries but all the threads in a process can use them).
This is why commercial companies that don't give out source code directly will frequently enter a Code Escrow agreement with a client, for exactly these reasons. If the company that makes the software disappears for some reason, the client that has the Code Escrow gets a copy of all the source to continue to do with as they need in-house. Otherwise, the client doesn't get to see the code.
Another thing is where you've come from and what you expect. Spacecraft control (and the government sector as a whole) are quite different from commercial (I've worked for years in both). I've seen exactly what you've seen, but I've also seen somewhere buy several million $$ worth of Sun hardware and they've never asked for the source code for Solaris, for example, or Oracle.
We saw this way back in the day when Linux was just starting to gain interest. Back before Linux, most code was intentionally made portable across various Un*x variants. You could download the source, configure and make, and off you went. We started seeing lots of patches/fixes and new code written for Linux that didn't port at all. The most annoying thing was the patches/fixes that were put into source bases that were already portable that broke the portability. Linux coding was polluting the F/OSS (before it was called that) world. These simple issues caused us many headaches back in the day.
These issues are less today, but they still exist.... mostly because Linux is killing off the other Un*x and Un*x-clones. Enough people are using Linux and have only used Linux that they think they are doing good things but break things out of ignorance or simply write non-portable code when they think they are writing portable code.
"Back in the day", I worked on two different projects where portability was a concern. One was Un*x/Windows (two flavors of Un*x and Win32) and the other was Un*x only (but about 10 flavors). Not only did the code have to be portable, but the data had to be as well. This included file formats and having all the different systems on the 'net and working together simultaneously. It can (and has) been done but it takes a bit of work.
Also, testing isn't linear in difficulty... Two systems are harder than one system (three combinations... hetero- each type and then both together), but three is not "just a little harder" than two... it's a bit harder... (seven combinations).
Dual processor (dual socket) motherboards cost a bunch of money... not necessarily because the boards really cost 2X as much to make, but because they simply *can*. Companies that want/need dual/quad/etc machines will pay a premium to get them. Intel knows this, AMD knows this, Sun knows this, software companies know this, everybody knows this. There is a premium on multiprocessor machines and software that is designed to take advantage of multiple processors has a premium attached to it as well. Machines and software usually license by the socket (single-core processor) because they can charge a premium because those that need that functionality are willing to pay premiums to get it. Simply look at traditional costs of things like Windows 2000, Oracle, and plenty other pieces of software that charge by the CPU for licensing.
Now, with dual cores, especially since Intel and AMD seem to be going to push dual-core onto the desktop as the 'norm' instead of as an exception. This means that everyone will be able to get them (probably won't have much of a choice after some point). Now, all of those pieces of software that charged premiums for multiprocessing licenses have a problem. Usually, single processor versions of some software (Oracle, Windows, etc.) were pretty cheap comparitively. Going up to the next licensing stage for multiple processors is a big jump. So, software that normally ran on single processor computers at home and at workplaces will suddently be very expensive if you say that dual-core is the same as dual-processor (which it in all ways that really matter to a programmer and user is). Will home users and businesses with 'normal' computers on lots of desks willingly buy "server" versions of Windows 2000? or Oracle? or whatever? Their $99 piece of software per seat just magically jumped to something like $1500. Would YOU buy Windows XP (assuming you have before) for $499 now because you bought a dual-core machine?
Microsoft and everybody else knows that claiming dual-core is the same as dual-cpu and charging accordingly will not fly. Also, since to tell the difference between a dual-core machine and a 'regular' dual-socket board with single cores requires extra coding (have to look up CPUIDs and the like), how do you make people with dual-socket boards with single-core in each pay different prices than dual-core single-socket users? It's unfair and any company that did that would be blasted to smithereens in the marketplace. The only recourse is to say that licensing will be by the socket, not by the core.
This way, there is still a premium for dual socket boards, for the same reasons that there's a premium on them now. Software licensing and such can likewise retain their premium costs for multiple-socket boards. Single socket boards will still be cheap because the market demands it (even if there are two or more cores on the chip you put into that socket) and the software that runs on the single socket boards will continue to be cheap so that licensing fees do not suddenly get astronomical when dual-/multi-core is the only option.
Now, from the software side, there is very little functional difference between a board with two sockets and single-core processors in each socket and a board with one socket but two cores in that chip. There may be some performance implications but programming the things is still so similar as to require special code just to tell the difference, and then you wouldn't do anything with that knowledge except maybe charge different licensing fees.
Dual-core vs. dual processor, vs. whatever is all just marketing and making prices of software and hardware remain pretty much the same as they are today for those who don't want to pay the premiums for having multi-core machines (multi-core covers having multiple single-core processors or one or more multi-core processors).
The other "benefit" to these licensing schemes is that it will really push multiprocessing out the door into the masses (something Intel has been tryi
If you're going to have cell based devices job out stuff to execute on any nearby cell processors on the network, you're going to need a really good sandbox. One that's better than Java's which isn't that good. IBM's virtualization technology is more secure than anything else I've seen out there.
Heh... before you make the sandboxes you had better write a distributed OS for the things... and make sure that all devices with Cell in it are running that distributed OS.
Oh... and a distributed OS is a pretty hard thing to write and what feats have been attributed to the yet-to-be-seen distributed OS that runs on all these Cell machines make the distributed OS look like "hello world".
The CELL on the otherhand will have the instruction ordering done in software. All those 'bits' you describe are replaced with software: a much smarter compiler.
Yes this processor will perform poorly with today's code. With appropriately written code it will scream.
Hmmm... seems like I've heard this before... oh yeah... Intel's Itanium.
I've seen exactly these things as well. ADD != genius. The other problem that folks with ADD tend to have is the inability to coherently relate their ideas to others. While this may seem to some people that the ADD person's thoughts are somehow "mystical" and "genius" because "their thoughts are so high-up that they can't be accurrately explained to us mere mortals", it's really just that the concentration and thought processes that it requires to explain the ideas are time consuming and involved so the ADD person has a difficult time staying on track and being thurough.
I always thought it was more like the "Infinite number of monkeys..." thing. I mean... with all the "eyes" that are supposedly on OSS code kinda being like an "Infinite number..." and, well, the average OSS programmer probably kinda smells and acts like a "monkey"...;)
"This is a delicate bit of coding that is going to need to be tweaked by highly-paid coders for every single game."
I know that you are talking, sort of, about two different things, but they are related. While it may be "easy as pie" to add the hooks into your code to call what is essentially a library, making sure that library is scheduled, running, running in the right place and on the right data, and synchronized with everything else in the right ways, is the hard part (which you kind of glossed over in #4).
Another myth:
X. This architecture is "brand new" Personally, I worked on a system that was very similar to this but a little more discrete. The board had a single PPC microcontroller type CPU (integer only 32-bit) that was the 'boss' and also a single chip package of eight DSPs, all with their own local share of memory (not cache, but memory just like here) and each had some high speed DMA engines that connected each DSP to other DSPs in the package in a certain configuration. The 'boss PPC' would farm out tasks to the DSPs, which could work either singularly or in parallel with other DSPs (given the code as written) to crunch numbers. Other than advances in processes that have made the cores in the Cell have more features and functionality and the fact that the PPC was on a seperate chip from the DSPs, the architecture is very, very similar and, I will bet, the programming will be similar (it wasn't easy).
I didn't say it wasn't real. I'm saying that many people have heard the term "bloat" in the past and simply point to any large executable or Version+1 being bigger than Version and say "bloat". Simply because an executable is 2X as big as the previous version does not automatically mean that the code is 2X slower.
"Bloat" is used by a bunch of people who don't know what it means. If the code is bloated (as in a bunch of code for features that aren't used), then the code is never accessed by the CPU. That means it doesn't take up cache and it doesn't get executed. At most, it will take up some of main memory and cause longer load times but after the application is running, code that isn't executed eventually gets removed from even main memory. Simply having more code for more features doesn't do much unless the code is actually getting executed.
Well... some years ago, these "kludges" were considered state of the art, not shoehorned solutions that barely scrape by.
Perhaps the better way to phrase it is:
AMD has a better dual-core architecture than Intel.
The use of the word "kludge" is very subjective. I would agree with you that AMD's multiprocessing architecture (HyperTransport - AMD's dual-core architecture is just their multiprocessing architecture on one die) is superior to Intels current architecture (shared bus), but I do not agree that Intel's architecture is a "kludge" any more than any older (or obsolete) technology becomes a "kludge" when something newer and/or better comes along. Perhaps those who are using the term "kludge" actually mean to use "obsolete".
Actually, suspected pricing was released a few weeks ago, if you follow the rumor sites. Supposedly, dual-core 2.8 Smithfields will be about $250USD and going up from there.
I'm not sure where people keep getting the idea that dual core Intel parts are "kludges". They are kludges in the same vein as having two processors share the same bus, the way that the Xeons (P2 and up) have all shared the same bus. There's not a lot of magic there. It's pretty easy to do in the scheme of things but it isn't necessarily as efficient as other, more complicated ways of doing it. Basically, some Northbridge logic has moved into the package and onto the die to allow arbitration of the external bus to the dual core chip. That's about as simple as you can get and exactly mirrors the current (and past) Xeon multi-processor bus architecture.
I agree... it was actually a part of our class schedule in college. In high school, I tought myself 6502 assembly on an Apple ][+ and I learned M68000 family and MC6800/6809/6811 assembly some on my own but some for classes. Later, I dallied in PPC and SPARC and a touch of MIPS. I think many programmers would benefit from retaking data structures in assembly:)
However, the fact is that there isn't that much call for assembly outside of embedded systems these days.
PS: I'm trying to decide whether or not I want to learn x86-64 assembly. I'm afraid it might be too much like x86 which I think is just ugly, but I haven't looked at it enough to decide yet.
I have nothing against the Mac, although your suggestion that it is "current or trendy" is somewhat subjective:)
If someone wanted to pay me to develop on a Mac, I'd get one without batting an eye. If Macs became a major part of the software market, I wouldn't hesitate to get one. It just doesn't meet any of my criteria at the moment to get one.
Also, I don't really need a computer to be sexy... I have a wife for that:) I would like to be able to justify an Athlon64 laptop, though, to run SuSE 9.2 Professional AMD64 on though. I really like it on one of my AMD64s at home.
Slashdot Mirror
harnessing 24% of available wave energy near the US at 50% efficiency is equal to all of the hydropower currently generated in the US (~7% of total electricity production).
Holy 1.21 jiggawatts, Batman! 24% of available wave energy "near" the US... How many miles of coastline are there in the USA? How many miles is 24% of that?
No... what is being said that if you make more noise about Microsoft doing this than any other company that does this exact thing, then you are a hypocrit.
There's nothing wrong with calling a company out for doing stuff like this. There is something wrong when you act like Microsoft is the only one that has ever done such a thing.
Well... IANAL, but if you knew someone broke the law and were asked to reveal who that person breaking the law was, aren't you guilty of Aiding and Abetting?
As far as your arguments about "write" and just laws, that doesn't apply here at all other than for you to fuel your "outrage". NDA falls under contractual law. An employee of Apple broke that contract. The web site knows who that is but doesn't want to tell. There is nothing unconstitutional or unfair here, unless you want to say that contractual law is suddenly invalid, in which case every other contract ever written is suddenly invalid.
While mutexes and CriticalSections are basically the same thing, CriticalSections are lots faster than mutexes (which require kernel context switches to manipulate).
I looked at them pretty deeply a few years ago and found no problems. While you may not be able to timeout on it, per se, you can do a loop with a microsleep in it to poll it if you really need that functionality (sleep for a millisecond in the loop), but as you say, this is not a good solution and you should use something else if you expect something to be locked forever and you'll need to timeout while waiting for it. If you have something that is locking a CriticalSection for long periods of time, then your problem is either doing something wierd (that long time of locking is going to be a serious bottleneck) or you are breaking the reason for using CriticalSections (lightweight atomic locking within a process where you know that a lock won't be held for long). Threads/processes that lock mutexes for longs periods of time are usually pathological in my experience.
If you've had problems with programs that used CriticalSections in the past, I imagine that there was something else going on.
Things I've implemented with CriticalSections: threadsafe queues, stacks, linked lists, a weird sort of priority double queue list thing (I'd have to describe the problem we were trying to solve to accurrately describe this thing), producer/consumer task queues, standard global data that required locking, and all sorts of things. I've also implemented these things with mutexes and binary semaphores on both Windows and various Un*xes and Un*x-alikes. I don't hesitate to use CriticalSections where they are a good fit.
It's actually gotten a lot better lately. Sticking to standard APIs is a start. Most of the time, man pages on Linux will tell you if it's Linux only or if Linux behaves a different way... one good example is for gettimeofday, the timezone structure never has and never will be surported by Linux, according to the documentation.
Unfortunately, there are a number of libraries for things that aren't portable. If you are planning to use some libraries to do something, make sure that they are supported on all the targets you think will use the software (sound and graphics being two).
Well... they also left out CriticalSections from Win32, which are really fast mutexes for threaded code (CriticalSections aren't shared across process boundaries but all the threads in a process can use them).
This is why commercial companies that don't give out source code directly will frequently enter a Code Escrow agreement with a client, for exactly these reasons. If the company that makes the software disappears for some reason, the client that has the Code Escrow gets a copy of all the source to continue to do with as they need in-house. Otherwise, the client doesn't get to see the code.
Another thing is where you've come from and what you expect. Spacecraft control (and the government sector as a whole) are quite different from commercial (I've worked for years in both). I've seen exactly what you've seen, but I've also seen somewhere buy several million $$ worth of Sun hardware and they've never asked for the source code for Solaris, for example, or Oracle.
We saw this way back in the day when Linux was just starting to gain interest. Back before Linux, most code was intentionally made portable across various Un*x variants. You could download the source, configure and make, and off you went. We started seeing lots of patches/fixes and new code written for Linux that didn't port at all. The most annoying thing was the patches/fixes that were put into source bases that were already portable that broke the portability. Linux coding was polluting the F/OSS (before it was called that) world. These simple issues caused us many headaches back in the day.
These issues are less today, but they still exist.... mostly because Linux is killing off the other Un*x and Un*x-clones. Enough people are using Linux and have only used Linux that they think they are doing good things but break things out of ignorance or simply write non-portable code when they think they are writing portable code.
"Back in the day", I worked on two different projects where portability was a concern. One was Un*x/Windows (two flavors of Un*x and Win32) and the other was Un*x only (but about 10 flavors). Not only did the code have to be portable, but the data had to be as well. This included file formats and having all the different systems on the 'net and working together simultaneously. It can (and has) been done but it takes a bit of work.
Also, testing isn't linear in difficulty... Two systems are harder than one system (three combinations... hetero- each type and then both together), but three is not "just a little harder" than two... it's a bit harder... (seven combinations).
Dual processor (dual socket) motherboards cost a bunch of money... not necessarily because the boards really cost 2X as much to make, but because they simply *can*. Companies that want/need dual/quad/etc machines will pay a premium to get them. Intel knows this, AMD knows this, Sun knows this, software companies know this, everybody knows this. There is a premium on multiprocessor machines and software that is designed to take advantage of multiple processors has a premium attached to it as well. Machines and software usually license by the socket (single-core processor) because they can charge a premium because those that need that functionality are willing to pay premiums to get it. Simply look at traditional costs of things like Windows 2000, Oracle, and plenty other pieces of software that charge by the CPU for licensing.
Now, with dual cores, especially since Intel and AMD seem to be going to push dual-core onto the desktop as the 'norm' instead of as an exception. This means that everyone will be able to get them (probably won't have much of a choice after some point). Now, all of those pieces of software that charged premiums for multiprocessing licenses have a problem. Usually, single processor versions of some software (Oracle, Windows, etc.) were pretty cheap comparitively. Going up to the next licensing stage for multiple processors is a big jump. So, software that normally ran on single processor computers at home and at workplaces will suddently be very expensive if you say that dual-core is the same as dual-processor (which it in all ways that really matter to a programmer and user is). Will home users and businesses with 'normal' computers on lots of desks willingly buy "server" versions of Windows 2000? or Oracle? or whatever? Their $99 piece of software per seat just magically jumped to something like $1500. Would YOU buy Windows XP (assuming you have before) for $499 now because you bought a dual-core machine?
Microsoft and everybody else knows that claiming dual-core is the same as dual-cpu and charging accordingly will not fly. Also, since to tell the difference between a dual-core machine and a 'regular' dual-socket board with single cores requires extra coding (have to look up CPUIDs and the like), how do you make people with dual-socket boards with single-core in each pay different prices than dual-core single-socket users? It's unfair and any company that did that would be blasted to smithereens in the marketplace. The only recourse is to say that licensing will be by the socket, not by the core.
This way, there is still a premium for dual socket boards, for the same reasons that there's a premium on them now. Software licensing and such can likewise retain their premium costs for multiple-socket boards. Single socket boards will still be cheap because the market demands it (even if there are two or more cores on the chip you put into that socket) and the software that runs on the single socket boards will continue to be cheap so that licensing fees do not suddenly get astronomical when dual-/multi-core is the only option.
Now, from the software side, there is very little functional difference between a board with two sockets and single-core processors in each socket and a board with one socket but two cores in that chip. There may be some performance implications but programming the things is still so similar as to require special code just to tell the difference, and then you wouldn't do anything with that knowledge except maybe charge different licensing fees.
Dual-core vs. dual processor, vs. whatever is all just marketing and making prices of software and hardware remain pretty much the same as they are today for those who don't want to pay the premiums for having multi-core machines (multi-core covers having multiple single-core processors or one or more multi-core processors).
The other "benefit" to these licensing schemes is that it will really push multiprocessing out the door into the masses (something Intel has been tryi
Yeah, that 25x reminds me of a CM-2 (ConnectionMachines), the main difference being that I (and others) actually wrote and ran code on the CM-2.
If you're going to have cell based devices job out stuff to execute on any nearby cell processors on the network, you're going to need a really good sandbox. One that's better than Java's which isn't that good. IBM's virtualization technology is more secure than anything else I've seen out there.
Heh... before you make the sandboxes you had better write a distributed OS for the things... and make sure that all devices with Cell in it are running that distributed OS.
Oh... and a distributed OS is a pretty hard thing to write and what feats have been attributed to the yet-to-be-seen distributed OS that runs on all these Cell machines make the distributed OS look like "hello world".
The CELL on the otherhand will have the instruction ordering done in software. All those 'bits' you describe are replaced with software: a much smarter compiler.
Yes this processor will perform poorly with today's code. With appropriately written code it will scream.
Hmmm... seems like I've heard this before... oh yeah... Intel's Itanium.
I've seen exactly these things as well. ADD != genius. The other problem that folks with ADD tend to have is the inability to coherently relate their ideas to others. While this may seem to some people that the ADD person's thoughts are somehow "mystical" and "genius" because "their thoughts are so high-up that they can't be accurrately explained to us mere mortals", it's really just that the concentration and thought processes that it requires to explain the ideas are time consuming and involved so the ADD person has a difficult time staying on track and being thurough.
I always thought it was more like the "Infinite number of monkeys..." thing. I mean... with all the "eyes" that are supposedly on OSS code kinda being like an "Infinite number..." and, well, the average OSS programmer probably kinda smells and acts like a "monkey"... ;)
Your points #4 and #6 almost conflict...
"Easy as pie."
and
"This is a delicate bit of coding that is going to need to be tweaked by highly-paid coders for every single game."
I know that you are talking, sort of, about two different things, but they are related. While it may be "easy as pie" to add the hooks into your code to call what is essentially a library, making sure that library is scheduled, running, running in the right place and on the right data, and synchronized with everything else in the right ways, is the hard part (which you kind of glossed over in #4).
Another myth:
X. This architecture is "brand new" Personally, I worked on a system that was very similar to this but a little more discrete. The board had a single PPC microcontroller type CPU (integer only 32-bit) that was the 'boss' and also a single chip package of eight DSPs, all with their own local share of memory (not cache, but memory just like here) and each had some high speed DMA engines that connected each DSP to other DSPs in the package in a certain configuration. The 'boss PPC' would farm out tasks to the DSPs, which could work either singularly or in parallel with other DSPs (given the code as written) to crunch numbers. Other than advances in processes that have made the cores in the Cell have more features and functionality and the fact that the PPC was on a seperate chip from the DSPs, the architecture is very, very similar and, I will bet, the programming will be similar (it wasn't easy).
I didn't say it wasn't real. I'm saying that many people have heard the term "bloat" in the past and simply point to any large executable or Version+1 being bigger than Version and say "bloat". Simply because an executable is 2X as big as the previous version does not automatically mean that the code is 2X slower.
Yes, but hopefully this isn't a significant portion of your code :) OO languages may actually lessen the effect of that in some cases :)
"Bloat" is used by a bunch of people who don't know what it means. If the code is bloated (as in a bunch of code for features that aren't used), then the code is never accessed by the CPU. That means it doesn't take up cache and it doesn't get executed. At most, it will take up some of main memory and cause longer load times but after the application is running, code that isn't executed eventually gets removed from even main memory. Simply having more code for more features doesn't do much unless the code is actually getting executed.
Well... some years ago, these "kludges" were considered state of the art, not shoehorned solutions that barely scrape by.
Perhaps the better way to phrase it is:
AMD has a better dual-core architecture than Intel.
The use of the word "kludge" is very subjective. I would agree with you that AMD's multiprocessing architecture (HyperTransport - AMD's dual-core architecture is just their multiprocessing architecture on one die) is superior to Intels current architecture (shared bus), but I do not agree that Intel's architecture is a "kludge" any more than any older (or obsolete) technology becomes a "kludge" when something newer and/or better comes along. Perhaps those who are using the term "kludge" actually mean to use "obsolete".
Actually, suspected pricing was released a few weeks ago, if you follow the rumor sites. Supposedly, dual-core 2.8 Smithfields will be about $250USD and going up from there.
I'm not sure where people keep getting the idea that dual core Intel parts are "kludges". They are kludges in the same vein as having two processors share the same bus, the way that the Xeons (P2 and up) have all shared the same bus. There's not a lot of magic there. It's pretty easy to do in the scheme of things but it isn't necessarily as efficient as other, more complicated ways of doing it. Basically, some Northbridge logic has moved into the package and onto the die to allow arbitration of the external bus to the dual core chip. That's about as simple as you can get and exactly mirrors the current (and past) Xeon multi-processor bus architecture.
Depends what the threads are doing...
I agree... it was actually a part of our class schedule in college. In high school, I tought myself 6502 assembly on an Apple ][+ and I learned M68000 family and MC6800/6809/6811 assembly some on my own but some for classes. Later, I dallied in PPC and SPARC and a touch of MIPS. I think many programmers would benefit from retaking data structures in assembly :)
However, the fact is that there isn't that much call for assembly outside of embedded systems these days.
PS: I'm trying to decide whether or not I want to learn x86-64 assembly. I'm afraid it might be too much like x86 which I think is just ugly, but I haven't looked at it enough to decide yet.
I have nothing against the Mac, although your suggestion that it is "current or trendy" is somewhat subjective :)
:) I would like to be able to justify an Athlon64 laptop, though, to run SuSE 9.2 Professional AMD64 on though. I really like it on one of my AMD64s at home.
If someone wanted to pay me to develop on a Mac, I'd get one without batting an eye. If Macs became a major part of the software market, I wouldn't hesitate to get one. It just doesn't meet any of my criteria at the moment to get one.
Also, I don't really need a computer to be sexy... I have a wife for that
Yeah... for all the people who write assembly these days....
I've written PPC assembly but no x86. I've never been a fan of x86 but these days, so few people program in assembly it's not an issue.