Couldn't see details, but this may use Sun's hypertransport switch as an interconnect. Until Intel's next generation of chips with QPI, you couldn't do that sort of interconnect with Intel processors. Admittedly though, I'm not convinced that it is significant enough a benefit over recent Infiniband solutions despite the penalty of going through an Infiniband chip and then a PCI express controller.
Even with the L3 errata straightened out, it still looks to be a rough road for AMD, who hasn't demonstrated clock-for-clock performance up to Core 2 yet, and also has lower clock speeds to boot. Unless AMD pulls something dramatic, it will be hard to justify AMD in supercomputing once Intel goes to QPI. They can pull off price-performance tricks to some extent, but in large deployments the power/cooling penalty is non-trivial.
I see that as a reason not to open source the existing drivers, but not to preclude releasing the details needed by the open source community to produce an open driver with their own shader programs, which may be lower performance, but good enough for default operation for a lot of distributions.
I find an interesting perspective being hinted at by AMD in this context. That they approach a common open source layer at the low level, and plug in their proprietary 'good stuff' as a replacement for higher layer things. As an example, they feel their powerplay stuff isn't top secret, so putting it at a layer where everyone can bang on it and improve it is ideal for everyone. Same with things like display handling. AMD and nVidia both do bizarre things requiring proprietary tools to configure display hotplug, instead of the full xrandr feature set, which has grown to include display hot plug.
In general, there are *many* things AMD has historically gotten wrong in their drivers. Mostly with respect to power management, suspend, stability with arbitrary kernels/X servers. One thing they seem to do better relative to the open source community is good 3D performance if all the underlying stuff happens to line up. If they can outsource the basic, but potentially widely varying work to the community, it would do wonders if their driver architecture lets them leverage that. And by giving open source 3D developers a chance to create a full stack, it's the best of all worlds. I would be delighted to see the Open Source 3D stack surpass the proprietary stack, but wonder what patents stand in the way of that being permitted...
You completely looked like an idiot declaring the parent is commiting two felonies by posting. Random slashdot post asserting that the author considers stock in lieu of money for part of an exchange to be 'funny money' is nothing more than an opinion and certainly is not talking up or down stock.
Secondly, speculating that it is 'likely' that the pension fund shareholders are somehow part of the MS plan isn't slander, it's just speculation. I concur whether directly or indirectly, this plays into the plan well. Maybe MS didn't approach anyone specific, but it doesn't take much foresight to know such a superficially outrageous deal will either be accepted or outrage to the point of lawsuit some set of shareholders. I would wager MS did not approach a single shareholder, but I wouldn't be surprised if they fully expected a refusal to meet with litiguous action from enough of the shareholders.
As to burying work on BSD/PHP/Zimbra, It's an obvious conclusion. The difference with FrontPage and Visio was there were no MS products being threatened by it. FrontPage ties in with the IE strategy and Visio a logical complement for the Office offering. BSD work *obviously* is not in MS's remote interest to help out, as with PHP. BSD is a Windows competitor and PHP is too OS/http server indepedent for their tastes to bother when they have a host of things already. Similarly, Zimbra has nothing over Exchange MS wants. Zimbra allows independence from Windows on the server side and client side for any who implement it, but otherwise it doesn't offer that much different from Exchange. I would wager they would offer some special 'upgrade' deal to Zimbra commercial users to Exchange and then be done with it. BSD/PHP wouldn't die, but would suffer development issues. Zimbra given its nature would be killed outright.
I'm not saying MS was explicitly targeting BSD/PHP/Zimbra in its bid to fend off OS/language/Exchange competitors, it's clear the bid is a desperate move against Google. By the way, it comes off like an unhealthy obsession with Google on the part of MS leadership, more than a sound business decision. BSD/PHP/Zimbra are incidentals that demonstrate the sale should be blocked by regulatory agencies, but from MS's perspective, they are either not even on the business people's radar or are mere bonus afterthoughts. From a certain perspective, it may have been a wise thing to decline the initial outrageous bid, knowing it was high risk with respect to regulatory agencies, and then exploit the exposure to get a more likely, but less lucrative situation elswhere..
I concur that certain people can be fantastic all star managers/executives. I can also concede that without the correct non-technical leadership, a project can fall apart (wrong leadership can drive it into the ground, no leadership means the technical pursuit of things may never be pulled into a realisticly usable product, with features always being chased by the technical people who want the challenge.)
However, by the same token, for every project with a clear leader who organized the success, you can probably identify some technical architect/developer with the driving technical vision that was absolutely needed to be the foundation of the project. Someone who didn't *explicitly* manage people in any business sense, but still laid out exactly how it would all play out from the technical standpoint. Though I am aware of a precious few who repeatedly shine in this context, I never hear about those people getting multi-million dollar signing bonuses or golden parachutes. Half the time, they get thoroughly pushed to the background as the executive type has the praise lavished on for the great work they personally did. The only time I see it happen is when they surrender and turn into a business type. Quite frequently I see people start down the path only after proving a lack of technical competence, and quickly out pace their technical seniors just by being on a business track rather than a technical track.
The problem with your switchless proposal is that you presume two ports of network connectivity per node and that all can be dedicated to inter-node communication. It's then hardly useful as there is no way to uplink it to transfer meaningful work/results in and out. I guess your answer would be to slap an ethernet card, but at three nodes, why bother, particularly if you are advocating on board NICs as the interconnect.
In any event, the penalty of an ethernet switch at small scale is negligible (latency increase on a decent swich would maybe 2 usec when the system latency of the two nodes in ethernet is commonly in the 40 usec range, and only really contrived situations will be meausurably impacted, and even then the difference will be low. There are interconnects that get in the 2 usec range total for latency penalty on those contrived cases, but that's far more expensive than the onboard NICs.
The system mentioned has infiniband ports, and you could ignore the ethernet, so you could use those instead. But considering the exorbitant cost of Infiniband cables and your stated limited budget restriction, it's going to be hard to use those with or without a switch Further, if using the IB ports, the fabric would tolerate an additional hop, so the relative penalty of two hop communications isn't bad there either.. The same can be said of bridging the ethernet ports so each node is also a low-port count switch, but I can't speak to the performance characteristics of that. Especially with a mere three nodes, the workload of clustered applications won't even notice the difference in your convoluted node interconnect vs. something more generally configured.
In other words, a three-socket motherboard with infiniband is going to cost you a lot to get not significantly better performance than cobbling together something of more mainstream nature that will scale to 8 or 24 nodes (depending on if you want an 8 or 24 port switch, 48 port starts getting pricier).
The reason for the three socket server being able to boast the direct connection is an artifact of AMD's design. The processors in question had only two coherent HT links, and thus a processor with more coherent links could be used to construct fully connected designs with more members (i.e. 3 coherent links allows a fully connected quad socket). Anyway, as nice and symmetric as it sounds, the problem is overwhelmingly, the performance penalty of the occasional two hop access pales in comparison to having 33% more processor available to crunch in the scenarios where you would care about the minor degradation of a two hop access. Now all this was presuming it would be possible to build such a system with a Phenom, but it simply isn't. It isn't until the third tier of Opteron (single socket capable (1000 series), dual socket capabable (2000 series), 'more' socket capable (8000 series) that the number of HT links usable for inter-processor links permits that design.
It has no relevance to AMDs quad-core design internally, the cores are no worse off communication wise than the triple cores. It has no relevance to a cluster, where it's hard to imagine *any* node interconnect that would care about having 3 vs. 4 nodes in it.
Those are facilities for programs to request particular behavior changes of the way the system scheduler does thing. Overwhelmingly, there is next to zero reason to adjust this in most applications. A good scheduler makes the best choices for the vast majority of cases.
That said, depending on the implementation, optimizations may be missed by certain vintages of particular schedulers. For example, a process might be suboptimally put on a core without access to the L2 cache that it had last go around. In a more esoteric case, if you are doing something highly IO intensive on a dual socket AMD system, it may be helpful to scehdule it on a core on the socket wired to the system chipset rather than one a hope away. In a NUMA machine, tending to run your process on the processor where your allocations are local is healthy in general, but most NUMA-aware schedulers explicitly know that basic optimization.
His point though was that applications don't have to do anything all that exotic to see the bulk of the benefit from reasonable number of cores. The affinity mechanisms given in most scenarios a developer may actually shoot themselves by thinking they know better than the scheduler, and even for cases where a programmer *does* know something about the system/application the kernel does not, the gain for the esoteric stuff is generally in the single digit percentages. Even on single threaded applications, under typical desktop load, quad core can help. I just checked at random and I had three processes in run state, but it's not uncommon for more processes with greater demand to peak concurrently.
I logged into some friends' machines (where I don't have root access) and used that program to fix it. I love code that uses an exploit to fix said exploit.
See, the exploit is a feature, it allows friends to patch your system... yeah..
Dump the entire memory contents, and you probably store data you don't care about, being even more wasteful of resources than XML. If it was so painless, why would every modern framework explicitly deal with special calls to serialize objects? What if you dump the memory space of some object on an x86 and try to restore it on a ppc, which differs in endianness? What if you try to load it on a system with different data type sizes and the alignments mess up? What if you update your program to add a member to a struct, and suddenly you've corrupted the meaning of your binary save data from previous iterations?
I'm not saying XML is the best answer or by simply saying 'XML' problems go away, you always have to do something and many different frameworks/facilities in various languages exist to help. You have to do something more than open a file handle and start dumping from memory addresses to that file handle. You have to either think carefully or choose a tool that let's you be fairly straightforward and preserve your options going forward.
That we can't have quad core Intel processors, since Intel has to manufacture chips for laptops which need lower power utilization than is currently not feasible with quad core. Oh wait, Intel manufactures different variations of the same architecture to suit different products/environments. Power chips, likewise, are used in tiny embedded appliances with low TDP and other crippling situations, but also at extremely high TDP in Unix servers, with many more capabilities.
It's obviously a bad move to presume IBM would be so stupid as to lock themselves into only ever implementing one specific instance of a design without variation if they want to deviate. I agree with the other post, seemingly pointing and laughing at IBM over this 'limitation' is going to backfire if IBM considers it a viable platform outside of gaming and releases a serious variant of the product as this advancement gets rolled out in parallel.
Doesn't it just seem *bizarre* that to this day we see filesystems in microsoft tied to rather archaic looking drive letters? Looking at his various traces and everything having an arbitrary letter to identify what filesystem it originates just seems kinda lame.
Unfortunately, it Looks like my network is more Awesome (over a septillion hosts, and less than one in a trillion chance it would conflict with my neighbor's)
I would disagree with your characterization of the migration to P4 to core as 'quick'. I would also not declare Intel successfully turning around a product that was competitive across the board with AMD until Core 2, when they pulled in the good instruction per clock and the 64 bit instruction sets all together. It took years for Intel to develop something that *almost* completely dominates the AMD equivalents (one could still make a case for the AMD memory architecture at scale, which Intel will counter with QPI this year). And the clock didn't start ticking until AMD forced their hand.
If it takes a company like Intel years to crank out something like that, a company with debatably the top notch fabrication capabilities in the world, what are nVidia's chances, given that only now they are feasibly able to leverage 65 nm fabrication processes for manufacture of their chips. Fabrication processes aren't everything, but it is a decent indicator of how the cards would be stacked for nVidia going into that market.
I personally would love to see nVidia enter the market with a viable offering, if only because I fear AMD is blowing the situation and the market desperately needs comparable vendors to compete, but I'm not optimistic about nVidia's capabilities.
If I ignore the incidentals for the moment (which I fear regulatory agencies might do), I'd be looking strictly at the online presence situation of the market. MS can't buy google, so is settling for yahoo. The fact that the resultant online presence of MS and Yahoo would still trail dramatically Google (even assuming some people wouldn't abandon yahoo, which they would). The fact is they can't buy off a majority as it stands, and most people observing don't see how MS could possibly use this as a way to pass Google, and as such, in the apparent point of the whole thing, it appears to be a dead end. The stuff that the mass media/most people don't even know about that can be classified as competitors in realms where MS maintains a monopoly will be what suffers.
MS shouldn't be allowed to do this due to their monopoly status. My fear is that too much focus will be placed on the primary mission of yahoo (trying to compete with Google), and not enough on the incidentals. You can bet MS would dismantle as soon as possible use and development of many open source technologies, such as Zimbra, FreeBSD, and php. Yahoo plays huge roles in those projects, and this deal could significantly impact those projects for the worse.
At the very least, the Zimbra vs. Exchange situation needs a hard look, since yahoo drives that project entirely and productizes it as an Exchange competitor.
Comparing what can be done in a Notes app with what can be built on the web is a very poor comparison and only valid for badly written corporate apps I think you give Webapps a bad wrap here. Just as you say it takes a good developer to leverage Notes architecture appropriately, the same can be said of web developers. A good web development team can deliver incredible results for arbitrary applications. Wat is a good example of an application that can't be usefully done in a web application that is better done in Notes versus a standalone application? To state my notes experience, I've seen things from a timecard application that I re-implemented as a web application for users without a client at the time (writing an agent to dump the notes data into the same data source), to a voicemail interaction system (again, wrote an agent to forward the relevant data from that company's backend to a source amenable to web access, as the company used clients without notes support at the time), to collaborative documents best served by either a plain old filespace with html indexes or something more encompassing like a wiki. Domino at the time when I wrote agents to manipulate the data did a fine job, but most of my work was getting out of requiring the notes client in a shop that had gotten Lotus lock-in and was regretting it.
Again, that so totally misses the point of Notes. If the point of Notes is to be even more ubiquitous than a web browser, to be as ubiquitous as a window manager, why bother integrating with the desktop look and feel? Why confine itself to a single window? Why not release an OS variant that does nothing more than start a GUI with a notes instance fullscreened? I'm not seeing what Notes yet brings to the table in terms of client side experience that isn't implementable with the tools the layer underneath (OS platforms) gives. Sure, I could let Writer/Calc etc run under the Lotus instance, but I have not seen a concrete benefit to that vs. the same program opening outside of Notes.
A lot of your response speaks to the server side of things, and I haven't touched the server side since R6, so I can't comment to that.
I think saying 90% live in it is an overstatement.
-A good chunk (more than 10%) of notes users only ever touch email and calendaring. I would guess on personal experience, a great majority are in this camp, but won't absolutely claim it. -Even looking beyond to companies that actual use the bits of Notes that are kind of unique (for the most part web applications without the web), I would bet a vast majority of those users do day to day work outside of notes, and use notes for the occasional internal application (maybe time card, putting documents into a database that's more awkward than a simple file share without real benefit). Bringing in OpenOffice raises it somewhat (I think I'd need to change jobs if I 'lived' in office applications), but beyond file save and load integrated into notes, it just slows down OpenOffice.
The problem is that Lotus software appears to shrug off significant memory utilization, storage utilization, and startup performance. Like you, they seem to think theirs is the only set of applications that matter, and that a computers entire point in life is to run their application suite and a user should only use it too. As such, why not suck up the memory and have ungodly load times? The truth is Notes is not my OS, it is not my 'desktop environment', it is an application. Even at its most ambitious, it is peer to a web browser. No web browser dares to have the general performance characteristics of a Lotus application, despite having a much closer to legitimate (but would still not be) claim to having typical users 'living' in their application.
Even putting aside those assumptions, running only notes and leaving it up all the time, it's still a sluggish application UI wise compared with the competition. This is even giving the benefit of client stored replica. Evolution connected to a slow IMAP server is obvious, but not grating. It immediately responds UI wise with obvious visual queues that it's interacting with the server, but allowing you to use other bits of the app while that happens. I.e., hit delete in notes, the app hangs until the server or file operation completes. Do the same in evolution, poof, the operation is denoted with strikethrough text and you go about your business while the 'heavy' lifting takes place, cleanly updating the UI on true completion by removing the entry.
I must ask, what version and what platform are you running notes on, for comparison? I've had the experience on my laptop (Ubuntu, dual core, but not that special) and my overpowered workstation (running RHWS5.1). Are you talking about opening notes8 after already running it (i.e. memory resident, or at the very least resident in disk cache the ludicrous amount of data it wants to pull from disk?).
Load time aside, what is the latency for clicking on a calendar entry to the time it is displayed? It doesn't sound like much if you put it to numbers, but it takes the better part of a second to a couple of seconds for me in notes to have the results after clicking. Same with doing mail operations. I can do many operations in evolution, and even if the mail server is in the picture and sluggish, the UI is immediately responsive, lets you continue, and intuitively denotes a queued deletion operation, for example, with strikethrough text.
My problem with Notes 8 is not that it isn't 'pretty' enough. My complaint is that it is an *unbelievable* amount of overhead for fulfilling its core function, email and calendaring. Software developers seem to cream themselves over the fact it is an eclipse platform, but the rest of the world stuck using the damn thing for email, that's zero comfort. There's no effort to provide a streamlined core client for the core function, just effort to make it even slower because some IBM managers/developers see that as the only path to progress.
Notes and Sametime clients both suffer this. Notes consumes 256 MB of my memory (yes, resident memory). Evolution 28M (not light weight, but still). Notes takes a long time to start and do any little operation (this machine is an 8 core system with 16GB of RAM, should be plenty). I haven't run Sametime client in a while, but I remember it taking ~50 seconds to start, and sucking up 128M of ram on it's own. It admittedly didn't feel slow once up and running, at least, though it did a terrible job of managing the WM hints (it would keep blinking in the window list despite acknowledging the message). Meanwhile, pidgin does *everything* pretty much right with a modest footprint and instantaneous start.
But I'm recommending all my business customers to stear clear of any proprietary thick-client-server groupware. I mostly agree, but would like to add using open, yet application specific protocols as available. Sure, have your ubiquitous webmail client, but it's so trivial to have both webmail and imap access. Webmail email clients more often are more awkward to use.
I am surprised at companies willingness to go with a Domino/Notes. It would be one thing if the application suite were rich and nice to use, but it isn't and webapps have in the meantime improved to have less awkwardness than Notes. I don't like acceptance of Exchange/Outlook (extreme vendor-lockin, significant cost), but at least the client isn't horrible.
I'm surprised open-standards based applications haven't gotten more traction. IMAP, CalDAV, and Jabber are decent protocols for their respective fields, but people still use Domino, Exchange, Sametime, and MS Communicator and volunteer for vendor lock-in.
R8 is pretty much sitting on top of Eclipse. Speaking as a Notes user (a Linux Notes 8 user at that), that really didn't help Notes significantly from my perspective. In terms of applications, I don't see how Notes 8 increases the skill of developers, but then again, that's not my chief gripe.
Notes always has been excruciatingly sluggish, bloated, and awkward. Putting it on top of eclipse made it that much worse. It feels like molasses on my system. This is working with local replicas of databases (eliminating the slow network) and on a ludicrously overpowered workstation (16 GB RAM, 8 cores, admittedly the hard drive setup is merely a mirror of 500 GB drives, but no other piece of software seems to mind).
I speak not as someone who actually has to use those annoying 'applications' written on the Notes platform by random people (just make a damn webapp people), but as someone who for the most part just needs it as an email client. For those who say 'but it isn't *just* an email client', that may be true, however, a primary function it is intended to fulfill should not be so user-antagonistic. Also, if the core function it means to fulfill with all the developer attention available can't be made pleasant, then it says unfortunate things about the platform.
Slashdot Mirror
Couldn't see details, but this may use Sun's hypertransport switch as an interconnect. Until Intel's next generation of chips with QPI, you couldn't do that sort of interconnect with Intel processors. Admittedly though, I'm not convinced that it is significant enough a benefit over recent Infiniband solutions despite the penalty of going through an Infiniband chip and then a PCI express controller.
Even with the L3 errata straightened out, it still looks to be a rough road for AMD, who hasn't demonstrated clock-for-clock performance up to Core 2 yet, and also has lower clock speeds to boot. Unless AMD pulls something dramatic, it will be hard to justify AMD in supercomputing once Intel goes to QPI. They can pull off price-performance tricks to some extent, but in large deployments the power/cooling penalty is non-trivial.
I see that as a reason not to open source the existing drivers, but not to preclude releasing the details needed by the open source community to produce an open driver with their own shader programs, which may be lower performance, but good enough for default operation for a lot of distributions.
I find an interesting perspective being hinted at by AMD in this context. That they approach a common open source layer at the low level, and plug in their proprietary 'good stuff' as a replacement for higher layer things. As an example, they feel their powerplay stuff isn't top secret, so putting it at a layer where everyone can bang on it and improve it is ideal for everyone. Same with things like display handling. AMD and nVidia both do bizarre things requiring proprietary tools to configure display hotplug, instead of the full xrandr feature set, which has grown to include display hot plug.
In general, there are *many* things AMD has historically gotten wrong in their drivers. Mostly with respect to power management, suspend, stability with arbitrary kernels/X servers. One thing they seem to do better relative to the open source community is good 3D performance if all the underlying stuff happens to line up. If they can outsource the basic, but potentially widely varying work to the community, it would do wonders if their driver architecture lets them leverage that. And by giving open source 3D developers a chance to create a full stack, it's the best of all worlds. I would be delighted to see the Open Source 3D stack surpass the proprietary stack, but wonder what patents stand in the way of that being permitted...
You completely looked like an idiot declaring the parent is commiting two felonies by posting. Random slashdot post asserting that the author considers stock in lieu of money for part of an exchange to be 'funny money' is nothing more than an opinion and certainly is not talking up or down stock.
Secondly, speculating that it is 'likely' that the pension fund shareholders are somehow part of the MS plan isn't slander, it's just speculation. I concur whether directly or indirectly, this plays into the plan well. Maybe MS didn't approach anyone specific, but it doesn't take much foresight to know such a superficially outrageous deal will either be accepted or outrage to the point of lawsuit some set of shareholders. I would wager MS did not approach a single shareholder, but I wouldn't be surprised if they fully expected a refusal to meet with litiguous action from enough of the shareholders.
As to burying work on BSD/PHP/Zimbra, It's an obvious conclusion. The difference with FrontPage and Visio was there were no MS products being threatened by it. FrontPage ties in with the IE strategy and Visio a logical complement for the Office offering. BSD work *obviously* is not in MS's remote interest to help out, as with PHP. BSD is a Windows competitor and PHP is too OS/http server indepedent for their tastes to bother when they have a host of things already. Similarly, Zimbra has nothing over Exchange MS wants. Zimbra allows independence from Windows on the server side and client side for any who implement it, but otherwise it doesn't offer that much different from Exchange. I would wager they would offer some special 'upgrade' deal to Zimbra commercial users to Exchange and then be done with it. BSD/PHP wouldn't die, but would suffer development issues. Zimbra given its nature would be killed outright.
I'm not saying MS was explicitly targeting BSD/PHP/Zimbra in its bid to fend off OS/language/Exchange competitors, it's clear the bid is a desperate move against Google. By the way, it comes off like an unhealthy obsession with Google on the part of MS leadership, more than a sound business decision. BSD/PHP/Zimbra are incidentals that demonstrate the sale should be blocked by regulatory agencies, but from MS's perspective, they are either not even on the business people's radar or are mere bonus afterthoughts. From a certain perspective, it may have been a wise thing to decline the initial outrageous bid, knowing it was high risk with respect to regulatory agencies, and then exploit the exposure to get a more likely, but less lucrative situation elswhere..
While the frontend may be rooted in the System/360 set, the driving force seems likely to be the same as all the Power6 systems. For example http://www.pseriestech.org/forum/articles/what-is-project-eclipz-112.html
Note the 'z' in eclipz. They seem to be seeking to consolidate their non-x86 offerings in terms of core component design.
I concur that certain people can be fantastic all star managers/executives. I can also concede that without the correct non-technical leadership, a project can fall apart (wrong leadership can drive it into the ground, no leadership means the technical pursuit of things may never be pulled into a realisticly usable product, with features always being chased by the technical people who want the challenge.)
However, by the same token, for every project with a clear leader who organized the success, you can probably identify some technical architect/developer with the driving technical vision that was absolutely needed to be the foundation of the project. Someone who didn't *explicitly* manage people in any business sense, but still laid out exactly how it would all play out from the technical standpoint. Though I am aware of a precious few who repeatedly shine in this context, I never hear about those people getting multi-million dollar signing bonuses or golden parachutes. Half the time, they get thoroughly pushed to the background as the executive type has the praise lavished on for the great work they personally did. The only time I see it happen is when they surrender and turn into a business type. Quite frequently I see people start down the path only after proving a lack of technical competence, and quickly out pace their technical seniors just by being on a business track rather than a technical track.
The problem with your switchless proposal is that you presume two ports of network connectivity per node and that all can be dedicated to inter-node communication. It's then hardly useful as there is no way to uplink it to transfer meaningful work/results in and out. I guess your answer would be to slap an ethernet card, but at three nodes, why bother, particularly if you are advocating on board NICs as the interconnect.
In any event, the penalty of an ethernet switch at small scale is negligible (latency increase on a decent swich would maybe 2 usec when the system latency of the two nodes in ethernet is commonly in the 40 usec range, and only really contrived situations will be meausurably impacted, and even then the difference will be low. There are interconnects that get in the 2 usec range total for latency penalty on those contrived cases, but that's far more expensive than the onboard NICs.
The system mentioned has infiniband ports, and you could ignore the ethernet, so you could use those instead. But considering the exorbitant cost of Infiniband cables and your stated limited budget restriction, it's going to be hard to use those with or without a switch Further, if using the IB ports, the fabric would tolerate an additional hop, so the relative penalty of two hop communications isn't bad there either.. The same can be said of bridging the ethernet ports so each node is also a low-port count switch, but I can't speak to the performance characteristics of that. Especially with a mere three nodes, the workload of clustered applications won't even notice the difference in your convoluted node interconnect vs. something more generally configured.
In other words, a three-socket motherboard with infiniband is going to cost you a lot to get not significantly better performance than cobbling together something of more mainstream nature that will scale to 8 or 24 nodes (depending on if you want an 8 or 24 port switch, 48 port starts getting pricier).
The reason for the three socket server being able to boast the direct connection is an artifact of AMD's design. The processors in question had only two coherent HT links, and thus a processor with more coherent links could be used to construct fully connected designs with more members (i.e. 3 coherent links allows a fully connected quad socket). Anyway, as nice and symmetric as it sounds, the problem is overwhelmingly, the performance penalty of the occasional two hop access pales in comparison to having 33% more processor available to crunch in the scenarios where you would care about the minor degradation of a two hop access. Now all this was presuming it would be possible to build such a system with a Phenom, but it simply isn't. It isn't until the third tier of Opteron (single socket capable (1000 series), dual socket capabable (2000 series), 'more' socket capable (8000 series) that the number of HT links usable for inter-processor links permits that design.
It has no relevance to AMDs quad-core design internally, the cores are no worse off communication wise than the triple cores. It has no relevance to a cluster, where it's hard to imagine *any* node interconnect that would care about having 3 vs. 4 nodes in it.
Those are facilities for programs to request particular behavior changes of the way the system scheduler does thing. Overwhelmingly, there is next to zero reason to adjust this in most applications. A good scheduler makes the best choices for the vast majority of cases.
That said, depending on the implementation, optimizations may be missed by certain vintages of particular schedulers. For example, a process might be suboptimally put on a core without access to the L2 cache that it had last go around. In a more esoteric case, if you are doing something highly IO intensive on a dual socket AMD system, it may be helpful to scehdule it on a core on the socket wired to the system chipset rather than one a hope away. In a NUMA machine, tending to run your process on the processor where your allocations are local is healthy in general, but most NUMA-aware schedulers explicitly know that basic optimization.
His point though was that applications don't have to do anything all that exotic to see the bulk of the benefit from reasonable number of cores. The affinity mechanisms given in most scenarios a developer may actually shoot themselves by thinking they know better than the scheduler, and even for cases where a programmer *does* know something about the system/application the kernel does not, the gain for the esoteric stuff is generally in the single digit percentages. Even on single threaded applications, under typical desktop load, quad core can help. I just checked at random and I had three processes in run state, but it's not uncommon for more processes with greater demand to peak concurrently.
I logged into some friends' machines (where I don't have root access) and used that program to fix it. I love code that uses an exploit to fix said exploit.
See, the exploit is a feature, it allows friends to patch your system... yeah..
Dump the entire memory contents, and you probably store data you don't care about, being even more wasteful of resources than XML. If it was so painless, why would every modern framework explicitly deal with special calls to serialize objects? What if you dump the memory space of some object on an x86 and try to restore it on a ppc, which differs in endianness? What if you try to load it on a system with different data type sizes and the alignments mess up? What if you update your program to add a member to a struct, and suddenly you've corrupted the meaning of your binary save data from previous iterations?
I'm not saying XML is the best answer or by simply saying 'XML' problems go away, you always have to do something and many different frameworks/facilities in various languages exist to help. You have to do something more than open a file handle and start dumping from memory addresses to that file handle. You have to either think carefully or choose a tool that let's you be fairly straightforward and preserve your options going forward.
That we can't have quad core Intel processors, since Intel has to manufacture chips for laptops which need lower power utilization than is currently not feasible with quad core. Oh wait, Intel manufactures different variations of the same architecture to suit different products/environments. Power chips, likewise, are used in tiny embedded appliances with low TDP and other crippling situations, but also at extremely high TDP in Unix servers, with many more capabilities.
It's obviously a bad move to presume IBM would be so stupid as to lock themselves into only ever implementing one specific instance of a design without variation if they want to deviate. I agree with the other post, seemingly pointing and laughing at IBM over this 'limitation' is going to backfire if IBM considers it a viable platform outside of gaming and releases a serious variant of the product as this advancement gets rolled out in parallel.
That nVidia is on 65nm, I'd expect they'd move the 7800 to that process, if they haven't already, for the PS3.
Doesn't it just seem *bizarre* that to this day we see filesystems in microsoft tied to rather archaic looking drive letters? Looking at his various traces and everything having an arbitrary letter to identify what filesystem it originates just seems kinda lame.
Nope... never ever have heard that one before....
Unfortunately, it Looks like my network is more Awesome (over a septillion hosts, and less than one in a trillion chance it would conflict with my neighbor's)
I would disagree with your characterization of the migration to P4 to core as 'quick'. I would also not declare Intel successfully turning around a product that was competitive across the board with AMD until Core 2, when they pulled in the good instruction per clock and the 64 bit instruction sets all together. It took years for Intel to develop something that *almost* completely dominates the AMD equivalents (one could still make a case for the AMD memory architecture at scale, which Intel will counter with QPI this year). And the clock didn't start ticking until AMD forced their hand.
If it takes a company like Intel years to crank out something like that, a company with debatably the top notch fabrication capabilities in the world, what are nVidia's chances, given that only now they are feasibly able to leverage 65 nm fabrication processes for manufacture of their chips. Fabrication processes aren't everything, but it is a decent indicator of how the cards would be stacked for nVidia going into that market.
I personally would love to see nVidia enter the market with a viable offering, if only because I fear AMD is blowing the situation and the market desperately needs comparable vendors to compete, but I'm not optimistic about nVidia's capabilities.
If I ignore the incidentals for the moment (which I fear regulatory agencies might do), I'd be looking strictly at the online presence situation of the market. MS can't buy google, so is settling for yahoo. The fact that the resultant online presence of MS and Yahoo would still trail dramatically Google (even assuming some people wouldn't abandon yahoo, which they would). The fact is they can't buy off a majority as it stands, and most people observing don't see how MS could possibly use this as a way to pass Google, and as such, in the apparent point of the whole thing, it appears to be a dead end. The stuff that the mass media/most people don't even know about that can be classified as competitors in realms where MS maintains a monopoly will be what suffers.
MS shouldn't be allowed to do this due to their monopoly status. My fear is that too much focus will be placed on the primary mission of yahoo (trying to compete with Google), and not enough on the incidentals. You can bet MS would dismantle as soon as possible use and development of many open source technologies, such as Zimbra, FreeBSD, and php. Yahoo plays huge roles in those projects, and this deal could significantly impact those projects for the worse.
At the very least, the Zimbra vs. Exchange situation needs a hard look, since yahoo drives that project entirely and productizes it as an Exchange competitor.
A lot of your response speaks to the server side of things, and I haven't touched the server side since R6, so I can't comment to that.
I think saying 90% live in it is an overstatement.
-A good chunk (more than 10%) of notes users only ever touch email and calendaring. I would guess on personal experience, a great majority are in this camp, but won't absolutely claim it.
-Even looking beyond to companies that actual use the bits of Notes that are kind of unique (for the most part web applications without the web), I would bet a vast majority of those users do day to day work outside of notes, and use notes for the occasional internal application (maybe time card, putting documents into a database that's more awkward than a simple file share without real benefit). Bringing in OpenOffice raises it somewhat (I think I'd need to change jobs if I 'lived' in office applications), but beyond file save and load integrated into notes, it just slows down OpenOffice.
The problem is that Lotus software appears to shrug off significant memory utilization, storage utilization, and startup performance. Like you, they seem to think theirs is the only set of applications that matter, and that a computers entire point in life is to run their application suite and a user should only use it too. As such, why not suck up the memory and have ungodly load times? The truth is Notes is not my OS, it is not my 'desktop environment', it is an application. Even at its most ambitious, it is peer to a web browser. No web browser dares to have the general performance characteristics of a Lotus application, despite having a much closer to legitimate (but would still not be) claim to having typical users 'living' in their application.
Even putting aside those assumptions, running only notes and leaving it up all the time, it's still a sluggish application UI wise compared with the competition. This is even giving the benefit of client stored replica. Evolution connected to a slow IMAP server is obvious, but not grating. It immediately responds UI wise with obvious visual queues that it's interacting with the server, but allowing you to use other bits of the app while that happens. I.e., hit delete in notes, the app hangs until the server or file operation completes. Do the same in evolution, poof, the operation is denoted with strikethrough text and you go about your business while the 'heavy' lifting takes place, cleanly updating the UI on true completion by removing the entry.
I've consistantly had the experience.
I must ask, what version and what platform are you running notes on, for comparison? I've had the experience on my laptop (Ubuntu, dual core, but not that special) and my overpowered workstation (running RHWS5.1). Are you talking about opening notes8 after already running it (i.e. memory resident, or at the very least resident in disk cache the ludicrous amount of data it wants to pull from disk?).
Load time aside, what is the latency for clicking on a calendar entry to the time it is displayed? It doesn't sound like much if you put it to numbers, but it takes the better part of a second to a couple of seconds for me in notes to have the results after clicking. Same with doing mail operations. I can do many operations in evolution, and even if the mail server is in the picture and sluggish, the UI is immediately responsive, lets you continue, and intuitively denotes a queued deletion operation, for example, with strikethrough text.
My problem with Notes 8 is not that it isn't 'pretty' enough. My complaint is that it is an *unbelievable* amount of overhead for fulfilling its core function, email and calendaring. Software developers seem to cream themselves over the fact it is an eclipse platform, but the rest of the world stuck using the damn thing for email, that's zero comfort. There's no effort to provide a streamlined core client for the core function, just effort to make it even slower because some IBM managers/developers see that as the only path to progress.
Notes and Sametime clients both suffer this. Notes consumes 256 MB of my memory (yes, resident memory). Evolution 28M (not light weight, but still). Notes takes a long time to start and do any little operation (this machine is an 8 core system with 16GB of RAM, should be plenty). I haven't run Sametime client in a while, but I remember it taking ~50 seconds to start, and sucking up 128M of ram on it's own. It admittedly didn't feel slow once up and running, at least, though it did a terrible job of managing the WM hints (it would keep blinking in the window list despite acknowledging the message). Meanwhile, pidgin does *everything* pretty much right with a modest footprint and instantaneous start.
I am surprised at companies willingness to go with a Domino/Notes. It would be one thing if the application suite were rich and nice to use, but it isn't and webapps have in the meantime improved to have less awkwardness than Notes. I don't like acceptance of Exchange/Outlook (extreme vendor-lockin, significant cost), but at least the client isn't horrible.
I'm surprised open-standards based applications haven't gotten more traction. IMAP, CalDAV, and Jabber are decent protocols for their respective fields, but people still use Domino, Exchange, Sametime, and MS Communicator and volunteer for vendor lock-in.
It's embedded Gecko. In fact, without Mozilla/Firefox installed, it won't render HTML internally.
Notes always has been excruciatingly sluggish, bloated, and awkward. Putting it on top of eclipse made it that much worse. It feels like molasses on my system. This is working with local replicas of databases (eliminating the slow network) and on a ludicrously overpowered workstation (16 GB RAM, 8 cores, admittedly the hard drive setup is merely a mirror of 500 GB drives, but no other piece of software seems to mind).
I speak not as someone who actually has to use those annoying 'applications' written on the Notes platform by random people (just make a damn webapp people), but as someone who for the most part just needs it as an email client. For those who say 'but it isn't *just* an email client', that may be true, however, a primary function it is intended to fulfill should not be so user-antagonistic. Also, if the core function it means to fulfill with all the developer attention available can't be made pleasant, then it says unfortunate things about the platform.