Showing posts from May, 2013

Plans for Chronicle 2.0

Plans for Chronicle I have a number of changes planned for Chronicle. Wider interest domain using / More modular design, extracting serialization and parsing from Chronicle. Take advantage of performance improvements using Java 7 Support for FIX directly to demonstrate it's support for text writing and parsing (as an additional module) Latest performance results I recently bought a PCI SSD and this made it clear to me that there is room for performance improvements in Chronicle.  Java 7 may provide improved performance in a thread safety. (In particular the Unsafe.putOrderXxx methods) Small Messages (13 bytes) Time to write and read as individual messages Time to write and read in batches of 10  5 billion  5 mins,  6 sec  2 mins,  6 sec 10 billion 10 mins, 13 sec  4 mins, 17 sec 15 billion 15 mins, 23 sec  6 mins, 28 sec 20 billion 20 mins, 47 sec  8 mins, 45 sec The test ExampleSimpleWriteReadMain from Chroni

The Java version of patenting the Wheel

Overview In 2001, an Australian man successfully patented a round device to aid movement.   Wheel patented in Australia More recently, a company patented using native memory as way of storing data and objects.   OFF-HEAP DIRECT-MEMORY DATA STORES, METHODS OF CREATING AND/OR MANAGING OFF-HEAP DIRECT-MEMORY DATA STORES, AND/OR SYSTEMS INCLUDING OFF-HEAP DIRECT-MEMORY DATA STORE The "off-heap" here being the Java terminology for direct or native memory. " computer systems that leverage an off-heap direct-memory data store that is massively scalable and highly efficient" It's such a good idea you might wonder, has this every been done before?   Well I deployed a project called Yellow Page's online in Australia in 2001 where the bulk of the data was in native memory. Why? because the JVMs at that time were not as efficient as I could write the code in C++ to pack and search the data. The project used EJBs, but they were implemented in native methods.

Exercise to understand double.

Many developers fell like double' rounding and representation errors and random errors which are wild and uncontrollable.   This exercise is intended to help understand what double is really doing. Write a method to convert double into text in a direct ByteBuffer which starts public static void append(ByteBuffer bb, double d) {     long val = Double.doubleToRawLongBits(d);     int sign = (int) (val >>> 63);     int exp = (int) ((val >>> 52) & 2047);     long mantissa = val & ((1L << 52) - 1); The goal is to write +/- 0.0001 to 100000.0 using no objects or double, just integer arithmetic.  Values outside this range can use BigDecimal or Double as a fall back. Implement this to convert to text the actual representation of the double, just as new BigDecimal(double) does. (Write a test which compares the values) e.g. 0.1d prints as  0.1000000000000000055511151231257827021181583404541015625 Implement this to convert to text the closest rou

Presentation on; Using BigDecimal and double

There will be a presentation for the Performance Java User's Group given at two times in June.  Both are about using BigDecimal and double together, comparing accuracy and performance.  A focus will be on use in trading systems. The first presentation will be early in Europe and late in Asia on  Saturday June 1st The second one will be late in Europe and early on the west cost of the US. Sunday June 9th Presentations I have given on-line are available at PerformanceJUG/Presentations

First talk posted online

This talk was given a Skills Matter in London and the first talk I have given which I felt happy with.  Practice is a good thing. ;) I have giving a talk with similar content on Sat 18th virtually. Bring your questions or you can post them on the Chronicle User's Group!forum/java-chronicle

Is it better to use immutable or mutable values in multi-threaded systems

@martypitt asked an interesting question which I think deserved it's own post. Most of the articles I've read of yours focus on concurrency and/or high performance. Most books I've read on concurrency espouse the benefits of immutability. If you have data shared between threads, it is a lot easier to write and debug if the data uses immutable values. i.e. you might have a mutable collection, or queue, but the data you hold in it is immutable. This is where Date could be a problem as it is mutable though it is rarely used this way. It can be treated as immutable, not by good design but by the fact most people don't use the setTime() method. Mutliple Actors My preference is to use the actor pattern and have a series of single threaded "engines" which send messages to each other via systems such as Chronicle. In this model, each thread has most data local to a thread and mutable. The benefit of using mutable state is the code is simpler (you are effect

A very interesting expert panel

This expert panel on the Future of the JVM includes Cliff Click, Charlie Hunt and Doug Lea. A number of interesting questions are asked and while I agree the points raised, I am reminded of something I state often; usually simplicity and maintainability is more important than performance. Q: struct , do we need them? The general discussion is broadly in favour of them but Cliff Click raises the point that the performance issue may be solved in the next five to seven years. My point of view:  The real value of structs is the ability to define types efficiently. e.g. instead of using String for a "name", an long for an "account id", a BigDecimal for a "price", you can define structs of those types and use those types in methods and classes without worrying about performance or overhead. Instead of  Map > map = ... public Double update(String name, long accountId, double price) you can write Map > map = ... public Pric

Performance Java User's Group (redo)

The first Performance Java User's Group was a good start, but there were some technical issues and suggestions on how it could be done better. For those who couldn't make it, especially those in Asian time zones, a revised presentation will be given on Saturday the 18th at 12:00 GMT which is 8 AM in New York, 1 PM in London and 10 PM in Sydney/Melbourne. The first meeting was originally titled an "Introduction to Memory Regions in Java" however all but one question was about Chronicle, so this presentation will focus more on Java Chronicle, where it came from and it's uses. The event details; Performance Java User's Group The presentation can be downloaded here Introduction to Chronicle (:  BTW: The Vanilla Java blog, is now getting 120K page views per month (including mirrors)  :)

First Performance Java User's Group meeting

This meeting will be online on Saturday May 4th at 7 PM (GMT+1) For more details I considered using Google hangout, but it has a limit of 9. GoToMeeting has a limit of 200. There will be a short lightening talk and an open question session. There is a longer meeting planned for Saturday June 1st, 7 PM (GMT+1) however I received a lot of feedback wanting a meeting sooner rather than later.