Soma-notes - User contributions [en]

DistOS 2014W Lecture 24

2014-04-08T14:49:51Z

Kwemason:

===The Landscape of Parallel Computing Research: A View from Berkeley===
* What sort of applications can you expect to run on distributed OS/parallize?
* How do you scale up
* We can't rely on processor improvements to provide speed-ups
* The proposed computational models that need more processor power don't really apply to regular
* Users would see the advances with games primarily
* More reliance in cloud computing in recent years
* In general you can model modern programs (Java, C, etc.) as finite state machines which are not parallizable
* Today we deal with processor limitations by using "experts" to build the system which results in a very specialized solution usually in the cloud
* Authors have found the problem but not really the process

==7 Dwarfs==
* Dense Linear Algebra
** Hard to parallize
* Sparse Linear Algebra
* Spectral Methods
* N-Body Methods
* Structured Grids
* Unstructured Grids
* Monte Carlo
==Extended Dwarfs==
* Combinational Logic
* Graph Traversal
* Dynamic Programming
* Backtrack/Branch + Bound
* Construct Graphical Models
* Finite State Machines

===Features===
* Pretty impressive on getting everyone to sign off on the report
* Connection to MapReduce
* Programs that run on distributed operating systems - applications that can be expected to be massively parallel - what sort of computational model is needed - Abstractions needed on top of the stack.
* Predictions about the processing power
* GPU's do have 1000 or more cores
* Desktop cores have not gotten that fast over the past years. They just don't run fast enough.
* Games are the only things that can't be run over the time on single thread
* Low power
* Being able to run a smart phone with 100's of transistors - stalled with the sequential processing
* Why do we need the additional processing power for ? - Games - Games - Games
* Doomsday of the IT industry
* Massive change in mobile and cloud over the past five years
* Linux a very general operating system when it started at first - hard coded to 8086 processor specialized to run on the box. Now it runs everywhere. It has all the abstractions dealing with various aspects of hardware, architecture. Multiple layers abstraction because it was useful.

DistOS 2014W Lecture 24

2014-04-08T14:42:28Z

Kwemason:

===The Landscape of Parallel Computing Research: A View from Berkeley===
* What sort of applications can you expect to run on distributed OS/parallize?
* How do you scale up
* We can't rely on processor improvements to provide speed-ups
* The proposed computational models that need more processor power don't really apply to regular
* Users would see the advances with games primarily
* More reliance in cloud computing in recent years
* In general you can model modern programs (Java, C, etc.) as finite state machines which are not parallizable
* Today we deal with processor limitations by using "experts" to build the system which results in a very specialized solution usually in the cloud
*

==7 Dwarfs==
* Dense Linear Algebra
** Hard to parallize
* Sparse Linear Algebra
* Spectral Methods
* N-Body Methods
* Structured Grids
* Unstructured Grids
* Monte Carlo
==Extended Dwarfs==
* Combinational Logic
* Graph Traversal
* Dynamic Programming
* Backtrack/Branch + Bound
* Construct Graphical Models
* Finite State Machines

===Features===
* Pretty impressive on getting everyone to sign off on the report
* Connection to MapReduce
* Programs that run on distributed operating systems - applications that can be expected to be massively parallel - what sort of computational model is needed - Abstractions needed on top of the stack.
* Predictions about the processing power
* GPU's do have 1000 or more cores
* Desktop cores have not gotten that fast over the past years. They just don't run fast enough.
* Games are the only things that can't be run over the time on single thread
* Low power
* Being able to run a smart phone with 100's of transistors - stalled with the sequential processing
* Why do we need the additional processing power for ? - Games - Games - Games
* Doomsday of the IT industry
* Massive change in mobile and cloud over the past five years
* Linux a very general operating system when it started at first - hard coded to 8086 processor specialized to run on the box. Now it runs everywhere. It has all the abstractions dealing with various aspects of hardware, architecture. Multiple layers abstraction because it was useful.

DistOS 2014W Lecture 24

2014-04-08T14:26:31Z

Kwemason:

DistOS 2014W Lecture 24

2014-04-08T14:24:20Z

Kwemason:

===The Landscape of Parallel Computing Research: A View from Berkeley===
* What sort of applications can you expect to run on distributed OS/parallise?
* How do you scale up
* We can't rely on processor improvements to provide speed-ups
* The proposed computational models that need more processor power don't really apply to regular
* Users would see the advances with games primarily
* More reliance in cloud computing in recent years

==7 Dwarfs==
* Dense Linear Algebra
* Sparse Linear Algebra
* Spectral Methods
* N-Body Methods
* Structured Grids
* Unstructured Grids
* Monte Carlo
==Extended Dwarfs==
* Combinational Logic
* Graph Traversal
* Dynamic Programming
* Backtrack/Branch + Bound
* Construct Graphical Models
* Finite State Machines

