Creative Reality Pty Ltd

Creating a new reality

  • Increase font size
  • Default font size
  • Decrease font size

Creative Reality Pty Ltd provides the following services. Contact us for information on availability.

Consulting

February 2012: Currently available.

Creative Reality provides consulting services for a wide range of computer, embedded and Internet technologies.

Recent work have been in collaborative-device multi-core concurrent software development on the Java platform written in Scala/Java for Android and JavaFX applications. Basically creating local clouds between devices when they don't have Internet connection and then merging local clouds with other local clouds or Internet cloud whenever they can get a connection. This allows for very useful remote area operations for individual and local-group connected device communicating over, say, a WiFi Direct connection.

Our background is in reliable efficient multi-threaded real-time embedded systems; from the software running in fighter aircraft computers to multi-media fiber-optic digital switches and telecommunications equipment. A lot of this work was done in C++/C.

We have worked on Internet-based solutions; including participation on one of the international web standards committees.

Creative Reality generally works on R&D projects and has been involved in more mathematical areas like image processing, weapon trajectory calculations, signal processing and combinatorial optimizations.

Currently we are developing a fast combinatorial optimization solution for useful scheduling and an animal management system suitable for Australian conditions.

See the technologies page for more details.


Tutoring

February 2012: Currently available.

Creative Reality provides tutoring services for high school maths, physics and computer related studies.

 

Language Teaching    中英文家教

February 2012: Mostly full, book soon if you are interested.

Creative Reality provides teaching services for Chinese/Mandarin and English (ESL).

更多信息,请点击




Recent Articles

 

Super-fast GC STM Value History

E-mail Print PDF

Such a simple and efficient approach. Just use a history list of WeakReference to previous values. Remember, the head of the list is a strong-reference, so the current value will always be in memory. We are only talking about the history.

You need to make sure that you retry any transaction when you can't find enough history, but you have to do this in most other solutions anyway.

Between garbage collection (GC) cycles, your history list will grow vey long until something triggers another GC. So you will have lots of history in memory and should not expect any transaction that started after the GC to have a problem getting the correct snapshot value from history. Then at around the time of GC, some transactions may have to retry, but only if they need history values and not the latest value.

 

Last Updated on Thursday, 09 February 2012 13:41 Read more...
 

Samsung Galaxy Note N7000

E-mail Print PDF

This is a review of the Samsung Galaxy Note N7000 after owning it for a few months.

I'm assuming you've read a number of reviews and have seen some video of the Note. This review is incremental to the general reviews of the Note that already exist.

The following is a quick summary of my view after using the Note:

  • The device is not too large; it could be larger.
  • The Note is probably the best example of a smartphone you can buy. The smart capabilities are more usable than any other smartphone due to its large screen size. Compare this to something like a iPhone, which is more a phone than a smart-phone because the smart capabilities are less useful with the smaller screen (otherwise there'd be no reason to buy an iPad).
  • The hardware is top-of-the-line.
  • The screen is amazing.
  • Every smartphone should have a stylus attached to it.

Single Hand Use Issue

The controversial issue with the Note is the size of the screen. From reading lots of reviews it's obvious that you can still hold the Note in your hand and carry it in your pocket - the main issue raised is using the Note with one hand. The solution for this is already beginning to appear and I would suspect we will see this becoming a common solution as more phones with larger display are released. 

If you are developing an app that is likely to be used in a one-hand scenario on a large screen then make the input part of your app smaller and move it to one corner of the phone. We have already seen this with the new update for the Note from Samsung. The keyboard is smaller and can be moved to the left or right side of the phone specifically to help one-handed use. You'd think that Google would standardize a way of doing this in the future.

I'd think that just allowing the user to shrink (and stretch) the whole screen and move it to the most useful location would be a good start. You would then get the best of all worlds, a small screen for one-handed use and a large screen the rest of the time. The device would still be the same physical size, just the usable screen area (and location) would be set by the user for what they needed at the time. This wouldn't need anything to be done by app developers, just an update to Android and then you have the feature to use or ignore. You could even shrink your screen down to half size, just to see what it would be like to own a iPhone.

Last Updated on Tuesday, 28 February 2012 23:45 Read more...
 

Fast & Simple GC STM Version History

E-mail Print PDF

What you want is to be able to start a transaction that has enough version history available just in case it needs it. This is good for read-only transactions that read a lot of data and just want a consistent dataset to work from.

Unfortunately we don't know which Refs are likely to be read, so we need to keep enough version history for all Refs. Approaches like Clojure use fixed size buffer and fail the transaction if it wants history that isn't in the buffer – it then increases the buffer size so future transactions are less likely to fail.

When I was playing with STMs in early 2010 I took the garbage collected history list approach (as described somewhere else on this site). While this kept exactly the correct amount of history in memory, it ran into other problems with task scheduling. Keeping values in memory for a transaction once it has started sounds like a good idea, but the JVM occasionally blocks a task for a very long time (maybe a full GC?). The version history approach worked so well, it would keep thousands of entries per Ref in memory and eventually cause issues for the GC and everything would slow down.

This perfect version history management approach was killed by unfavourable thread management in the JVM. But this also had a known issue that you could sleep() in a transaction and deliberately cause the same problem. You could probably block new transactions from starting if a transaction was running for too long, but when you have lots of cores not being used, maybe killing the transaction that is taking too long is the better solution.

 

Last Updated on Sunday, 05 February 2012 13:08 Read more...
 

STM Overview

E-mail Print PDF

This article is a description of a simple software transaction memory (STM) I wrote in Scala in order to better understand STMs. I'll start with a summary of performance and then go into some details. For a good introduction to writing an STM in Scala, look at the article in code commit. These are all MVCC-style STMs that guarantee transactions read from a consistent snapshot of data. Unlike other similar approaches, they don't allow write-skew - so your transactions give the same result running in parallel as they would if they ran serially; no surprises. The all provide nested transactions.

 

9.5 million transactions / second

very optimistic for low contention transactions

uses CAS instead of locking

snapshot history is limited to allow good garbage collection performance - meaning some transactions may retry due to not finding the required history

 

4.5 million transactions / second

pessimistic, transactions are isolated until commit time

uses locking instead of CAS - better for high concurrency implementations

also has limited snapshot history for good, fast GC performance

 

3.5 million transactions / second  (new alpha version)

has precise snapshot history management - you can start a transaction, sleep for a year, then continue on - the transaction will still be able to access a full snapshot history, using minimal memory to store the snapshot - based on a distributed snapshot tree for concurrent updating - read only transactions never retry

 

Last Updated on Sunday, 05 February 2012 13:02 Read more...