... On the other hand, git and mercurial just don't have the tooling (GUI) that subversion has with TortoiseSVN, SmartSVN, the Eclipse SVN Handler... There might be equivalents, but they are not as good.
I've used TortoiseHg for a while now, and it seems to be complete. Is it just that I'm a Mercurial Noob?
The ultimate end to this trend is to build a system that is just core processing logic, with logic and memory all fused as closely as possible. I call it the BitGrid... it consists of 4bit look up tables hooked into an orthogonal grid. Because every single table can be used simultaneously, there is no Von Neuman bottleneck to worry about.
It's so obvious how to blow the doors off the competition in this race... if everything is all hitting the limits of the Von Neuman wall... go around it with something like a BitGrid, which is a reconfigurable systolic array granular down to the bit level. Using the latest memristors with this idea it should be quite feasible to build Exaflop computers for the desktop.
One should never trust an application, I'm in agreement on that.
The user owns the machine, they should be trusted to decide what is done with it. If you think I'm wrong... let me explain...
The reason we don't want to trust users is because they have a demonstrated history of bad choices, which result in a lot of work for the geeks who have to clean up the mess. We have a better track record, so we assume that it must be because we are smarter than they are. This is only true to a limited extent.
The reason the user makes bad choices is because are given the wrong choice to make. Instead of asking what extent of permission a program should be granted, the user is given an all or nothing choice. It's not possible for them to "try out" a program without risking everything. This is just plain nuts.
Capability based security offers a way to express the wishes of the user in a manner which NEVER trusts an application... but rather places the responsibility for limiting system changes in the operating system, where it belongs.
It is only when we finally get out of or smug self congratulatory slumber that it's possible consider that the typical user is not an idiot prone to randomly pressing OK.
We need to offer sane choices, and a sane security model... Capability Based Security is the only way to go.
Google... unfortunately, isn't any wiser and misses the boat here, but by a slightly smaller margin.
The use of a string of cells to handle long lines IS a ridiculous was of transistors, and a fairly large source of delay.. that's for sure. The ability to use the cell in the other 3 directions while passing a signal kinda makes up for it.
The big bet with the bitgrid is that the flexibility in routing makes it possible to optimized designs in ways impractical with FPGAs. The ability to flip or rotate a given virtual hardware object is something that doesn't happen easily with FPGAs, as far as I know.
I have done a simulator, even going so far as to guess what the energy to flip a bit is... it would be very useful to have a realistic estimate, so I can tell just how much energy is required to do an FFT, or whatever.
I know long lines are very useful when you're squeezing the last bit of functionality out of an FPGA, my hope is to let the compiler do that by moving the pieces around and try several optimizations.
Thanks for sticking with the thread... you've given me some good things to think about
It took some digging, but at the core of the CAL1024 is a very limited compute logic (2 input LUT) and lots of routing logic.
The sole innovative feature of the bitgrid is its complete lack of routing logic. Any LUT can be doing a part of a computation, in fact you could have 4 different computations going on at the same time in a given cell, as a maximum.
Well, I may an idiot, but I think you've jumped to that conclusion prematurely. I have done quite a bit of research in this area trying to find some prior art, things got close a few times, but no cigar.
As to your claim that it's possible to do this with an existing FPGA, According to Digikey, their "biggest" Xilinx Spartan 6 FPGA, which prices out at about $150 is capable of providing 5831 CLBs... which is less than 1% of the capability of the bitgrid chip I proposed above.
A chip devoid of specialized routing hardware and all the complexity that entails, will be far cheaper to design, test, and ship out the door. I estimate, base on NO actual experience, just a gut hunch... that $10.00 for the final device would give a very nice profit margin to the manufacturer. I would imagine that a second generation device would include far more cells, and perhaps some specialized I/O.
The FPGA industry optimized on complexity, and trying to get the maximum performance out of a piece of silicon. It's my thesis that they prematurely optimized, and a much simpler architecture could provide a new class of solutions which may be far more efficient for a number of applications
As you said, building the FPGA isn't the hard part... actually understanding the architecture enough to maximize its use is. The BitGrid is dead simple, can process data in all 4 directions simultaneously, can route around defects, and can add/remove a bit of precision from a function with no major hassles. This is NOT the case with an FPGA design.
The thing I really need to find out, is just how much power does a 4 input/ 4 output LUT actually consume. I haven't been able to find that type of information, as it's all behind paywalls.
In any case, thanks for the time and attention and discussion.
The FPGA is a course grained device, which is generally heterogeneous. A lot of effort in the actual designs that use an FPGA centers around getting a design which meets timing requirements and routability.
The simplicity, uniformity, and symmetry of a bitgrid design allows for almost trivial movement of portions of a computation, which also allows it to route around hardware failure.
The systolic array is any array of computational elements each of which runs its own program.... almost any supercomputer is a systolic array.
I've not really invented anything... but I have re-imagined what FPGAs could be, if someone were to toss out routing and go as fine grained as feasible.
There are definitive differences between the FPGA and the Bit Grid... and I hope this reply points them out sufficiently to merit further attention.
Long ago I mis-understood what a "bit slice" processor really was... and the bit grid was born. If I'm right it's possible to build something to kick the current technology to the curb, running in a single rack.
Due to the Von Neuman bottleneck, most of the transistors in a computer are in the RAM, which is idle except for the row/column being accessed at a given time. The bitgrid gets around this by building a grid of look up tables which operate on 4 bits in and 4 bits. It should be quite easy to build a chip which has a million of these tables in a 1000x1000 grid. This would allow data to flow off the edges at a result per clock cycle.... which in modern CMOS is at least 1 Ghz.
Finding applications to run on a theoretical chip isn't easy... but synthetic focus imagery comes to mind. Imagine a survey plane with an array of cameras, generating 3d imagery with a resolution of 1 centimeter in all 3 dimensions, at a speed of 1000 kph at a height of 15,000 meters, giving a swath 5 km wide.... that's 14 Gigapixels/second of final product. I believe it's feasible to do this with the bit grid chip.
Anyone want to sponsor the research? If not, I'll stick to my day job.
It's not about Microsoft having to "man up"... it's more about a structural flaw in the basic paradigm we all know and love... the idea of running everything a default permissive environment.
Until capability based security is put into common use, this problem will NEVER go away.
'Though it will be a real-time system with Windows software, source code and architecture will be proprietary, giving us the exclusivity of owning a system unknown to foreign elements and protect our security system,' Saraswat said after unveiling a training facility at the Centre for Artificial Intelligence and Robotics (CAIR), a defence lab in this tech hub.
Classic first timer mistake.
No mention of capability based security either.
At best they end up with a bad clone of Windows or Linux.
I believe a bitgrid chip would cost $10k or so for the first samples. If I'm right about this, it should be capable of scaling into the Exaflop range if you slapped enough of them together, at a cost of $10,000,000.
It turns out there is already a protocol in place for doing a lot of the grunt work. It allows for the federation of changes to a given object across organizations. While I wouldn't want to try build an ACID database on it in my free time, I supposed it could eventually be done with a larger team of programmers.
A query can be distributed across machines, which is what the map-reduce meme is all about. The next stage is to eliminate redundant calculations across time. LiveSQL will do that.
I think that the real innovation will be a variation of SQL that allows for the persistence of queries, such that they continue to yield new results as new data is found to match them in the database. If you have a database of a trillion web pages, and you continue to put more in, it doesn't make sense to re-scan all of the existing records each time you decide you need to get the results of the query again. It should be possible, and far more computationally efficient to have a stream of results from a LiveSQL query that can feed a stream, instead of batch mode.
I've registered the domain name livesql.org as a first step to helping to organize this idea and perhaps set up a standard.
The real problem with wave, from my perspective were bad design decisions.
1. To make things familiar, they made it look like a threaded Slashdot discussion, and made each element of text a big block with a lot of decoration, framing, etc. This was way too chunky, as there was no way to highlight or otherwise mark up someone else's text.
2. There was no way to prune or trim a discussion, which made them stretch on to infinity.
3. You really couldn't collaborate on a piece of text, you could only have a conversation about it.
4. There was no desktop native client, which means you always had the slow and buggy web interface to deal with. It should have been smooth and fast, like a Word document open in more than one place in real time... but it wasn't.
5. Did they really have to waste all that screen space so you knew who owned every word?
I think the criticisms to date of Wave really miss the mark. Had it been more interactive and less clunky, it would have taken off. The protocol is open, and someone could fix the above mentioned problems. I'd be willing to help.
Capability based security has been patiently waiting for people to get fed up with the broken mess that is user based security.... it's time to end this mess by properly securing everyone's computers.
Learn at least one source control system, such as Git or Mercurial. You'll need to be able to share your code with others, and these are the modern ways of doing so. Having a global undo is also very freeing in terms of being able to experiment.
The model used to computerize the stock market was wrong.
Everything should be in batch mode. Bids and Asks would be you put it into the system, then matched in a batch according to well known rules, and then the results of the matching process would be sent to everyone. The batch would run every 5 minutes as an example. This would prevent front running and many other forms mischievous behavior.
Batch mode is under-appreciated in the the Internet Age.
... On the other hand, git and mercurial just don't have the tooling (GUI) that subversion has with TortoiseSVN, SmartSVN, the Eclipse SVN Handler... There might be equivalents, but they are not as good.
I've used TortoiseHg for a while now, and it seems to be complete. Is it just that I'm a Mercurial Noob?
The ultimate end to this trend is to build a system that is just core processing logic, with logic and memory all fused as closely as possible. I call it the BitGrid... it consists of 4bit look up tables hooked into an orthogonal grid. Because every single table can be used simultaneously, there is no Von Neuman bottleneck to worry about.
Petaflops... here we come.... !
It's so obvious how to blow the doors off the competition in this race... if everything is all hitting the limits of the Von Neuman wall... go around it with something like a BitGrid, which is a reconfigurable systolic array granular down to the bit level. Using the latest memristors with this idea it should be quite feasible to build Exaflop computers for the desktop.
One should never trust an application, I'm in agreement on that.
The user owns the machine, they should be trusted to decide what is done with it. If you think I'm wrong... let me explain...
The reason we don't want to trust users is because they have a demonstrated history of bad choices, which result in a lot of work for the geeks who have to clean up the mess. We have a better track record, so we ass u me that it must be because we are smarter than they are. This is only true to a limited extent.
The reason the user makes bad choices is because are given the wrong choice to make. Instead of asking what extent of permission a program should be granted, the user is given an all or nothing choice. It's not possible for them to "try out" a program without risking everything. This is just plain nuts.
Capability based security offers a way to express the wishes of the user in a manner which NEVER trusts an application... but rather places the responsibility for limiting system changes in the operating system, where it belongs.
It is only when we finally get out of or smug self congratulatory slumber that it's possible consider that the typical user is not an idiot prone to randomly pressing OK.
We need to offer sane choices, and a sane security model... Capability Based Security is the only way to go.
Google... unfortunately, isn't any wiser and misses the boat here, but by a slightly smaller margin.
Selling wave as an email replacement was a mistake.
The packaging that wave came it was what killed it.
A group of people could work on a document, or stream of thoughts, refining things as they went... that part was brilliant.
The insistence that each person had to "own" a piece of it.. meant each document was a chain of links, instead of a seamless whole.
This packaging choice killed the usability, and lead to the downfall of wave.
Let's hope this can be overcome in the next iteration.
I really hate this kind of thing... a potentially useful technology for building electronics devices at home, and it's behind a paywall.
The use of a string of cells to handle long lines IS a ridiculous was of transistors, and a fairly large source of delay.. that's for sure. The ability to use the cell in the other 3 directions while passing a signal kinda makes up for it.
The big bet with the bitgrid is that the flexibility in routing makes it possible to optimized designs in ways impractical with FPGAs. The ability to flip or rotate a given virtual hardware object is something that doesn't happen easily with FPGAs, as far as I know.
I have done a simulator, even going so far as to guess what the energy to flip a bit is... it would be very useful to have a realistic estimate, so I can tell just how much energy is required to do an FFT, or whatever.
I know long lines are very useful when you're squeezing the last bit of functionality out of an FPGA, my hope is to let the compiler do that by moving the pieces around and try several optimizations.
Thanks for sticking with the thread... you've given me some good things to think about
It took some digging, but at the core of the CAL1024 is a very limited compute logic (2 input LUT) and lots of routing logic.
The sole innovative feature of the bitgrid is its complete lack of routing logic. Any LUT can be doing a part of a computation, in fact you could have 4 different computations going on at the same time in a given cell, as a maximum.
Well, I may an idiot, but I think you've jumped to that conclusion prematurely. I have done quite a bit of research in this area trying to find some prior art, things got close a few times, but no cigar.
As to your claim that it's possible to do this with an existing FPGA, According to Digikey, their "biggest" Xilinx Spartan 6 FPGA, which prices out at about $150 is capable of providing 5831 CLBs... which is less than 1% of the capability of the bitgrid chip I proposed above.
A chip devoid of specialized routing hardware and all the complexity that entails, will be far cheaper to design, test, and ship out the door. I estimate, base on NO actual experience, just a gut hunch... that $10.00 for the final device would give a very nice profit margin to the manufacturer. I would imagine that a second generation device would include far more cells, and perhaps some specialized I/O.
The FPGA industry optimized on complexity, and trying to get the maximum performance out of a piece of silicon. It's my thesis that they prematurely optimized, and a much simpler architecture could provide a new class of solutions which may be far more efficient for a number of applications
As you said, building the FPGA isn't the hard part... actually understanding the architecture enough to maximize its use is. The BitGrid is dead simple, can process data in all 4 directions simultaneously, can route around defects, and can add/remove a bit of precision from a function with no major hassles. This is NOT the case with an FPGA design.
The thing I really need to find out, is just how much power does a 4 input/ 4 output LUT actually consume. I haven't been able to find that type of information, as it's all behind paywalls.
In any case, thanks for the time and attention and discussion.
It's unfortunate that the article is behind a payway, as it does look quite interesting.
The simplicity, uniformity, and symmetry of a bitgrid design allows for almost trivial movement of portions of a computation, which also allows it to route around hardware failure.
The systolic array is any array of computational elements each of which runs its own program.... almost any supercomputer is a systolic array.
I've not really invented anything... but I have re-imagined what FPGAs could be, if someone were to toss out routing and go as fine grained as feasible.
There are definitive differences between the FPGA and the Bit Grid... and I hope this reply points them out sufficiently to merit further attention.
Due to the Von Neuman bottleneck, most of the transistors in a computer are in the RAM, which is idle except for the row/column being accessed at a given time. The bitgrid gets around this by building a grid of look up tables which operate on 4 bits in and 4 bits. It should be quite easy to build a chip which has a million of these tables in a 1000x1000 grid. This would allow data to flow off the edges at a result per clock cycle.... which in modern CMOS is at least 1 Ghz.
Finding applications to run on a theoretical chip isn't easy... but synthetic focus imagery comes to mind. Imagine a survey plane with an array of cameras, generating 3d imagery with a resolution of 1 centimeter in all 3 dimensions, at a speed of 1000 kph at a height of 15,000 meters, giving a swath 5 km wide.... that's 14 Gigapixels/second of final product. I believe it's feasible to do this with the bit grid chip.
Anyone want to sponsor the research? If not, I'll stick to my day job.
It's not about Microsoft having to "man up"... it's more about a structural flaw in the basic paradigm we all know and love... the idea of running everything a default permissive environment. Until capability based security is put into common use, this problem will NEVER go away.
'Though it will be a real-time system with Windows software, source code and architecture will be proprietary, giving us the exclusivity of owning a system unknown to foreign elements and protect our security system,' Saraswat said after unveiling a training facility at the Centre for Artificial Intelligence and Robotics (CAIR), a defence lab in this tech hub.
Classic first timer mistake.
No mention of capability based security either.
At best they end up with a bad clone of Windows or Linux.
I believe a bitgrid chip would cost $10k or so for the first samples. If I'm right about this, it should be capable of scaling into the Exaflop range if you slapped enough of them together, at a cost of $10,000,000.
For the first time ever... mentioning a site was down on ./ made it come back to life.
Yes... and I gave away a similar idea 2 years ago.
It turns out there is already a protocol in place for doing a lot of the grunt work. It allows for the federation of changes to a given object across organizations. While I wouldn't want to try build an ACID database on it in my free time, I supposed it could eventually be done with a larger team of programmers.
A query can be distributed across machines, which is what the map-reduce meme is all about. The next stage is to eliminate redundant calculations across time. LiveSQL will do that.
one has to wait a bit for these things, as DNS updates are still batch oriented. 8)
I think that the real innovation will be a variation of SQL that allows for the persistence of queries, such that they continue to yield new results as new data is found to match them in the database. If you have a database of a trillion web pages, and you continue to put more in, it doesn't make sense to re-scan all of the existing records each time you decide you need to get the results of the query again. It should be possible, and far more computationally efficient to have a stream of results from a LiveSQL query that can feed a stream, instead of batch mode.
I've registered the domain name livesql.org as a first step to helping to organize this idea and perhaps set up a standard.
The real problem with wave, from my perspective were bad design decisions.
1. To make things familiar, they made it look like a threaded Slashdot discussion, and made each element of text a big block with a lot of decoration, framing, etc. This was way too chunky, as there was no way to highlight or otherwise mark up someone else's text.
2. There was no way to prune or trim a discussion, which made them stretch on to infinity.
3. You really couldn't collaborate on a piece of text, you could only have a conversation about it.
4. There was no desktop native client, which means you always had the slow and buggy web interface to deal with. It should have been smooth and fast, like a Word document open in more than one place in real time... but it wasn't.
5. Did they really have to waste all that screen space so you knew who owned every word?
I think the criticisms to date of Wave really miss the mark. Had it been more interactive and less clunky, it would have taken off. The protocol is open, and someone could fix the above mentioned problems. I'd be willing to help.
The fact that there is a term critical thinking is a sure sign of a problem... it implies that most thinking really isn't.
Capability based security has been patiently waiting for people to get fed up with the broken mess that is user based security.... it's time to end this mess by properly securing everyone's computers.
Learn at least one source control system, such as Git or Mercurial. You'll need to be able to share your code with others, and these are the modern ways of doing so. Having a global undo is also very freeing in terms of being able to experiment.
The model used to computerize the stock market was wrong.
Everything should be in batch mode. Bids and Asks would be you put it into the system, then matched in a batch according to well known rules, and then the results of the matching process would be sent to everyone. The batch would run every 5 minutes as an example. This would prevent front running and many other forms mischievous behavior.
Batch mode is under-appreciated in the the Internet Age.