DistOS 2014W Lecture 24

2014-04-08T14:24:02Z

Kwemason:

===The Landscape of Parallel Computing Research: A View from Berkeley===
* What sort of applications can you expect to run on distributed OS/parallise?
* How do you scale up
* We can't rely on processor improvements to provide speed-ups
* The proposed computational models that need more processor power don't really apply to regular
* Users would see the advances with games primarily
* More reliance in cloud computing in recent years

==7 Dwarfs==
* Dense Linear Algebra
* Sparse Linear Algebra
* Spectral Methods
* N-Body Methods
* Structured Grids
* Unstructured Grids
* Monte Carlo
=Extended Dwarfs=
* Combinational Logic
* Graph Traversal
* Dynamic Programming
* Backtrack/Branch + Bound
* Construct Graphical Models
* Finite State Machines

DistOS 2014W Lecture 24

2014-04-08T14:18:30Z

Kwemason:

DistOS 2014W Lecture 24

2014-04-08T14:13:41Z

Kwemason:

===The Landscape of Parallel Computing Research: A View from Berkeley===
* What sort of applications can you expect to run on distributed OS/parallise?
* How do you scale up
*

DistOS 2014W Lecture 24

2014-04-08T14:12:48Z

Kwemason: Created page with "===Berkeley Paper=== * What sort of applications can you expect to run on distributed OS/parallise? * How do you scale up *"

===Berkeley Paper===
* What sort of applications can you expect to run on distributed OS/parallise?
* How do you scale up
*

DistOS 2014W Lecture 20

2014-03-25T17:58:56Z

Kwemason: /* Cassandra */

== Cassandra ==

Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure. BigTable uses GFS' built-in replication and Chubby for locking. Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].

Initialy Anil talked about google versus facebook approach to technologies.Google developed its technology internally and used for competitive advantage.Facebook developed its technology in open source manner.He talked little bit about licences. Gpl 3 you have to provide code with binary. In AGPL additional service also be given with source code.

While discussing Hbase versus Cassandra discussed why two projects with same notion are supported?Apache as a community. For any tool in CS particularly software tools, its actually important to have more than one good implementation. Only time it doesn't happen because of market realities.

Bigtable and Cassandra exposes similar apis. Bigtable needs GFS. Cassandra depends on server's file system.Anil feels cassandra cluster is easy to setup. Bigtable is designed for batch updates.Cassandra is for handling realtime stuff.

Schema design is explained in inbox example.It does not give clarity about how table will look like. Anil thinks they store lot data with messages which makes table crappy.

Cassandra is design for high speed access and online operation.

Apache Zookeeper is used for distributed configuration. Zookeeper is similar to chubby. Zookeeper is for node level information.Gossip is more about key partitioning.Zookeeper is for configuration of new node.

Cassandra uses a modified version of the Accrual Failure Detector. The idea of an Accrual Failure Detection is that failure detection module emits a value which represents a suspicion level for each of monitored nodes. The idea is to express the value of phi� on a scale that is dynamically adjusted to react network and load conditions at the monitored nodes.

Cassandra writes in immutable way like functional programming.There is no assignment in functional programming. It tries to eliminate side effects. Data is just binded you associate a name with a value. Garbage collection.

Casandra -
GFS type cluster which big table depends on
Lighter weight
All most of the readings are part of Apache
More designed for online updates for interactive lower latency
Once they write to disk they only read back
Scalable multi master database with no single point of failure
Reason for not giving out the complete detail on the table schema
Probably not just inbox search
All data in one row of a table
Its not a key-value store. Big blob of data.
Gossip based protocol - Scuttlebutt
Fixed circular ring
Consistency issue not addressed at all. Does writes in an immutable way. Never change them.

Older style network protocol - token rings
What sort of computational systems avoid changing data?
Systems talking about implementing functional like semantics.

== Comet ==

The major idea behind Comet is triggers/callbacks. There is an extensive literature in extensible operating systems, basically adding code to the operating system to better suit my application. "Generally, extensible systems suck." -[[User:Soma]]

[https://www.usenix.org/conference/osdi10/comet-active-distributed-key-value-store The presentation video of Comet]

Comet seeks to greatly expand the application space for key-value storage systems through application-specific customization.Each Comet node stores a collection of active storage objects (ASOs) that consist of a key, a value, and a set of handlers. Comet handlers run as a result of timers or storage operations, such as get or put, allowing an ASO to take dynamic, application-specific actions to customize its behaviour. Handlers are written in a simple sandboxed extension language, providing properties of safety and isolation.