<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:georss='http://www.georss.org/georss' xmlns:gd='http://schemas.google.com/g/2005' xmlns:thr='http://purl.org/syndication/thread/1.0'><id>tag:blogger.com,1999:blog-6382152282482193920</id><updated>2011-11-27T17:11:13.549-08:00</updated><category term='CUDA'/><category term='GPU'/><category term='Data Security'/><category term='Percistant storage'/><category term='Trees'/><category term='32Bit'/><category term='64Bit'/><category term='Index'/><category term='SSD'/><category term='C'/><category term='Adress space'/><category term='databases'/><title type='text'>Experimenting with database management systems</title><subtitle type='html'>In the world full of new news and events many Ideas come up how to work with new technology. This blog is intended as an outlet to the world for these ideas. Comments and discussions are welcome.</subtitle><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://databastech.blogspot.com/feeds/posts/default'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/6382152282482193920/posts/default?max-results=100'/><link rel='alternate' type='text/html' href='http://databastech.blogspot.com/'/><link rel='hub' href='http://pubsubhubbub.appspot.com/'/><author><name>Peter</name><uri>http://www.blogger.com/profile/03157941310388931591</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>3</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>100</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-6382152282482193920.post-1595742818592775175</id><published>2010-02-10T13:12:00.000-08:00</published><updated>2010-02-10T13:20:36.803-08:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='CUDA'/><category scheme='http://www.blogger.com/atom/ns#' term='databases'/><category scheme='http://www.blogger.com/atom/ns#' term='Data Security'/><category scheme='http://www.blogger.com/atom/ns#' term='GPU'/><title type='text'>CUDA Data security</title><content type='html'>CUDA, DirectX and OpenCL. Wow how great that technology is. Simply write your C code and have it executed on your GPU on up to 512 cores in parallel (NVIDIA Fermi architecture). I have seen many interesting approaches to use these methods. Except for the simulations and numerical calculation guys, like physics or weather forecasting, there are a few approaches to use the GPUs for databases. Simply execute a few operations on the GPU, like Joins or aggregations. Ok well lets have the smart people do those things..But what about data security at this point? Lets look at CUDA. According to the documentation all data is kept on the device memory as long as the app runs. The GPU hardware is only isolated by a driver that actually should protect other applications to access data on the device. Well I don't think that the driver developers have payed too much attention to data security yet. &lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Here is my challenge. I have one approach of how to access another programs data on the device memory. Does anyone else have one? &lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6382152282482193920-1595742818592775175?l=databastech.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://databastech.blogspot.com/feeds/1595742818592775175/comments/default' title='Kommentare zum Post'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=6382152282482193920&amp;postID=1595742818592775175' title='1 Kommentare'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/6382152282482193920/posts/default/1595742818592775175'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/6382152282482193920/posts/default/1595742818592775175'/><link rel='alternate' type='text/html' href='http://databastech.blogspot.com/2010/02/cuda-data-security.html' title='CUDA Data security'/><author><name>Peter</name><uri>http://www.blogger.com/profile/03157941310388931591</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-6382152282482193920.post-2681711081030631928</id><published>2009-08-19T16:17:00.000-07:00</published><updated>2009-08-19T16:38:40.497-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='C'/><category scheme='http://www.blogger.com/atom/ns#' term='32Bit'/><category scheme='http://www.blogger.com/atom/ns#' term='Trees'/><category scheme='http://www.blogger.com/atom/ns#' term='64Bit'/><category scheme='http://www.blogger.com/atom/ns#' term='Adress space'/><category scheme='http://www.blogger.com/atom/ns#' term='Index'/><title type='text'>Leveraging 64bit adress space</title><content type='html'>I have been developing applications for 32 bit systems ever since I was 13. This year I got around my first 64bit app. Amazing. When the vendors introduced 64bit for common use (aka desktop and laptops) I started thinking "what hell of an app would use 64bit on a laptop".  This app I got to work on was an index for data. Nothing too fancy. But very data centric. Since the goal was to have very fast operations on the index we had to tune a few knobs. One of the knobs is the addres space. Virtual 32bit address spaces. The principle is that you store a base pointer within your system and then reference everything from this base pointer. Not with 64bit but with 32bit. What is that any use for? Well if you have a tree structure (like and AVL or B-Tree) one of the main concerns is the node size. Since the nodes of a tree contain pointers to children the pointers are 64bit wide consuming more space than necessary. To get rid of this space consumption simply use the reduced address space. You can of course fit it to your personal needs in terms of space necessity.&lt;br /&gt;&lt;br /&gt;Since the bottleneck between CPU and RAM will exist for the next N years (with N &gt;&gt;10 years) we still need to reduce the number of bytes pushed around between RAM and CPU. Reducing the size of pointers is one approach.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6382152282482193920-2681711081030631928?l=databastech.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://databastech.blogspot.com/feeds/2681711081030631928/comments/default' title='Kommentare zum Post'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=6382152282482193920&amp;postID=2681711081030631928' title='0 Kommentare'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/6382152282482193920/posts/default/2681711081030631928'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/6382152282482193920/posts/default/2681711081030631928'/><link rel='alternate' type='text/html' href='http://databastech.blogspot.com/2009/08/leveraging-64bit-adress-space.html' title='Leveraging 64bit adress space'/><author><name>Peter</name><uri>http://www.blogger.com/profile/03157941310388931591</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-6382152282482193920.post-1868428065481336693</id><published>2009-08-12T23:59:00.001-07:00</published><updated>2009-08-13T00:51:14.327-07:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='databases'/><category scheme='http://www.blogger.com/atom/ns#' term='SSD'/><category scheme='http://www.blogger.com/atom/ns#' term='Percistant storage'/><title type='text'>SSD</title><content type='html'>For many years the rotating monster (harddrive) has been one big thing of interest for the algorithms around database systems. Indexes where created to retrieve and access data faster from memory than from disc. With SSDs a faster persistent storage medium is being established. At first everything seems like that with a very fast read we would have to buy a high penalty for sequential write (something like 1:10 in terms of throughput). So you can actually different index structures and algorithms for SSDs and HDDs that work optimal on one hardware and suboptimal for the other. But over time product development will definitely remove the write penalty from SSDs. Not completly but quite significantly. So now what to do with a disc? What a bout another storage layer between RAM and HDD?&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6382152282482193920-1868428065481336693?l=databastech.blogspot.com' alt='' /&gt;&lt;/div&gt;</content><link rel='replies' type='application/atom+xml' href='http://databastech.blogspot.com/feeds/1868428065481336693/comments/default' title='Kommentare zum Post'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=6382152282482193920&amp;postID=1868428065481336693' title='0 Kommentare'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/6382152282482193920/posts/default/1868428065481336693'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/6382152282482193920/posts/default/1868428065481336693'/><link rel='alternate' type='text/html' href='http://databastech.blogspot.com/2009/08/ss.html' title='SSD'/><author><name>Peter</name><uri>http://www.blogger.com/profile/03157941310388931591</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry></feed>
