It'll be nice when this obsession with having other people do everything else for you will be over. Then again, it might require a certain demographic to just grow up a bit and not panic about having do anything they don't like because they are busy.
Frankly, if you aren't horribly overworked and not constantly distracted, things like shopping for you own food, filling up your own gas and so on aren't intolerable annoyances that you must eliminate at any cost. That's where the mobile app bubble is, there's not nearly enough people that can't manage to balance work and life out there as Silicon Valley thinks there is.
I think the another factor that is keeping this going for longer is that unlike the first dot-com boom, everybody has computing power and network access. In the first dot-com crash, it quickly became clear that access to the internet outside of SV was very small, and fewer people even had PCs (outside of work) than expected, and it all fell apart with only a few left with the funding and user base to continue on.
It did spark this next bubble though. There was such a massive investment in networking infrastructure for a perceived demand that came much later than expected.
Seriously, processing all those supplements, I wouldn't be surprised if his liver starts to tank a bit down the road. And his kidneys are probably having a good time as well. Oh, well, I'm sure he'll find somebody to grow him new ones.
So, first, people figured out that rm -rf / is bad, so they added an option that would disallow it by default, but you can turn it off, and rm -rf/* may still work.
But, the command never makes sense. What does it mean to remove/proc? Or/dev? People quote the ideal that you could be able to do really dumb things to be able to do really great things, but why allow things that don't make any sense at all? "rm -rf/dev/null" for example. What does that mean? It's seems reasonable to say "rm -r/" or "rm -r/*" has no meaning, as it asks to perform an operation on filesystems where it has no defined semantics, and therefore, you can always forbid it. After all, you can still list all the directories and files you want manually to get the same effect.
It's pretty much a port of the console based user space from Ubuntu, which will make a lot of developers happy (more options good). But, given how it works, you can't use bash to script windows commands (like you could in Cygwin/MSYS2). Nor can you expect to run some unix commands from the console either. On the other hand, the whole apt toolkit is at your hands, so you can install a ton of software and not wait for a Cygwin port.
I'm sure I'll get labeled as a shill (I'm not, it'd be nice, I could use the extra cash), but this is a major boost to Windows 10 as a developer OS. I get all the Windows tools I like and all the Linux bits I'm likely to want. And, yes, they are developing the.Net ecosystem into a really nice cross-platform environment for a lot of platforms.
Don't get me wrong, this is a squeeze on desktop Linux. There's likely no way they'll have the subsystem able to host X (or Wayland or Mir), it's not worth the effort. And there's no plans to port any of the Universal Windows Platform GUI stuff to Linux (again, no pay off).
Basically, this is a Windows Subsystem for Linux. The article claimed it is using some technology from MS Research to translate the Linux syscalls to Windows syscalls (probably the Detours group and other OS team members, if I had to bet). The nice part here it is avoids what doomed the older Subsystem for Unix, having to compile apps. This subsystem just runs ELF binaries, intercepting and rewriting syscalls as needed. That's the new piece.
It'll be interesting to see how far they try to push it.
Let me be upfront about my biases first: Node is trying to a solve a problem that really doesn't need to exist: To write everything in one language. It's amazing how much demand there is for it. It's clear that the core libraries and language just can't keep up with developer demands and the number of libraries to fill those demands has exploded out of control. Npm is packed to the gills with vanity projects that are made as a resume item for developers. Sure, there's plenty of these in other ecosystems, but it's amazing what has come to depend on them.
The Node ecosystem is amazingly fragile and it's going to get worse and worse. I fully expect there will be lots of work in the future unwinding the messes people made with it and replacing it with a more appropriate platform.
I know, everybody is waiting for the other shoe to drop, but there is none. The strategy here is obvious. Grow usage of Azure and displace Amazon. This means being pragmatic about platforms and gaining developer mindshare. There's billions of dollars to business to be had and Microsoft is ahead of the curve.
And it's a good story from a developer standpoint and it's getting better. Currently, where I'm at, they are still busy testing and doing proof of concepts, trying to set stuff up in Amazon, when they could have just gotten things running and started testing in Azure in minutes. They just refuse to believe that it can be that easy and they cling to virtual machine images and control they don't need (and costs them in resources).
It was overdue. Oddly, I think it was Xamarin that delayed this acquisition. I think MS would have been happy to pick them up two years ago. For all the flack Miguel de Icaza gets, he is a big open source supporter, and I bet he was concerned with how that would work being at MS and all. But, when.Net core happened, the writing was on the wall, and now they can just get.Net core to be what it needs to be.
Make no mistake, this is a play to displace some existing players and to encourage adoption of hosting on Azure and using Azure services. It's a good story for a lot of companies. You can use one set of skills (C#/.Net) to address development from end to end and you get pretty streamlined hosting (via Azure). Compared to having to assemble all the pieces from front to back, plenty of companies will take the ecosystem lock in.
Like most stuff at MS these days, it's Azure. A mobile app is just another front end to a web applications, and this makes the case of having using.Net from end to end and hosting in Azure and using things like Azure Mobile Services, Service Fabric and so on.
Look, the truly awful, horribly expensive solutions that lock people into insanely overpriced development projects are truly bad. Federal investigation into this company for ripping people off bad. No question. For the very few hospital systems that had their own home-grown systems, they do and still do okay.
But, the law had a purpose. Not having access to a comprehensive medical records causes injury and death from decisions made without the full record. It's a fairly well researched fact. But, nothing about the current systems address that need in any real way. Frankly, vendors have made claims that are (in my mind) almost criminally false.
It'd be nice to point and say that engineers are programmers are at fault, but if you look at those vendors and the medical informatics field in general, those who make the decisions are often doctors, nurses and other health professionals. The field is littered those who are unhappy with practicing medicine and think they can be software engineers and researchers instead and the result is an unspeakable mess.
The first step is that doctors, nurses, and so on will have to work with software engineers, system analysts, interaction designers and so on as peers. Not as contractors, not as subordinates, but as peers. And there are way too few doctors, etc. that can accept that a set of programmers can have just as much of an impact on the health of our population as they can. For better or for worse. And, yes, sadly, too many engineers have too much hubris and disrespect for how hard the care of other human beings truly is.
And, until we in America accept that access to universal, affordable healthcare is a fundamental right, we won't look far enough past profit to make a difference anyway. So, in the meantime, people will get needlessly hurt, will needlessly suffer and needlessly die.
While there is a lot of new proposed designs for reactors, the nature of nuclear energy is that there is waste. Waste that is insanely toxic, some of it for an incredibly long time. In the end, all nuclear energy creates a very, very long term problem that is much harder to address. Building a reactor is fairly easy compared to figuring out what to do with what it leaves behind.
The basic point of the article is dead on. The major assumption that I/O is extremely slow has driven the organization of computer architecture from the beginning. But, as the article noted, in the last few years, that equation can be changed drastically. The memory hierarchy is going to get more complicated: DRAM, NVDIMM, NVM, SSD, HD, Optical/Tape, and best using that hierarchy means that there are changes that need to be made.
For one, I think there will be a lot of research in this area. Just like modern network cards do a lot of processing before involving the CPU, it may be necessary to have similar abilities. For example, allowing the network and I/O devices to work with each other with much less CPU intervention. Or making the I/O controllers smarter so that computation can be moved to the disks. How to best organize operating systems to use this new memory hierarchy well.
The Java language and frameworks still have their fans, but the platform has just ground to a halt and has ossified into an overly rigid and verbose environment that takes increasingly longer to get anything done in compared to other alternatives.
Type erasure was hailed as the right thing. Time has show it was not, not at all. C#, Swift and Scala have all shown that proper generics really make for better APIs and programming models. More and more programmers are comfortable with higher-order programming, and Java is just behind in this respect, even with regards to C++14.
Build tools are still a hodge podge of Ant, Maven and Gradle. Maven can make even worse MSBuild file seem reasonable. And package management is just a mess. Even Microsoft is managing to use NuGet to make projects more management and modular. And Java, well, it's module improvements will be too little, too late. And Java projects are just huge monoliths that are hard to maintain and improve.
The JCP has just ground to a complete halt, and once leading edge frameworks have just lagged in terms of new ideas and innovations. I know Java programmers that loath using relational databases. Object Relational Mapping was once a strength of Java, but things like JPA have made verbose and clunky. Entity Framework just makes anything in the Java space look outdated.
It is true that the JVM itself has proven to very effective, and it's use will continue. But, it has improving contenders in LLVM and the CLR (via.Net Core). And in many ways, Java prevents the JVM from evolving (invoke dynamic is a great example).
Between Scala, Clojure and C#, there are better alternatives to Java in the enterprise space. And, in terms of mobile, Google has no reason to keep using Java. Swift has shown that developers want better, more expressive languages. Google has plenty of choices to choose from.
The reasons for using C and C++ haven't changed. The domains they serve they serve well and continue to do so. But, there are less and less reasons to use Java, and it is much easier to replace and displace unlike COBOL and related mainframe tech.
I have to agree. It's crazy how far people go to avoid just having to deal with relational database in OO languages. Sure, things like Hibernate/JPA can be clunky, but there are better models out there.
I can't count how many times I've had to explain to people that because we are using.Net, it's really not hard to use relational databases, and we don't need all those things that NoSQL people thing are revolutionary and groundbreaking, because LINQ has been working fine for years, and when it comes down to it, you've got SQL as an option too.
Does anybody remember when the NoSQL people swore that wouldn't never create new query languages, that they weren't reinventing the wheel, that this was an evolution. Guess what, everybody is inventing new query languages and ideas and features that relational databases have had for ages.
The NIH and NSF budgets would need a much larger bump to really kick off some major new initiatives, much less restore funding to useful programs. Translational medicine research programs have stalled, and major disease foundations are having to fund tons of foundational work. Also, there's no "moonshot" type of projects, for example, setting a goal of creating a battery that has 50% more capacity for the same weight (vs current best technology), notable gains in wind or solar efficiency, massive improvements to the power grid, and so on.
Well, actually, no. An optimal compiler and libraries would indeed be able to squeeze out some gains by knowing exactly what microarchitecture was being targeted versus just instruction sets.
I disagree. AMD played the largest role in failing to press advantages they had in growing markets up to the K10 microarchitecture (2006/2007). The ATI acquisition spilt their focus and reduced their resources in CPU microarchitecture, as well as tying up a lot of cash. The APU idea didn't play out nearly as well as it needed to. Then, the spinoff of Global Foundries and some process misses. Then Bulldozer. Intel killed NetBurst pretty fast. They had too, AMD was beating them on all fronts. But, they got Core online pretty quick, then Nehalem. Bulldozer was introduced in 2011, and Zen won't be online until 2017 at the earliest. So, Intel executed and AMD didn't. In the end, the antitrust settlement was a moot point. The damage was done, and the biggest blows were self inflicted.
Sure, lots of controversy over their actions in the late 90s and early 2000s, but by 2005, Intel had recovered from the mistakes made in NetBurst. Starting with the Core microarchitecture, Intel made some very strong advances in process and gains in their CPU architectures in the consumer and server spaces. AMD got distracted with the APU designs and made a huge misstep with the Bulldozer line. I think the ATI acquisition was a distraction as well. Meanwhile, Sandy Bridge was in place and allow Intel to make gains all around. By the time Haswell was in place, their entire lineup was solid. They had the core counts to match the high end Opterons, they were pushing ahead on virtualization (VT-D, APICv) and AMD was and is in a rough spot.
Zen needs to have good parity with Skylake for AMD to regain market share, and that's a tough task. Also, Intel has major process advantages. They are at 14nm already, which helps keep yield up as transistor count rises (core count). They do have an advantage in the all in one market and do very well in the budget segments. We will see if their ARM based assets play out, but it's going to be tough going for AMD with Intel on one side and NVidia on the other.
While supercomputing is a very small section of the computing world, it's not that hard to understand.
First of all, this would make for a terrible graphics card. This (deliberately) sits between a CPU and GPU. Each core in a Phi has more branching support, memory space, more complex instructions, etc than a GPU core, but is still more limited than a Xeon core (but it has wider SIMD paths).
A GPU has many more cores that have a much more limited set of operations, which is what is needed for rapid graphics render. But, those limited sets of operations can also very useful in scientific computing.
I haven't seen anybody try a three pronged approach (CPU/Phi/Nvidia Tesla), but I will admit I didn't look very hard. This is all in the name of solving really big problems.
Kind of. The advantages of RISC faded pretty fast. The footprint of a decoder between something like x86 and say, ARM is really not that much, and a decoder is just a small part of a core these days. Clock speed is an issue of thermal footprint. So, all the disadvantages of the x86 (and it's x64 extensions) faded in the face of Intel's focus on process improvements. In the end, not even the Itanium could eek out enough of a win to dethrone the x86 architecture.
Actually, the average case estimation is correct and is the most common. Your statement that hashing inserts and find are likely O(N) is O(log N) is not true at all. Two things, a perfect hash function for all integers of a given set is pretty trivial. Given than, O(1) worse case time is a given.
More generally, a cryptographic hash will (provably) have very few collisions, so it's not hard to create a hash table that really performs in constant time in all cases. The tradeoff is in space complexity
In this case, using a hash table is indeed the best solution. Your claim that hashing insert and find aren't O(1) is focusing on a basic level of understanding of hash tables. Modern implementations avoid non-constant performance with rebalancing, open addressing schemes and so on.
Which is convincing our field that diversity helps and lack of it has real impact on the people in it and the society we contribute to.
Because, if you look at discussion like this, too few are willing to admit it is an issue. Too many get defensive and throw up a ton of unrelated issues.
Because it's scary to admit you may not be as rational as you think you are, that you act on societal biases like most people. Even worse, it really hard to have a moment of doubt that you actually may not be a very good person, and all your technical skills and accomplishments does nothing to change that.
That's what this is about. Addressing diversity issues makes things better for everybody. But, no, too many steadfastly refused to accept anybody else's perspective if it is different from their own.
Look at this discussion. Not one well moderated comment had anything that remotely looked like an answer posted in the post itself. Not surprising, because it is clear that not enough people see the issues that do exist and wouldn't be that difficult to solve.
From this, it is clear that there are plenty of programmers that are threatened by the mere idea that they, as a man, could have to work with (or be replaced by) a woman that is just as skilled as they are. This is an ages old theme that plays out over and over again in every aspect of society.
The people that do really well welcome the challenge as an opportunity to improve and learn from all sides. I saw it the CS lab when I was in school. Most were clueless, many resentful, but the really smart ones just worked *with* the women in our class. They didn't tell them what to do, didn't judge, but just collaborated.
To this day, I know a few that resent that the women in our class ended up in the positions they did (most notably, one at JPL working on the Pathfinder mission). The simple fact is that she was that good and they weren't.
My career isn't going well at all, but I'm not going to blame it on so called social justice warriors and affirmative action just to feel better. Easy for me to do. One of my PhD cohort that worked with my advisor was a female. She got a faculty position somewhere, I didn't. In the end, I didn't set myself up like I thought I did, and she did better. End of story.
Making yourself feel better by dismissing progress as the action of out of control protestors (SJW) or as affirmative action gone out of control doesn't actually work in the long run.
Slashdot Mirror
It'll be nice when this obsession with having other people do everything else for you will be over. Then again, it might require a certain demographic to just grow up a bit and not panic about having do anything they don't like because they are busy.
Frankly, if you aren't horribly overworked and not constantly distracted, things like shopping for you own food, filling up your own gas and so on aren't intolerable annoyances that you must eliminate at any cost. That's where the mobile app bubble is, there's not nearly enough people that can't manage to balance work and life out there as Silicon Valley thinks there is.
I think the another factor that is keeping this going for longer is that unlike the first dot-com boom, everybody has computing power and network access. In the first dot-com crash, it quickly became clear that access to the internet outside of SV was very small, and fewer people even had PCs (outside of work) than expected, and it all fell apart with only a few left with the funding and user base to continue on.
It did spark this next bubble though. There was such a massive investment in networking infrastructure for a perceived demand that came much later than expected.
Seriously, processing all those supplements, I wouldn't be surprised if his liver starts to tank a bit down the road. And his kidneys are probably having a good time as well. Oh, well, I'm sure he'll find somebody to grow him new ones.
From the blog post:
"Partners include cloud computing providers such as Microsoft -- whose dedication to open source software was a catalyst for the project's creation"
And that's not nearly as an odd statement as it would have been two years ago.
So, first, people figured out that rm -rf / is bad, so they added an option that would disallow it by default, but you can turn it off, and rm -rf /* may still work.
But, the command never makes sense. What does it mean to remove /proc? Or /dev? People quote the ideal that you could be able to do really dumb things to be able to do really great things, but why allow things that don't make any sense at all? "rm -rf /dev/null" for example. What does that mean? It's seems reasonable to say "rm -r /" or "rm -r /*" has no meaning, as it asks to perform an operation on filesystems where it has no defined semantics, and therefore, you can always forbid it. After all, you can still list all the directories and files you want manually to get the same effect.
It's pretty much a port of the console based user space from Ubuntu, which will make a lot of developers happy (more options good). But, given how it works, you can't use bash to script windows commands (like you could in Cygwin/MSYS2). Nor can you expect to run some unix commands from the console either. On the other hand, the whole apt toolkit is at your hands, so you can install a ton of software and not wait for a Cygwin port.
I'm sure I'll get labeled as a shill (I'm not, it'd be nice, I could use the extra cash), but this is a major boost to Windows 10 as a developer OS. I get all the Windows tools I like and all the Linux bits I'm likely to want. And, yes, they are developing the .Net ecosystem into a really nice cross-platform environment for a lot of platforms.
Don't get me wrong, this is a squeeze on desktop Linux. There's likely no way they'll have the subsystem able to host X (or Wayland or Mir), it's not worth the effort. And there's no plans to port any of the Universal Windows Platform GUI stuff to Linux (again, no pay off).
The following article has more technical insights. https://insights.ubuntu.com/2016/03/30/ubuntu-on-windows-the-ubuntu-userspace-for-windows-developers
Basically, this is a Windows Subsystem for Linux. The article claimed it is using some technology from MS Research to translate the Linux syscalls to Windows syscalls (probably the Detours group and other OS team members, if I had to bet). The nice part here it is avoids what doomed the older Subsystem for Unix, having to compile apps. This subsystem just runs ELF binaries, intercepting and rewriting syscalls as needed. That's the new piece.
It'll be interesting to see how far they try to push it.
Let me be upfront about my biases first: Node is trying to a solve a problem that really doesn't need to exist: To write everything in one language. It's amazing how much demand there is for it. It's clear that the core libraries and language just can't keep up with developer demands and the number of libraries to fill those demands has exploded out of control. Npm is packed to the gills with vanity projects that are made as a resume item for developers. Sure, there's plenty of these in other ecosystems, but it's amazing what has come to depend on them.
The Node ecosystem is amazingly fragile and it's going to get worse and worse. I fully expect there will be lots of work in the future unwinding the messes people made with it and replacing it with a more appropriate platform.
"He shouldn't have picked me for the job. But next time I talk to him, I'm gonna ask him, 'Why me. You picked a loser.' "
I do hope that he came to realize just how wrong he was in the end. He was never a loser. Moral courage is the greatest strength one can have.
I know, everybody is waiting for the other shoe to drop, but there is none. The strategy here is obvious. Grow usage of Azure and displace Amazon. This means being pragmatic about platforms and gaining developer mindshare. There's billions of dollars to business to be had and Microsoft is ahead of the curve.
And it's a good story from a developer standpoint and it's getting better. Currently, where I'm at, they are still busy testing and doing proof of concepts, trying to set stuff up in Amazon, when they could have just gotten things running and started testing in Azure in minutes. They just refuse to believe that it can be that easy and they cling to virtual machine images and control they don't need (and costs them in resources).
It was overdue. Oddly, I think it was Xamarin that delayed this acquisition. I think MS would have been happy to pick them up two years ago. For all the flack Miguel de Icaza gets, he is a big open source supporter, and I bet he was concerned with how that would work being at MS and all. But, when .Net core happened, the writing was on the wall, and now they can just get .Net core to be what it needs to be.
Make no mistake, this is a play to displace some existing players and to encourage adoption of hosting on Azure and using Azure services. It's a good story for a lot of companies. You can use one set of skills (C#/.Net) to address development from end to end and you get pretty streamlined hosting (via Azure). Compared to having to assemble all the pieces from front to back, plenty of companies will take the ecosystem lock in.
Like most stuff at MS these days, it's Azure. A mobile app is just another front end to a web applications, and this makes the case of having using .Net from end to end and hosting in Azure and using things like Azure Mobile Services, Service Fabric and so on.
Look, the truly awful, horribly expensive solutions that lock people into insanely overpriced development projects are truly bad. Federal investigation into this company for ripping people off bad. No question. For the very few hospital systems that had their own home-grown systems, they do and still do okay.
But, the law had a purpose. Not having access to a comprehensive medical records causes injury and death from decisions made without the full record. It's a fairly well researched fact. But, nothing about the current systems address that need in any real way. Frankly, vendors have made claims that are (in my mind) almost criminally false.
It'd be nice to point and say that engineers are programmers are at fault, but if you look at those vendors and the medical informatics field in general, those who make the decisions are often doctors, nurses and other health professionals. The field is littered those who are unhappy with practicing medicine and think they can be software engineers and researchers instead and the result is an unspeakable mess.
The first step is that doctors, nurses, and so on will have to work with software engineers, system analysts, interaction designers and so on as peers. Not as contractors, not as subordinates, but as peers. And there are way too few doctors, etc. that can accept that a set of programmers can have just as much of an impact on the health of our population as they can. For better or for worse. And, yes, sadly, too many engineers have too much hubris and disrespect for how hard the care of other human beings truly is.
And, until we in America accept that access to universal, affordable healthcare is a fundamental right, we won't look far enough past profit to make a difference anyway. So, in the meantime, people will get needlessly hurt, will needlessly suffer and needlessly die.
While there is a lot of new proposed designs for reactors, the nature of nuclear energy is that there is waste. Waste that is insanely toxic, some of it for an incredibly long time. In the end, all nuclear energy creates a very, very long term problem that is much harder to address. Building a reactor is fairly easy compared to figuring out what to do with what it leaves behind.
The basic point of the article is dead on. The major assumption that I/O is extremely slow has driven the organization of computer architecture from the beginning. But, as the article noted, in the last few years, that equation can be changed drastically. The memory hierarchy is going to get more complicated: DRAM, NVDIMM, NVM, SSD, HD, Optical/Tape, and best using that hierarchy means that there are changes that need to be made.
For one, I think there will be a lot of research in this area. Just like modern network cards do a lot of processing before involving the CPU, it may be necessary to have similar abilities. For example, allowing the network and I/O devices to work with each other with much less CPU intervention. Or making the I/O controllers smarter so that computation can be moved to the disks. How to best organize operating systems to use this new memory hierarchy well.
The Java language and frameworks still have their fans, but the platform has just ground to a halt and has ossified into an overly rigid and verbose environment that takes increasingly longer to get anything done in compared to other alternatives.
Type erasure was hailed as the right thing. Time has show it was not, not at all. C#, Swift and Scala have all shown that proper generics really make for better APIs and programming models. More and more programmers are comfortable with higher-order programming, and Java is just behind in this respect, even with regards to C++14.
Build tools are still a hodge podge of Ant, Maven and Gradle. Maven can make even worse MSBuild file seem reasonable. And package management is just a mess. Even Microsoft is managing to use NuGet to make projects more management and modular. And Java, well, it's module improvements will be too little, too late. And Java projects are just huge monoliths that are hard to maintain and improve.
The JCP has just ground to a complete halt, and once leading edge frameworks have just lagged in terms of new ideas and innovations. I know Java programmers that loath using relational databases. Object Relational Mapping was once a strength of Java, but things like JPA have made verbose and clunky. Entity Framework just makes anything in the Java space look outdated.
It is true that the JVM itself has proven to very effective, and it's use will continue. But, it has improving contenders in LLVM and the CLR (via .Net Core). And in many ways, Java prevents the JVM from evolving (invoke dynamic is a great example).
Between Scala, Clojure and C#, there are better alternatives to Java in the enterprise space. And, in terms of mobile, Google has no reason to keep using Java. Swift has shown that developers want better, more expressive languages. Google has plenty of choices to choose from.
The reasons for using C and C++ haven't changed. The domains they serve they serve well and continue to do so. But, there are less and less reasons to use Java, and it is much easier to replace and displace unlike COBOL and related mainframe tech.
I have to agree. It's crazy how far people go to avoid just having to deal with relational database in OO languages. Sure, things like Hibernate/JPA can be clunky, but there are better models out there.
I can't count how many times I've had to explain to people that because we are using .Net, it's really not hard to use relational databases, and we don't need all those things that NoSQL people thing are revolutionary and groundbreaking, because LINQ has been working fine for years, and when it comes down to it, you've got SQL as an option too.
Does anybody remember when the NoSQL people swore that wouldn't never create new query languages, that they weren't reinventing the wheel, that this was an evolution. Guess what, everybody is inventing new query languages and ideas and features that relational databases have had for ages.
The NIH and NSF budgets would need a much larger bump to really kick off some major new initiatives, much less restore funding to useful programs. Translational medicine research programs have stalled, and major disease foundations are having to fund tons of foundational work. Also, there's no "moonshot" type of projects, for example, setting a goal of creating a battery that has 50% more capacity for the same weight (vs current best technology), notable gains in wind or solar efficiency, massive improvements to the power grid, and so on.
Well, actually, no. An optimal compiler and libraries would indeed be able to squeeze out some gains by knowing exactly what microarchitecture was being targeted versus just instruction sets.
I disagree. AMD played the largest role in failing to press advantages they had in growing markets up to the K10 microarchitecture (2006/2007). The ATI acquisition spilt their focus and reduced their resources in CPU microarchitecture, as well as tying up a lot of cash. The APU idea didn't play out nearly as well as it needed to. Then, the spinoff of Global Foundries and some process misses. Then Bulldozer. Intel killed NetBurst pretty fast. They had too, AMD was beating them on all fronts. But, they got Core online pretty quick, then Nehalem. Bulldozer was introduced in 2011, and Zen won't be online until 2017 at the earliest. So, Intel executed and AMD didn't. In the end, the antitrust settlement was a moot point. The damage was done, and the biggest blows were self inflicted.
Sure, lots of controversy over their actions in the late 90s and early 2000s, but by 2005, Intel had recovered from the mistakes made in NetBurst. Starting with the Core microarchitecture, Intel made some very strong advances in process and gains in their CPU architectures in the consumer and server spaces. AMD got distracted with the APU designs and made a huge misstep with the Bulldozer line. I think the ATI acquisition was a distraction as well. Meanwhile, Sandy Bridge was in place and allow Intel to make gains all around. By the time Haswell was in place, their entire lineup was solid. They had the core counts to match the high end Opterons, they were pushing ahead on virtualization (VT-D, APICv) and AMD was and is in a rough spot.
Zen needs to have good parity with Skylake for AMD to regain market share, and that's a tough task. Also, Intel has major process advantages. They are at 14nm already, which helps keep yield up as transistor count rises (core count). They do have an advantage in the all in one market and do very well in the budget segments. We will see if their ARM based assets play out, but it's going to be tough going for AMD with Intel on one side and NVidia on the other.
While supercomputing is a very small section of the computing world, it's not that hard to understand.
First of all, this would make for a terrible graphics card. This (deliberately) sits between a CPU and GPU. Each core in a Phi has more branching support, memory space, more complex instructions, etc than a GPU core, but is still more limited than a Xeon core (but it has wider SIMD paths).
A GPU has many more cores that have a much more limited set of operations, which is what is needed for rapid graphics render. But, those limited sets of operations can also very useful in scientific computing.
I haven't seen anybody try a three pronged approach (CPU/Phi/Nvidia Tesla), but I will admit I didn't look very hard. This is all in the name of solving really big problems.
Kind of. The advantages of RISC faded pretty fast. The footprint of a decoder between something like x86 and say, ARM is really not that much, and a decoder is just a small part of a core these days. Clock speed is an issue of thermal footprint. So, all the disadvantages of the x86 (and it's x64 extensions) faded in the face of Intel's focus on process improvements. In the end, not even the Itanium could eek out enough of a win to dethrone the x86 architecture.
Actually, the average case estimation is correct and is the most common. Your statement that hashing inserts and find are likely O(N) is O(log N) is not true at all. Two things, a perfect hash function for all integers of a given set is pretty trivial. Given than, O(1) worse case time is a given.
More generally, a cryptographic hash will (provably) have very few collisions, so it's not hard to create a hash table that really performs in constant time in all cases. The tradeoff is in space complexity
In this case, using a hash table is indeed the best solution. Your claim that hashing insert and find aren't O(1) is focusing on a basic level of understanding of hash tables. Modern implementations avoid non-constant performance with rebalancing, open addressing schemes and so on.
Which is convincing our field that diversity helps and lack of it has real impact on the people in it and the society we contribute to.
Because, if you look at discussion like this, too few are willing to admit it is an issue. Too many get defensive and throw up a ton of unrelated issues.
Because it's scary to admit you may not be as rational as you think you are, that you act on societal biases like most people. Even worse, it really hard to have a moment of doubt that you actually may not be a very good person, and all your technical skills and accomplishments does nothing to change that.
That's what this is about. Addressing diversity issues makes things better for everybody. But, no, too many steadfastly refused to accept anybody else's perspective if it is different from their own.
Look at this discussion. Not one well moderated comment had anything that remotely looked like an answer posted in the post itself. Not surprising, because it is clear that not enough people see the issues that do exist and wouldn't be that difficult to solve.
From this, it is clear that there are plenty of programmers that are threatened by the mere idea that they, as a man, could have to work with (or be replaced by) a woman that is just as skilled as they are. This is an ages old theme that plays out over and over again in every aspect of society.
The people that do really well welcome the challenge as an opportunity to improve and learn from all sides. I saw it the CS lab when I was in school. Most were clueless, many resentful, but the really smart ones just worked *with* the women in our class. They didn't tell them what to do, didn't judge, but just collaborated.
To this day, I know a few that resent that the women in our class ended up in the positions they did (most notably, one at JPL working on the Pathfinder mission). The simple fact is that she was that good and they weren't.
My career isn't going well at all, but I'm not going to blame it on so called social justice warriors and affirmative action just to feel better. Easy for me to do. One of my PhD cohort that worked with my advisor was a female. She got a faculty position somewhere, I didn't. In the end, I didn't set myself up like I thought I did, and she did better. End of story.
Making yourself feel better by dismissing progress as the action of out of control protestors (SJW) or as affirmative action gone out of control doesn't actually work in the long run.