Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts

Monday, November 25, 2013

Java Sumatra project for OpenCL

I found an interesting article for Java's Smatra project.
http://pc.watch.impress.co.jp/docs/column/kaigai/20130826_612591.html

I was interested in using OpenCL in Java 3 years ago, at that time there was no such projects, but  2 years ago, a solid project, Sumatra project to support OpenCL in Java seems started by Oracle/AMD.
OpenCL is very important standard to support heterogeneous hardware environment including GPU, CUP, etc. OSX of Apple is now based on LLVM (Since Snow Leopard) and supporting OpenCL. So This move of Java is actually following Apple.

Project Sumatra

This primary goal of this project is to enable Java applications to take advantage of graphics processing units (GPUs) and accelerated processing units (APUs)--whether they are discrete devices or integrated with a CPU--to improve performance.
We expect the initial focus to be on the Hotspot JVM, enabling code generation, runtime support and garbage collection on GPUs. Once basic capabilities are in place in the JVM, we will also examine how to best expose GPU support to application and/or library developers, initially leveraging the new Java 8 Lambda language and library features. As the project progress, we may identify challenges with the Java API and constructs which may lead to new language, JVM or library extensions that will need standardization under the JCP process. While the Java language is an obvious focus, we also anticipate that this project will provide guidance for other JVM-hosted languages such as JavaScript/Nashorn, Scala and JRuby.
You can follow the project and get involved on the sumatra-dev mailing list.

Related projects and material

This Project is sponsored by the HotSpot Group.

This is quite interesting direction, also Java 8's support of Lambda(closure) seems associated with this parallel computing based on GPGPU or OpenCL approach.

I installed two projects in Windows. but it looks like Intel only supports Windows OS(except xeon). In order to use this on Linux, we may need to install AMD's SDK. It seems usable for Intel's graphics core in the CPU(like i5 etc).

1) https://code.google.com/p/aparapi/
2a) http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/
2b) http://software.intel.com/en-us/vcsource/tools/opencl

These are other related projects.

http://openjdk.java.net/groups/hotspot/

http://openjdk.java.net/projects/mlvm/index.html

http://download.java.net/openjdk/jdk7/

Here is a qupte from jdk8 project. It actually seems related to Sumatra project..
 http://mreinhold.org/blog/jdk8-preview

JDK 8 Developer Preview
2013/09/09 10:39:26 -07:00 
The JDK 8 De­vel­oper Pre­view (a.k.a. Mile­stone 8) builds are now avail­able!
This mile­stone is in­tended for broad test­ing by de­vel­op­ers. We’ve run all tests on all Or­a­cle-sup­ported plat­forms and haven’t found any glar­ing is­sues. We’ve also fixed many of the bugs dis­cov­ered since we reached the Fea­ture Com­plete mile­stone back in June.
The prin­ci­pal fea­ture of this re­lease is Pro­ject Lambda (JSR 335), which aims to make it eas­ier to write code for mul­ti­core proces­sors. It adds lambda ex­pres­sions, de­fault meth­ods, and method ref­er­ences to the Java pro­gram­ming lan­guage, and ex­tends the li­braries to sup­port par­al­leliz­able op­er­a­tions upon streamed data.
There are, of course, many other new fea­tures, in­clud­ing a new Date and Time API (JSR 310), Com­pact Pro­files, the Nashorn JavaScript En­gine, and even some anti-fea­tures such as the re­moval of the Per­ma­nent Gen­er­a­tion from the HotSpot vir­tual ma­chine. A com­plete list of new fea­tures is avail­able on the JDK 8 Fea­tures page.
If you’ve been watch­ing JDK 8 evolve from afar then now is an ex­cel­lent time to down­load a build and try it out—the sooner the bet­ter! Let us know if your ex­ist­ing code doesn’t com­pile and run cor­rectly on JDK 8, if it runs slower than be­fore, if it crashes the JVM, or if there are any re­main­ing de­sign is­sues in the new lan­guage and API fea­tures.
We’ll do our best to read, eval­u­ate, and act on all feed­back re­ceived via the usual bug-re­port­ing chan­nel be­tween now and the end of Oc­to­ber. After that we’ll grad­u­ally ramp down the rate of change in order to sta­bi­lize the code, so bugs re­ported later on might not get fixed in time for the GA re­lease.
Other Java 8 related info:

http://www.infoq.com/news/2013/06/jdk8-almost-feature-complete

https://blogs.oracle.com/thejavatutorials/entry/jdk_8_documentation_developer_preview

This kind of direction should be considered in Dart as well.
This will affect both of client and server. Since JavaScript seems going to support OpenGL like architecture, Dart need to handle it also. But server side support would be more natural fit for high performance computation using OpenGL.

In fact, I was surprised to know the direction of Java 8 was shifted to this direction. Previously it was aiming to support of modules etc, but the focus seems changed quite  a lot.

Thursday, October 10, 2013

JsonMapper and JPA

One area I haven't investigated for Jason Mapper is the case where entity  have general network structure rather than tree structure where no sharing of objects occurs

I need to check how dart handle such cases, for parse, stringify.
When I checked the dart:json code, there was a code to check repeated occurrence  (for the recent version of Json lib.)

for stringify, if it does not check, either the same entity will be serialized repeatedly, and worst, if there are circular references, it will go into infinite loop.

for parse, essentially original json string need to have some id information so that other part of json code can refer to it.
when json see new json id, it may not be loaded yet, so substituting the actual object must be delayed until that object is created. so the fromJson will be more complicated.(but it will be still simple if we push closure to assign to the entity field  with given parameter, and when object is created with given id, it should  retrieve those closures and apply them with the newly created entity object.)

There is a Java project called jackson, I guess it will handle such cases, and if there is a some notation to represent such reference in json, Dart's json mapper should follow the convention.

This is important, since json is good format to communicate Java and Dart.
 If both are following the same format, we can pass Dart's object to Java, and vice versa.
This may happen through Dart's VM and JVM message passing protocol similar to Dart's  javascript call mechanisms (although I don't know if such lib exist now), or through HTTP protocol using REST style API such as CouchDB.
Both approaches are relying on converting an entity object to json string.

The useful application of this approach will be the support of JPA(Java Persistence API) in Dart.
It will be achieved by a Restfull service in HTTP server implemented by Servlet where the mapped Java object are to be serialized to Json string(using Jackson).

Since building JPA like service in Dart will be not simple task, this will be a quickest  way. the main problem will be some performance issues for server side Dart's access to JPA.(For client side, if it directly calls this servlet service, there should be no performance issues.) 
But such loosely coupled architecture will allow to use separate CPU cores for JVM to run Java Servlet for JPA and Dart VM to run HTTP client(server) to consume(provide) JPA services from servlet, so it may not be so inefficient.

Also if we provide such restful service, it may be called directly from client side (browser).
We may consider an additional query for Restful API in which query condition can be expressed as a dart expression  like CouchDB (CouchDB uses JavaScript for such filter function).
This may require some dynamic loading of Dart code, so it may not be so straightforward, but it may be interesting to investigate the possibility.

For such a binding, there should be a tool to map between Dart and Java persistent classes.
One direction is to start from annotated Dart classes, and generate corresponding Java JPA entity classes with the same annotation.

The other direction is to start JPA Entity Java classes, and generate Dart annotated classes.

For this end, we should define Dart annotation classes corresponding to JPA annotation classes in Java.