You're assuming that the only difference between 32-bit and 64-bit x86 instructions are the bit sizes. That's not true, and the most immediate gain from AMD64 are the extra registries. There are a lot of changes to the ISA that will dramatically skew the results. The only negative results you would get compiling 32-bit code to 64-bit would be: A) The cache can contain fewer entries; B) Platform assumptions, such as when performing pointer arithmetic, would break. His code is probably fairly clean since he was able to test it on both x86 and PowerPC processors.
I also disagree with you on Operating System support. The HP wx9300 is sold with 64-bit Linux or Windows XP x64, both of which have mature 64-bit support. Microsoft Windows became 64-bit clean with the Intel Itanium series and Linux with the DEC Alpha. Windows 2000, for instance, supports up to 32GB of addressable memory on 32-bit x86 by using PAE.
Its funny you talk about jumping the gun, but then shrug off your assumptions. The entire point is to find out what bad assumptions are being made, since so many people are surprised by his numbers.
AMD64 is not a processor, it is an instruction set. So you need to clarify whether you compiled your programs using 32-bit or 64-bit x86 instructions. I am not a gcc user, but I'm assuming that it chooses the default architecture based on your environment settings, thus AMD64 on 64-bit Linux. Since you've included a PowerPC processor, its really not obvious.
When the Core2 was released, benchmarks made it clear that Intel did not optimize for 64-bit performance. They have the architecture, but they pushed that task to a future refresh. AMD processors receive a significant performance boost in 64-bit mode, which could easily explain your numbers.
My argument is quite simple:
- Both can develop and create new innovative products.
- Both must take into account a lot of technical aspects to perform their job.
- But, an engineer's toolchain and designs must reflect the physical world.
I would be overjoyed if the term "Software Developer" was used instead of "Software Engineer". I honestly don't see one as being more prestigious than the other. My feeling is that the term "engineer" was adopted due to the immaturity of the field and a search for a term to help justify considering it as a profession. Other terms were tried: craftsman, artist, wizard, architect. The software industry has proven itself as a profession and members of the community should not feel insecure based on their title. A "Software Developer" is just as impressive, but simply more fitting. It also descripes the tasks correctly and does not try to adopt the image of other, more mature professions.
My personal take is that the mathematics of programming abstract too far away from the physical world. The implementation of the system can very well be transistors, vacuum tubes, mechanical, or quantum. The logic of the system doesn't change, but the design decisions of the developer will change based upon the capabilities and performance of the underlying system.
When I write code with Hibernate, my thoughts aren't remotely attached to the hardware of running the database. They also are not on the speed of the data cables. Instead, they are on creating abstractions and optimizing queries for the cleanest and best performing code. The tools of the software industry only require taking into account physical limitations indirectly, because as long as the logic is correct it will work despite the performance penalty.
Whereas when I developed a high-speed adder in graduate school, I had to consider the natural limitations. When drawing VLSI floorplans, the spacing between elements (e.g. wires) is important to take into account to optimize layout space and not incur cross-talk. A high-level modeling technique called Logical Effort, takes into account the laws of electricity in determining the correct gate to use. While mathematically I could drive a dozen inverters off of one line, in reality the current can only sustain up to four. My designs decisions took into account more than mathematics, but properties in the core sciences.
Now, I definately agree that there is significant overlap between some forms of engineering and development. As I mentioned in another post, I earned degrees in both fields and am a sotware developer. The significant overlaps and differences helped me become better in each domain, but I wouldn't consider them comparable enough to call both engineering.
Whereas most people say they are the same because both create products, they do with far different mindsets. Many fields create products - an author writes books, but knowing the a language does not make them engineers. That is why I view "software developer" as the most appropriate title, since it acknowledges the creation of software. An "engineer" is simply a developer rooted in some field of natural science.
Using the term for software seems to be more about trying to call instill programming as a profession or simple ego. Software is a profession and so successful developers shouldn't feel the need to even use the term "engineer". It makes them seem insecure.
I agree! However, the term has been so horrible misused and generalized that those who apply it to software now feel justified to do so. A traditional engineer is rooted in mathmatics and science. All their techniques have a direct relation to properties that exist in nature. The term "Software Engineer" grew out of trying to make software development sound more professional, and thus unjustified title inflation.
I have degrees in both CS and EE (computer specialization). The two are incredibly different, and everyone I know with a traditional engineering degree (and in the software field) resents the abusage. I may have the title "Software Engineer", but I'd prefer "Software Developer" since it fits my job desciption far better. In becoming a better developer, I have never once had to use scientific research. As an graduate student in engineering, every bit related. Even for very logical aspects, such as designing high speed adders, intimate knowledge of physics was necessary (e.g. VLSI, logical effort). You can't escape nature as an engineer.
So to everyone replying to the parent saying 'nay'.. how many of you actually have an engineering background and the ability to make a fair comparision?
I agree, Rearden isn't consumer friendly - yet. We are working on that and a lot of effort is being done to clean up the user interface, as well as to totally redesign it to create a enhance experience. In the future, I am positive that Rearden Commerce will open their platform to the public once critical mass of corporate users, suppliers, and services has been reached.
In terms of offering "a greater variety of services" - that's our long-term goal. We have a SOA platform that allows us to easily integrate new services and have developed a new framework to rapidly create them. We'll quickly become a marketplace of services.
It will be interesting to see how AMEX responds to us. We're on their radar.
What he wants now: Concierge-grade trip planning over the Web. Imagine getting a message on your BlackBerry alerting you that your villa is booked, dinner reservations are confirmed, and a driver will pick you up in an hour for the flight to Belize. It's not live agents making that happen, but software that taps into the growing number of travel-industry databases - of hotel chains, restaurants, limo services, amusement parks - to assemble smarter, more personalized itineraries than can be found on major travel hubs like Orbitz and Travelocity.
Look at Rearden Commerce. Plus, we get to throw around the latest tech buzz words too (SOA, SaaS, AJAX, etc)!
What you're thinking of is more on the lines of a UML as blueprint vs. UML as sketch. DBC is purely code-level and is simply a good practice. Good programmers will at least check all preconditions (e.g. if (param == null) {throw new IllegalArgumentException("Param=NULL")}). That's step one of the DBC philosophy. Having the whole process built into the language simply makes it cleaner reduces LOC.
Design by Contract basically means that someone takes the responcibility to make sure inputs and outputs are valid. A verbal contract is loose - everyone assumes that everyone else did the right thing and the data is valid. When someone makes a coding mistake, such as passing in a null object, it may propogate pretty far and cause an error to appear. You'll then spend a lot of cycles trying to fix the problem and work your way back to the real offender. So DBC simply forces an error to happen right away and saves time.
So think of DBC as your friend. It never gets in the way of refactoring, yet kindly points out problems before your customers do.:)
Sometimes, in the short term, fixing a bug is harder than making sure that it won't be exploited 95%+ of the time. This could be due to architecture/legacy issues, not having resource(s) who know that code base, or the fixer not knowing the code. By using signatures, you're seperating the person that writes the signature from knowing any of the code for the underlying product. Its probably much quicker since they don't have a steep learning curve, can rapidly generate signatures, and its both a cheaper and faster solution. That's not to say its good long term, but considering why IE is slow to fix bugs (MS had haulted development) this has the benefit of being independant and much easier to maintain.
On implementation, Vista will have auto-updates on be default. From their work towards making Windows far more modular, they can probably now stop services, patch, and restart them seemlessly instead of requiring a reboot. If it was proxy based, any browser could use it and we'd likely see a Google proxy too, since the data would be quite valuable and power users would naively trust Google more than Microsoft.
One thing to remember, Sun has a lot more expertise on memory busses than Intel does. The UltraSparc chips have never been great performers, but are wonderful at scaling in multiprocessor systems. Intel has never put too much effort in their bus system, because the economics favor cheaper solutions. Their shared bus approach reduces costs for a mass market, but they even use it for ultra high-end systems like Itanium. Those systems really need a better system bus, but simply used a tweaked version of the standard Xeon one. I believe Intel is targetting 2007 for the release of their new bus architecture.
What is the benefit that Kentsfield is delivering? I was under the impression that Woodcrest would be a four core processor (2 independant dies, each with two cores sharing L2) and a dual FSB. It sounds like your saying Woodcrest is a Xeon version of dual core Conroes? I'm a bit surprised Kentsfield is using a single bus rather than the dual bus current Xeons support.
Any word on when Intel will put in the energy to remove the rough spots on 64-bit Conroe performance? Its good and the infrustructure is there, but from benchmarks its evident that they wisely put their energy towards tuning 32-bit performance. EM64T may not be a critical market for them, but it will be nice to know in what refresh they plan on implementing 64-bit macro-op fusion and other refinements.
For Intel, they are currently using a shared bus approach. It makes sense for a lot of reasons (mainly by being very cost effective), and they are developing a point-to-point bus for the near future. In such a system, each CPU is using the bus for retrieve data. This means that they lock the bus, make their calls, finish, and unlock. The total bandwidth available is split between all parties, so if there are multiple active members (e.g. CPUs) then their effective bandwidth is split N ways. The only solution to this is to have multiple shared busses, which is expensive.
A point-to-point bus gives each member their own bus to memory. Thus, there is NxBW effective bandwidth available. As memory cells are independant, the memory system can feed multiple calls. You'll only run into issues if multiple CPUs are accessing the same memory, but models have been around for a long time. There might be a slightly higher latency, but not by much.
With multiple cores, you may get the benefit of shared caches which could remove a memory hit.
Overall, I would assume a multi-core system would scale fairly similarly to a multi-processor system.
That's only for poorly designed systems. Ever hear, "Don't throw the baby out with the bathwater!"? Most of these systems were short-sighted and the cultures were not actively put in check, allowing for the flaws to be abused and dominate the system.
Personally, I've been a fan of the "Balanced Scorecard" approach for a number of years, and had success implementing it. The development was quite challenging in order to make it effective, and the toolkit needs to be integrated into the management system. Its definately a heavy weight approach, but can work quite well. In the end, no methodology can make up for poor implementations and unethical (or negligent) leadership.
Personally, I really liked Lou Gerstner's comments in "Who Says Elephants Can't Dance?" (IBM's former CEO). He disliked meeting with reporters to gain press coverage. The more time with them, the less with the company's problems. He also questioned the current stock option schemes, which allow for too much short-term focus. If I remember correctly, he used them but wasn't fully happy and was hoping for wavering on supporting them. I believe the one they devised required a more long-term holding then the norm, but its been a few years since I read his book.
While the article is vague, I doubt they are considering genetic algorithms. While very cool, they can be unpredictable and hard reproduce. My favorite story, which drove home to me that that technique would rarely work, is about voice recognition hardware on an FPGA. The genetic algorithm had excellent performance, but when the researchers "copied" the mask to another FPGA, it failed to work. The cause: the algorithm leveraged various techniques such as cross-talk that engineers work hard to avoid which caused it to be tied that particular environment.
What these researchers are probably aiming towards is a large-scale MP system that can readily handle massive failures. Who would find this useful? Any enterprise software companies, such as Google which has thousands upon thousands of machines in its cluster. The ability to have a large network of simple (cheap) processors and a network that can readily withstand a massive multi-point failure is quite attractive to real-world companies.
Both software and hardware is beginning to go down this route by evolution of the industries. On the software front, asynchronous message-oriented systems work beautifully in terms of reliability, scalability, maintainability, and service integration. In the coming years, you'll notice that most major web services will be running on a SOA architecture. On the other side of the pond, raw CPU performance is getting harder to squeeze out. Power issues are limitting frequency scaling (due to current leakage), we are hitting limits of our ability to feasibly extract more ILP that's worth the extra effort, and the market drivers for these types of processors is slowly diminishing. Instead multiple physical and logical core CPUs are gaining ground, will be cheaper to develop and manufacture, and fit the future market demands.
It will be nice to hear how this research goes, since it will hopefully uncover potential problems and solutions that will be useful in the coming decades.
Passion can't be benchmarked, nor can any measure be made to show how it directly (or indirectly) affects performance. The definition of "passion" is also up for grabs and can be twisted either to hurt or aid the individual being measured against it. For example, most engineers view being passionate as working 100% towards the product's vision, ensuring it is done right, sacraficing through long hours, and ignoring a lot of peripheral, non-core, problems (e.g. insulting behavior by managemment/co-workers). Engineers are usually very aloof and don't cheerlead ideas, since R&D requires staying objective. They will believe that their passion shows through their actions.
Yet, to marketing and sales, passion might be seen as the person who acts as a cheerleader and is extremely open about their commitment. Those that deliver are truly passionate, and cheerleading is extremely important in that field. Yet enough believe in "faking it 'till you make it", ensuring that pure words are made meaningless. Unfortunately most people fail to look any deeper.
What matters isn't "passion" but performance. Passion is just an excuse to promote or fire someone, because real passion translates into performance. You can measure performance. Jack's rule is to measure performance. The top leaders on Human Resources and measurement systems focus on performance. The company vision isn't built on someone stating that they are "passionate", but by execution.
An excellent read, following Jack's rule and knowledge built from practitioners of the Balanced Scorecard is "The Workforce Scorecard" (Harvard Business School Press, 2005).
I think the idea is that they write embedded OS, APIs, and other tools to allow easy development of robotics by manufacturers. They aren't researching and developing their own, simply trying to become the dominent platform for an emurging market.
It definately could be if you expect the same UI logic to be reused. However JSF is a component framework, so you can either have the component render itself (thus having a PDA view, Web view, etc) or use a renderkit. The renderkit can decide what to show and how. I believe the idea is that different UIs can be created in an architecture as either a set of components that are designed as a self-contained MVCs with multiple views, or uing renderkits as application-level views. Either way, the UI is kept seperate from the underlying logic.
Note: I am a beginner in JSF so my explanations are fairly vague and could be slightly wrong.
All I meant regarding the business logic vs. interface was a question of priorities, rather than whether you use an MVC-style architecture. It was largely another wording for the adjacent question, as in: Does Lazlo force you to spend more time on the UI than on business-level features?
That can be a concern depending on your market, so a lot of people either blindly believe that the UI doesn't matter or is overly important. I was trying to gauge how much emphasis your company put on UI work (and whether it could be a concern or an asset). So I asked it in a few different ways in case you didn't fully answer the question. But you did.:)
- I like the idea of using JavaServer Faces and renderkits, so you can easily migrate to different presentation technologies. Did you write directly to Lazlo's API or use a renderkit-type method? IBM has a Lazlo-JSF renderkit and that seems like the best way to go in that world.
- If you're writing to the API, how tied to it are you? With a rederkit, you can quickly make changes from a web-browser to a PDA, with the components taking care of the display issues. Is display migration an issue?
- How is performance? I've always found the examples on OpenLazlo to be slow, limitted, and not seem to be very useful in the real world.
- How much time have you spend on the UI versus other techniques (e.g. DHTML/AJAX)? If longer with Lazlo, do your customers see your UI as value-added? Does it reduce your time from working on the core business-logic?
What Amazon is describing is their SOA and their efforts to make it a generic, base platform for a large multitude of services. The idea of having a service grid, where services are easily developed, deployed, and work seemlessly together, has been gaining a lot of momentium in the last few years. A number of companies are posed to shift the playing field from an ASP model to a network of service.
The article is impressive in hearing how Amazon successfully migrated from their legacy platform to a SOA. They may become a real contender in this emerging market, considering that they already have the user base and are quickly maturing a powerful platform. The other major contenders are Rearden Commerce and Salesforce.
Rearden Commerce, the company I work for, has developed a very pure SOA. They are currently targetting enterprise customers in order to gain the critical mass and user adoption necessary to succeed, which can be very difficult for a startup working in the consumer market. Their goal is to provide a web-based personal assistent that you can use to book plane tickets, dinning, etc. and all coordinated with your peers and working with your calendar and notification preferences (email, SMS, voice). It looks as if Amazon is on a similar path, so it will be interesting to see what happens in the next few years.
After the critical mass and the base platform are available the next big issue is getting 3rd party developers on the platform. That's something that everyone seems to be working on, which is why we're seeing so many AJAX and other toolkits emerging from companies like Yahoo, Google, and Zimbra. Imagine another company's product integrating just as neatly with Gmail as Google Calendar, yet staying very decoupled. That's part of the promise, and is the next big hurdle for the SOA leaders even though their platforms are still quite fresh and new.
I've been working for about 6 months in our platform group (a web services company).
My first starter project was to write an XML validator, so that we could compare profiles created and uploaded through FTP and those sent through web services. Unfortunately the schemas had become a bit different, so we needed a way to validate that the same data existed. I used graph theory to represent the XML documents, validate and transform elements, and create a diff log.
My next project was continuing the development of our Operations Console, which helps us monitor for application failures. While I used a number of design patterns, later we wanted our a UI filter to be a backend mechanism. That meant creating our own filtering syntax and generating custom SQL statements per user filtering statement. I created a grammer, a simple LR parser, and an SQL code generator.
I've since moved on to other projects. While a lot of work is implementation and not architecture design or algorithms, I have found my CS background to be useful. It allows me to solve problems quicker and more elegant than a naive approach. It also gives me the foundation to continue educating myself to move on to the next level, rather than just focusing on enhancing the skillset at my current level.
Because your comments seem full of nonsense, I finally looked up the dynamic power equation I was thinking of and that the grandparent had just learned.
P(ave) = C(eff) x V(dd)^2 x f
Which of course means my original comment was correct. Rather than citing confidential material and skirting the issues, how about backing up your assertions with real facts.
Slashdot Mirror
You're assuming that the only difference between 32-bit and 64-bit x86 instructions are the bit sizes. That's not true, and the most immediate gain from AMD64 are the extra registries. There are a lot of changes to the ISA that will dramatically skew the results. The only negative results you would get compiling 32-bit code to 64-bit would be: A) The cache can contain fewer entries; B) Platform assumptions, such as when performing pointer arithmetic, would break. His code is probably fairly clean since he was able to test it on both x86 and PowerPC processors.
I also disagree with you on Operating System support. The HP wx9300 is sold with 64-bit Linux or Windows XP x64, both of which have mature 64-bit support. Microsoft Windows became 64-bit clean with the Intel Itanium series and Linux with the DEC Alpha. Windows 2000, for instance, supports up to 32GB of addressable memory on 32-bit x86 by using PAE.
Its funny you talk about jumping the gun, but then shrug off your assumptions. The entire point is to find out what bad assumptions are being made, since so many people are surprised by his numbers.
AMD64 is not a processor, it is an instruction set. So you need to clarify whether you compiled your programs using 32-bit or 64-bit x86 instructions. I am not a gcc user, but I'm assuming that it chooses the default architecture based on your environment settings, thus AMD64 on 64-bit Linux. Since you've included a PowerPC processor, its really not obvious.
When the Core2 was released, benchmarks made it clear that Intel did not optimize for 64-bit performance. They have the architecture, but they pushed that task to a future refresh. AMD processors receive a significant performance boost in 64-bit mode, which could easily explain your numbers.
My argument is quite simple:
- Both can develop and create new innovative products.
- Both must take into account a lot of technical aspects to perform their job.
- But, an engineer's toolchain and designs must reflect the physical world.
I would be overjoyed if the term "Software Developer" was used instead of "Software Engineer". I honestly don't see one as being more prestigious than the other. My feeling is that the term "engineer" was adopted due to the immaturity of the field and a search for a term to help justify considering it as a profession. Other terms were tried: craftsman, artist, wizard, architect. The software industry has proven itself as a profession and members of the community should not feel insecure based on their title. A "Software Developer" is just as impressive, but simply more fitting. It also descripes the tasks correctly and does not try to adopt the image of other, more mature professions.
My personal take is that the mathematics of programming abstract too far away from the physical world. The implementation of the system can very well be transistors, vacuum tubes, mechanical, or quantum. The logic of the system doesn't change, but the design decisions of the developer will change based upon the capabilities and performance of the underlying system.
When I write code with Hibernate, my thoughts aren't remotely attached to the hardware of running the database. They also are not on the speed of the data cables. Instead, they are on creating abstractions and optimizing queries for the cleanest and best performing code. The tools of the software industry only require taking into account physical limitations indirectly, because as long as the logic is correct it will work despite the performance penalty.
Whereas when I developed a high-speed adder in graduate school, I had to consider the natural limitations. When drawing VLSI floorplans, the spacing between elements (e.g. wires) is important to take into account to optimize layout space and not incur cross-talk. A high-level modeling technique called Logical Effort, takes into account the laws of electricity in determining the correct gate to use. While mathematically I could drive a dozen inverters off of one line, in reality the current can only sustain up to four. My designs decisions took into account more than mathematics, but properties in the core sciences.
Now, I definately agree that there is significant overlap between some forms of engineering and development. As I mentioned in another post, I earned degrees in both fields and am a sotware developer. The significant overlaps and differences helped me become better in each domain, but I wouldn't consider them comparable enough to call both engineering.
Whereas most people say they are the same because both create products, they do with far different mindsets. Many fields create products - an author writes books, but knowing the a language does not make them engineers. That is why I view "software developer" as the most appropriate title, since it acknowledges the creation of software. An "engineer" is simply a developer rooted in some field of natural science.
Using the term for software seems to be more about trying to call instill programming as a profession or simple ego. Software is a profession and so successful developers shouldn't feel the need to even use the term "engineer". It makes them seem insecure.
All engineer's tools is rooted in the basic sciences.
All software developer's tools are rooted in mathmatics.
An engineer cannot escape the laws of nature. A developer can rewrite them.
I agree! However, the term has been so horrible misused and generalized that those who apply it to software now feel justified to do so. A traditional engineer is rooted in mathmatics and science. All their techniques have a direct relation to properties that exist in nature. The term "Software Engineer" grew out of trying to make software development sound more professional, and thus unjustified title inflation.
I have degrees in both CS and EE (computer specialization). The two are incredibly different, and everyone I know with a traditional engineering degree (and in the software field) resents the abusage. I may have the title "Software Engineer", but I'd prefer "Software Developer" since it fits my job desciption far better. In becoming a better developer, I have never once had to use scientific research. As an graduate student in engineering, every bit related. Even for very logical aspects, such as designing high speed adders, intimate knowledge of physics was necessary (e.g. VLSI, logical effort). You can't escape nature as an engineer.
So to everyone replying to the parent saying 'nay'.. how many of you actually have an engineering background and the ability to make a fair comparision?
I agree, Rearden isn't consumer friendly - yet. We are working on that and a lot of effort is being done to clean up the user interface, as well as to totally redesign it to create a enhance experience. In the future, I am positive that Rearden Commerce will open their platform to the public once critical mass of corporate users, suppliers, and services has been reached.
In terms of offering "a greater variety of services" - that's our long-term goal. We have a SOA platform that allows us to easily integrate new services and have developed a new framework to rapidly create them. We'll quickly become a marketplace of services.
It will be interesting to see how AMEX responds to us. We're on their radar.
What he wants now: Concierge-grade trip planning over the Web. Imagine getting a message on your BlackBerry alerting you that your villa is booked, dinner reservations are confirmed, and a driver will pick you up in an hour for the flight to Belize. It's not live agents making that happen, but software that taps into the growing number of travel-industry databases - of hotel chains, restaurants, limo services, amusement parks - to assemble smarter, more personalized itineraries than can be found on major travel hubs like Orbitz and Travelocity.
Look at Rearden Commerce. Plus, we get to throw around the latest tech buzz words too (SOA, SaaS, AJAX, etc)!
Disclamer: Employee of said company.
What you're thinking of is more on the lines of a UML as blueprint vs. UML as sketch. DBC is purely code-level and is simply a good practice. Good programmers will at least check all preconditions (e.g. if (param == null) {throw new IllegalArgumentException("Param=NULL")}). That's step one of the DBC philosophy. Having the whole process built into the language simply makes it cleaner reduces LOC.
:)
Design by Contract basically means that someone takes the responcibility to make sure inputs and outputs are valid. A verbal contract is loose - everyone assumes that everyone else did the right thing and the data is valid. When someone makes a coding mistake, such as passing in a null object, it may propogate pretty far and cause an error to appear. You'll then spend a lot of cycles trying to fix the problem and work your way back to the real offender. So DBC simply forces an error to happen right away and saves time.
So think of DBC as your friend. It never gets in the way of refactoring, yet kindly points out problems before your customers do.
why not ship the actual updates?
Sometimes, in the short term, fixing a bug is harder than making sure that it won't be exploited 95%+ of the time. This could be due to architecture/legacy issues, not having resource(s) who know that code base, or the fixer not knowing the code. By using signatures, you're seperating the person that writes the signature from knowing any of the code for the underlying product. Its probably much quicker since they don't have a steep learning curve, can rapidly generate signatures, and its both a cheaper and faster solution. That's not to say its good long term, but considering why IE is slow to fix bugs (MS had haulted development) this has the benefit of being independant and much easier to maintain.
On implementation, Vista will have auto-updates on be default. From their work towards making Windows far more modular, they can probably now stop services, patch, and restart them seemlessly instead of requiring a reboot. If it was proxy based, any browser could use it and we'd likely see a Google proxy too, since the data would be quite valuable and power users would naively trust Google more than Microsoft.
One thing to remember, Sun has a lot more expertise on memory busses than Intel does. The UltraSparc chips have never been great performers, but are wonderful at scaling in multiprocessor systems. Intel has never put too much effort in their bus system, because the economics favor cheaper solutions. Their shared bus approach reduces costs for a mass market, but they even use it for ultra high-end systems like Itanium. Those systems really need a better system bus, but simply used a tweaked version of the standard Xeon one. I believe Intel is targetting 2007 for the release of their new bus architecture.
What is the benefit that Kentsfield is delivering? I was under the impression that Woodcrest would be a four core processor (2 independant dies, each with two cores sharing L2) and a dual FSB. It sounds like your saying Woodcrest is a Xeon version of dual core Conroes? I'm a bit surprised Kentsfield is using a single bus rather than the dual bus current Xeons support.
Any word on when Intel will put in the energy to remove the rough spots on 64-bit Conroe performance? Its good and the infrustructure is there, but from benchmarks its evident that they wisely put their energy towards tuning 32-bit performance. EM64T may not be a critical market for them, but it will be nice to know in what refresh they plan on implementing 64-bit macro-op fusion and other refinements.
Worse.
For Intel, they are currently using a shared bus approach. It makes sense for a lot of reasons (mainly by being very cost effective), and they are developing a point-to-point bus for the near future. In such a system, each CPU is using the bus for retrieve data. This means that they lock the bus, make their calls, finish, and unlock. The total bandwidth available is split between all parties, so if there are multiple active members (e.g. CPUs) then their effective bandwidth is split N ways. The only solution to this is to have multiple shared busses, which is expensive.
A point-to-point bus gives each member their own bus to memory. Thus, there is NxBW effective bandwidth available. As memory cells are independant, the memory system can feed multiple calls. You'll only run into issues if multiple CPUs are accessing the same memory, but models have been around for a long time. There might be a slightly higher latency, but not by much.
With multiple cores, you may get the benefit of shared caches which could remove a memory hit.
Overall, I would assume a multi-core system would scale fairly similarly to a multi-processor system.
That's only for poorly designed systems. Ever hear, "Don't throw the baby out with the bathwater!"? Most of these systems were short-sighted and the cultures were not actively put in check, allowing for the flaws to be abused and dominate the system.
Personally, I've been a fan of the "Balanced Scorecard" approach for a number of years, and had success implementing it. The development was quite challenging in order to make it effective, and the toolkit needs to be integrated into the management system. Its definately a heavy weight approach, but can work quite well. In the end, no methodology can make up for poor implementations and unethical (or negligent) leadership.
Personally, I really liked Lou Gerstner's comments in "Who Says Elephants Can't Dance?" (IBM's former CEO). He disliked meeting with reporters to gain press coverage. The more time with them, the less with the company's problems. He also questioned the current stock option schemes, which allow for too much short-term focus. If I remember correctly, he used them but wasn't fully happy and was hoping for wavering on supporting them. I believe the one they devised required a more long-term holding then the norm, but its been a few years since I read his book.
While the article is vague, I doubt they are considering genetic algorithms. While very cool, they can be unpredictable and hard reproduce. My favorite story, which drove home to me that that technique would rarely work, is about voice recognition hardware on an FPGA. The genetic algorithm had excellent performance, but when the researchers "copied" the mask to another FPGA, it failed to work. The cause: the algorithm leveraged various techniques such as cross-talk that engineers work hard to avoid which caused it to be tied that particular environment.
What these researchers are probably aiming towards is a large-scale MP system that can readily handle massive failures. Who would find this useful? Any enterprise software companies, such as Google which has thousands upon thousands of machines in its cluster. The ability to have a large network of simple (cheap) processors and a network that can readily withstand a massive multi-point failure is quite attractive to real-world companies.
Both software and hardware is beginning to go down this route by evolution of the industries. On the software front, asynchronous message-oriented systems work beautifully in terms of reliability, scalability, maintainability, and service integration. In the coming years, you'll notice that most major web services will be running on a SOA architecture. On the other side of the pond, raw CPU performance is getting harder to squeeze out. Power issues are limitting frequency scaling (due to current leakage), we are hitting limits of our ability to feasibly extract more ILP that's worth the extra effort, and the market drivers for these types of processors is slowly diminishing. Instead multiple physical and logical core CPUs are gaining ground, will be cheaper to develop and manufacture, and fit the future market demands.
It will be nice to hear how this research goes, since it will hopefully uncover potential problems and solutions that will be useful in the coming decades.
I utterly agree.
Passion can't be benchmarked, nor can any measure be made to show how it directly (or indirectly) affects performance. The definition of "passion" is also up for grabs and can be twisted either to hurt or aid the individual being measured against it. For example, most engineers view being passionate as working 100% towards the product's vision, ensuring it is done right, sacraficing through long hours, and ignoring a lot of peripheral, non-core, problems (e.g. insulting behavior by managemment/co-workers). Engineers are usually very aloof and don't cheerlead ideas, since R&D requires staying objective. They will believe that their passion shows through their actions.
Yet, to marketing and sales, passion might be seen as the person who acts as a cheerleader and is extremely open about their commitment. Those that deliver are truly passionate, and cheerleading is extremely important in that field. Yet enough believe in "faking it 'till you make it", ensuring that pure words are made meaningless. Unfortunately most people fail to look any deeper.
What matters isn't "passion" but performance. Passion is just an excuse to promote or fire someone, because real passion translates into performance. You can measure performance. Jack's rule is to measure performance. The top leaders on Human Resources and measurement systems focus on performance. The company vision isn't built on someone stating that they are "passionate", but by execution.
An excellent read, following Jack's rule and knowledge built from practitioners of the Balanced Scorecard is "The Workforce Scorecard" (Harvard Business School Press, 2005).
I think the idea is that they write embedded OS, APIs, and other tools to allow easy development of robotics by manufacturers. They aren't researching and developing their own, simply trying to become the dominent platform for an emurging market.
It definately could be if you expect the same UI logic to be reused. However JSF is a component framework, so you can either have the component render itself (thus having a PDA view, Web view, etc) or use a renderkit. The renderkit can decide what to show and how. I believe the idea is that different UIs can be created in an architecture as either a set of components that are designed as a self-contained MVCs with multiple views, or uing renderkits as application-level views. Either way, the UI is kept seperate from the underlying logic.
Note: I am a beginner in JSF so my explanations are fairly vague and could be slightly wrong.
Yep, thanks!
:)
All I meant regarding the business logic vs. interface was a question of priorities, rather than whether you use an MVC-style architecture. It was largely another wording for the adjacent question, as in: Does Lazlo force you to spend more time on the UI than on business-level features?
That can be a concern depending on your market, so a lot of people either blindly believe that the UI doesn't matter or is overly important. I was trying to gauge how much emphasis your company put on UI work (and whether it could be a concern or an asset). So I asked it in a few different ways in case you didn't fully answer the question. But you did.
Thanks again!
- I like the idea of using JavaServer Faces and renderkits, so you can easily migrate to different presentation technologies. Did you write directly to Lazlo's API or use a renderkit-type method? IBM has a Lazlo-JSF renderkit and that seems like the best way to go in that world.
:)
- If you're writing to the API, how tied to it are you? With a rederkit, you can quickly make changes from a web-browser to a PDA, with the components taking care of the display issues. Is display migration an issue?
- How is performance? I've always found the examples on OpenLazlo to be slow, limitted, and not seem to be very useful in the real world.
- How much time have you spend on the UI versus other techniques (e.g. DHTML/AJAX)? If longer with Lazlo, do your customers see your UI as value-added? Does it reduce your time from working on the core business-logic?
There's some questions for you.
What Amazon is describing is their SOA and their efforts to make it a generic, base platform for a large multitude of services. The idea of having a service grid, where services are easily developed, deployed, and work seemlessly together, has been gaining a lot of momentium in the last few years. A number of companies are posed to shift the playing field from an ASP model to a network of service.
The article is impressive in hearing how Amazon successfully migrated from their legacy platform to a SOA. They may become a real contender in this emerging market, considering that they already have the user base and are quickly maturing a powerful platform. The other major contenders are Rearden Commerce and Salesforce.
Rearden Commerce, the company I work for, has developed a very pure SOA. They are currently targetting enterprise customers in order to gain the critical mass and user adoption necessary to succeed, which can be very difficult for a startup working in the consumer market. Their goal is to provide a web-based personal assistent that you can use to book plane tickets, dinning, etc. and all coordinated with your peers and working with your calendar and notification preferences (email, SMS, voice). It looks as if Amazon is on a similar path, so it will be interesting to see what happens in the next few years.
After the critical mass and the base platform are available the next big issue is getting 3rd party developers on the platform. That's something that everyone seems to be working on, which is why we're seeing so many AJAX and other toolkits emerging from companies like Yahoo, Google, and Zimbra. Imagine another company's product integrating just as neatly with Gmail as Google Calendar, yet staying very decoupled. That's part of the promise, and is the next big hurdle for the SOA leaders even though their platforms are still quite fresh and new.
I've been working for about 6 months in our platform group (a web services company).
My first starter project was to write an XML validator, so that we could compare profiles created and uploaded through FTP and those sent through web services. Unfortunately the schemas had become a bit different, so we needed a way to validate that the same data existed. I used graph theory to represent the XML documents, validate and transform elements, and create a diff log.
My next project was continuing the development of our Operations Console, which helps us monitor for application failures. While I used a number of design patterns, later we wanted our a UI filter to be a backend mechanism. That meant creating our own filtering syntax and generating custom SQL statements per user filtering statement. I created a grammer, a simple LR parser, and an SQL code generator.
I've since moved on to other projects. While a lot of work is implementation and not architecture design or algorithms, I have found my CS background to be useful. It allows me to solve problems quicker and more elegant than a naive approach. It also gives me the foundation to continue educating myself to move on to the next level, rather than just focusing on enhancing the skillset at my current level.
Because your comments seem full of nonsense, I finally looked up the dynamic power equation I was thinking of and that the grandparent had just learned.
P(ave) = C(eff) x V(dd)^2 x f
Which of course means my original comment was correct. Rather than citing confidential material and skirting the issues, how about backing up your assertions with real facts.
Yep, you're right about that - that was a mistype. However, it does not change the meat of my reply. Its just good nit-picking. :)