Easy to use Java performance booster

[Alexey Bezrodnov]

Tim Cooke wrote:I propose a challenge. Mostly for you Alexey.

No Tim. If I take every challenge on the net, then I most probably will die of hunger in a few days.

But if there is a compensation for my efforts, then I think it is possible to outperform pure Java solution for the task you have proposed.

Tim Cooke wrote:The company I work for is one of the biggest, if not the biggest, financial trading platforms in the world, and we spend a lot of resources finding ways to improve the throughput speed of our systems. Blindingly fast queues are a big deal. So, if you can outperform Martin's queue implementation (which I believe to be the fastest there is) then you're really on to something.

Are you up for a challenge?

Sorry, but having a big money and asking to help you for free is a bit unfair. But if your company is ready to pay for the job, then it is possible to make a deal.

[Alexey Bezrodnov]

Henry Wong wrote:In fact, IMO, this is why no-one uses an assembler anymore.

It's too bold statement to be true.

Henry Wong wrote:And of course, Java can't support this as there is no way to do this in platform independent manner.

Again, it's too bold and this link just proves that it is possible.

[Tim Cooke]

OK fair enough, up to you of course.

Alexey Bezrodnov wrote:having a big money and asking to help you for free is a bit unfair

Apologies. I can see how it may have come across that way but it certainly wasn't my intention.

I was merely letting you know of a real world application that you could consider competing for, that could earn you some serious income.

[Winston Gutkowski]

Alexey Bezrodnov wrote:It's too bold statement to be true.

Not so sure. Even most geeks I know that love bit-and-byte-twiddling and writing drivers use C these days; and I suspect that similar ops in Java are running in peko-second time nowadays, given that my 7-year old Dell can do them in sub-nanosecond (averaged over billions of ops).

My clunker can even create 20 million simple objects a second in Java, so I wonder where the "efficiency" can be tweaked?

Fun stuff though.

Winston

[Gary W. Lucas]

Interesting idea. Does your solution address any memory management or object-construction related issues?

I've done a lot of work with performance-related implementations, including image processing, data compression, and scientific applications. And as long as I've managed to avoid the few but truly unforgivable performance traps in the Java API, I've always been impressed by how fast Java runs... Not just a little impressed, but downright blown away. Still, I am always looking an opportunity for improving the user experience for my software, and even a reduction of a few seconds of run time can be meaningful.

Anyway, I have a question about a problem I am working on right now. One of the tools used for processing surface elevation data is the Triangulated Irregular Network (TIN) such as the one shown at this picture of a TIN. With the advent of lidar technology (laser-based elevation surveys with a point-spacing of 1 meter per sample), it is common to process files that contain multiple millions of sample points. My current implementation can build a TIN from 1 million points in about 0.4 seconds on a typical PC... But there are issues.

The biggest issue is that I am averaging about 320 bytes per vertex. In an optimized TIN, N vertices results in 2*N triangles. In Java an object always has a reference to its class. So there's at least 4 and probably 8 bytes per object... My triangle class has references to 3 vertices (of course) and 3 neighboring triangles. So that's 6*8 bytes. I store these references in arrays, and since Java doesn't have a concept of a fixed-size array, there's 2*4 bytes of overhead just to store the size of an array that never changes. For lidar data, one million vertices is a small data product. On my poor little 4 Gigabyte laptop (a hand-me-down from my kid when she went to college), I quickly run out of memory when I try to process something larger.

I also have an issue in that there is a relatively high overhead for object construction. In an ordinary Java application, that doesn't matter. But when you're dealing with a collection of millions of objects, it starts to add up. In building my TIN, I use an "incremental" algorithm which essentially means we insert vertices into the TIN one at a time (potentially changing the layout of the TIN with each insertion). Basically, this process creates and discards about 9*N triangles by the time it is done. Since constructing and garbage collecting these triangles would be a terrible performance drag for the JVM (and I'm not just speculating here, I've measured it), I've implemented an object pool that lets me reuse triangles. Even so, the initial allocation of millions of triangles actually takes longer than the time required to run the TIN-building algorithm.

And finally, much as I love Java, and as many times as the array-bounds checking feature has saved my neck, I do wish there was a pragma or something that would let you turn it off (sort of like strictfp). Every time you access an array element, there is a conditional evaluation to make sure the array index is in bounds (Java is smart, it only needs to do one comparison, not two).

So, does your optimizer address any of these considerations? Most of them are, of course, just the way Java works, especially because of the need to support automatic garbage collection. So I imagine that they are intrinsic to the concept and not something you can optimize away. Still, it would be interesting to get your take on the issue.

[Winston Gutkowski]

Gary W. Lucas wrote:Anyway, I have a question about a problem I am working on right now. One of the tools used for processing surface elevation data is the Triangulated Irregular Network (TIN) such as the one shown at this picture of a TIN. With the advent of lidar technology (laser-based elevation surveys with a point-spacing of 1 meter per sample), it is common to process files that contain multiple millions of sample points. My current implementation can build a TIN from 1 million points in about 0.4 seconds on a typical PC...

Hope you don't mind me butting in, but I would have thought that the first place that you could "optimize", since files are involved, would be to use an SSD. In fact, I suspect that a huge amount of it could involve simply having large swap files on a "hard" device (unless Alexey's "booster" gets down to that level; but it seems unlikely) - particularly as many of the new SSDs seem to be geared for caching.

But this is entirely out of the realm of Java, and into OS-tweaking. Unix, of course, is brilliant for all this sort of stuff; not so sure about Windows.

I actually wonder if we may be getting to the point where memory compression techniques may be worth the overhead, because it does seem to me that the places where optimization is important also seem to coincide with huge volumes of data ... and Wang proved back in the late 70's that simple lossless compression wasn't such a bad idea for disk drives.

My 2¢

Winston

[Gary W. Lucas]

Winston,

You are always welcome to butt in :-) An SSD is definitely on my wish list for my next computer...

Actually, the performance stats I was referring to are based on just the time to process the data. I maintain different timers for different phases of the operation. Once I got the file-reader implemented cleanly, I figured that disk performance was a fixed cost that I couldn't address in software. Just now, I am focused on algorithmic considerations.

Gary

[Henry Wong]

Tim Cooke wrote:

Alexey Bezrodnov wrote:having a big money and asking to help you for free is a bit unfair

Apologies. I can see how it may have come across that way but it certainly wasn't my intention.

I was merely letting you know of a real world application that you could consider competing for, that could earn you some serious income.

Also, it is not a good idea to take the challenge...

Besides the fact that LMAX, like all high performance exchanges, hires the "best" (and pays for it); and those developers created a ground breaking algorithm, which has been proven in the industry... I am thinking that the two core technologies that makes is work, is the full control of memory (outside of the GC) and the fact that the algorithm is completely lock free.

Java currently provides APIs for both. Direct byte buffers to fixed memory, and the atomic classes to implement the queue in a lock free manner. IMO, there isn't anything that isn't already exposed in Java that could be used to improve this. And with the queue, there is very little actual calculations -- it is mostly about moving stuff in memory and doing so in a thread safe manner.

Henry

[Tim Cooke]

I might be wrong on this but I think Martin wrote the Queue implementation first, then the LMAX company came later. That's certainly the impression I got from talking with him anyway. I might (probably) be wrong though.

You're probably right about the rest, but it was something that came to mind as a legitimate high performance application that could be used to 'show off' the system.

[Alexey Bezrodnov]

Winston Gutkowski wrote:Even most geeks I know that love bit-and-byte-twiddling and writing drivers use C these days;

Well, they use C, it's great! But they also use assembly, aren't they? So, the Henry's statement is still too bold.

[Henry Wong]

Winston Gutkowski wrote:
Not so sure. Even most geeks I know that love bit-and-byte-twiddling and writing drivers use C these days; and I suspect that similar ops in Java are running in peko-second time nowadays, given that my 7-year old Dell can do them in sub-nanosecond (averaged over billions of ops).

Doing rough math, on a 3 GHz machine, a cycle is around 200 pico seconds -- so yes, it is sub nanoseconds, but it is only about 5 instructions in a nanosecond...

On the other hand, depending on the instructions, the processor can actually execute multiple instructions in parallel in a single cycle *and* many instructions in parallel on different cores / processors. So, it is not as bad...


Which brings me to my point ... since it is possible to run multiple instructions in the same cycle (for particular combination of instructions) on the same core, many C optimizers will actually perform code motion, in order to get those instructions to be done in parallel. In effect, the code is moved to run faster -- but not moved to affect the final result. This is something that a program can do much better than a human, especially since it may have to be done differently if some code is refactored. This is yet another reason why C seems to be preferred over assembly.

Henry

[Alexey Bezrodnov]

Gary W. Lucas wrote:Does your solution address any memory management or object-construction related issues?

In your particular case it is better just to change your algorithm first. It will get you speed increase of a few times. Use plain array and don't be bothered with objects.

And after the algorithm is good enough, then it's time for the Machine Level Java. It can increase the speed even more.

But there is a drawback, you need to spend some time improving your program. Do not expect, that it will be improved automatically, as some members here do.

[Alexey Bezrodnov]

Henry Wong wrote:IMO, there isn't anything that isn't already exposed in Java that could be used to improve this.

It was an opinion of many people before they were introduced to some low level stuff.

[Henry Wong]

Alexey Bezrodnov wrote:

Winston Gutkowski wrote:Even most geeks I know that love bit-and-byte-twiddling and writing drivers use C these days;

Well, they use C, it's great! But they also use assembly, aren't they? So, the Henry's statement is still too bold.

Full disclosure. I do mostly C programming these days -- Java is much lower in usage for me.

There is some assembly, but we are talking only about a few lines, done via the asm pragma. And quite frankly, I believe it is only to access the intel RDTSC instruction. I haven't had a need to use an actual assembler in a very long time (meaning decades).



But you are right, my statements are from personal usage -- and not from any study. So, yes, I won't make a conclusion. On the other hand, I don't think that you can make a conclusion either.

Henry

[Winston Gutkowski]

Alexey Bezrodnov wrote:But there is a drawback, you need to spend some time improving your program. Do not expect, that it will be improved automatically, as some members here do.

I think that was me; and I hate to say, but that's a bit of a "downer".

A generic Java booster? Fine. One that I have to "tweak"? Mmmm....

Winston

[Winston Gutkowski]

Gary W. Lucas wrote:Actually, the performance stats I was referring to are based on just the time to process the data. I maintain different timers for different phases of the operation. Once I got the file-reader implemented cleanly, I figured that disk performance was a fixed cost that I couldn't address in software. Just now, I am focused on algorithmic considerations.

But this is where I have to differ. As a builder of systems, I know from past experience that i/O is usually the bottleneck; so, unless the "processing time per megabyte" is NOT unduly affected by such concerns - and, since I have no knowledge of surface elevation processing, I'm not in a position to comment - it seems odd to concentrate on the algorithm.

Indeed, I suspect there may be situations where hardware RAID with nice, big-cache disks still outperforms an SSD, but I also suspect that those days are numbered.

Hardware is better than software, or anything that involves mechanics; it just IS. How soon we see it...another question. :

Winston

[Tim Cooke]

I think we have well established that the thread title "Easy to use Java performance booster" is misleading a best, and plain false at worst.

What we have here, is a thin wrapper on JNI allowing you to write, and interface to, assembler code in an "improved" manner over just using JNI directly.

The 'Java performance booster' part comes from you rewriting your Java algorithm as a more efficient assembler algorithm.

[Alexey Bezrodnov]

Tim Cooke wrote:The 'Java performance booster' part comes from you rewriting your Java algorithm as a more efficient assembler algorithm.

Well, if the performance boost of 5 times with the SAME algorithm is invisible for you, then I just can't help.

Tim Cooke wrote:What we have here, is a thin wrapper on JNI allowing you to write, and interface to, assembler code in an "improved" manner over just using JNI directly.

And again, it is recommended to try to "just use" the JNI directly and feel the difference.

A bit more about efforts. Any technology on earth requires some knowledge and efforts to be used properly. If somebody sees such situation as a hard stopper, then it is recommended to buy only ready to use solutions. But if it is about an enterprise goal, which should be met, then there is no choice, but to create something by yourself. Else you'll just have nothing to sell and, as a consequence, no money to buy a ready to use product.

And by the way, if a few hours for getting performance increase of 5 times and producing some tests and comparison benchmarks is too much for you, then again - I just can't help.

[Winston Gutkowski]

Alexey Bezrodnov wrote:Any technology on earth requires some knowledge and efforts to be used properly...

Actually, the changes to the memory model in early releases of Java resulted in dramatic improvements in speed with no effort at all on the part of programmers.

Indeed, most changes involved removing "clever" pieces of logic (eg, double-check locking) that were used before the new releases to get around the worst aspects of things like synchronization.

And this is the main problem with things like optimization in Java. You just never know when a new release is going to make all your efforts redundant; or even - as in the above example - broken.

Winston

[Alexey Bezrodnov]

Winston Gutkowski wrote:Actually, the changes to the memory model in early releases of Java resulted in dramatic improvements in speed with no effort at all on the part of programmers.

If a programmer will call an optimized native method instead of unoptimized Java method, then again, efforts to change one line of code can be called as "no efforts". And if a native method developer provides a wrapper around the native method, then no Java developer will ever need to change a line of code to use some new version of a native code or to use the library on an unsupported platform.

Of course, if we are going to discuss every letter a programmer changes, then yes, the Machine Level Java requires some efforts. But are such discussions anywhere close to be sane?

Winston Gutkowski wrote:And this is the main problem with things like optimization in Java. You just never know when a new release is going to make all your efforts redundant; or even - as in the above example - broken.

The life was never easy. But we somehow manage to be still alive. We can loose something, but we also can find something useful. So, I see it is better to just not be bothered with some changes in the future, but to be prepared and agile enough to cope with the complexity of life.

[Tim Cooke]

I do get it, really I do.

I'll openly admit that my reluctance to fully engage with this system is my lack of assembler programming skills. I have not programmed assembler since 1996, which was for a MOS 6502 processor. A relative dinosaur compared to a modern Intel chip, for which I have never written assembler.

I have no doubt that there are applications where a system such as this will be extremely useful, and will reap some great performance gains. However, for a general purpose programmer such as myself I do not see a place for it in my toolkit.

I wish you all the best with it Alexey. And please do let us know if you succeed in having your system used in any real life applications, commercial or open source. I certainly would be very interested to hear about that.

[Winston Gutkowski]

Alexey Bezrodnov wrote:So, I see it is better to just not be bothered with some changes in the future, but to be prepared and agile enough to cope with the complexity of life.

And that's where we differ. To me, the easiest way not to worry about the future is not to do things that might be affected by it. Much of good OO design is about putting off decisions that don't need to be made, and IMO, optimization is almost always one of them.

As Michael Jackson (no, not "Thriller" Jackson) said:

The First Rule of Program Optimization — Don't do it.
The Second Rule of Program Optimization (for experts only!) — Don't do it yet.

Winston

[Alexey Bezrodnov]

Tim Cooke wrote:I do get it, really I do.

It's really nice to see it

Tim Cooke wrote:I'll openly admit that my reluctance to fully engage with this system is my lack of assembler programming skills. I have not programmed assembler since 1996, which was for a MOS 6502 processor. A relative dinosaur compared to a modern Intel chip, for which I have never written assembler.

Yes, the assembly language is a new technology to a biggest part of the Java community. So, it is a very important stopper.

But if you remember the time, that was taken to implement best concurrent queue in Java, then I suppose it will be a very bold example of a time, required to make things better. Another option of downloading Intel's IA 32 architecture guide and remembering Intel's instruction set is in fact not so time consuming. And there is a third option - Java team can have just one developer with some assembly skills (in addition to Java), just in a simple correspondence to the time, required for the overall project implementation and it's optimization phase.

When a team has such option in place, then it clearly can outperform a team without such options. So I hope, after some slow and gradual acceptance of low level optimizations by the Java community, it will be considered "a bad design" if there is no bottleneck, that was optimized using Machine Level Java

[Alexey Bezrodnov]

Winston Gutkowski wrote:To me, the easiest way not to worry about the future is not to do things that might be affected by it. Much of good OO design is about putting off decisions that don't need to be made, and IMO, optimization is almost always one of them.

Your defensive approach is weak when it meets the real world. You just can't predict, where the future will get you. Of course, you can always get an umbrella and even never leave it alone, but it won't help if you have met some slop. So, it is better to have a habit of looking at the weather, instead of a habit of always having an umbrella.

[Ernest Friedman-Hill]

It seems odd to suggest that there is a large population of people who can program in assembly, but can't run an assembler or linker. I'll stick to traditional JNI, thanks. Far more flexible and IMO no more difficult to use.

Years ago I wrote a Javadoc doclet that let you put JNI implementations in the doc comments of native method declarations. By using preprocessor guards, you could include implementations for multiple platforms, all in the one Java file. The doclet would generate compilable C++ source, easy to include in your build process. You could have used inline assembly with it if you wanted.

[Steve Fahlbusch]

Greetings,

Your earlier posts were odd, but these are simply disperbing, but if you are really thinking that your effort is useful then write a paper and submit to either the ACM or the IEEE. Then and only then tell use why we should think about this.

-steve

[Winston Gutkowski]

Alexey Bezrodnov wrote:Your defensive approach is weak when it meets the real world. You just can't predict, where the future will get you.

I'm not quite sure what you're referring to as "defensive" - my attitude to optimization in general, or to your product. If it's the first, then all I can say is that it's one shared by many, including some of the best brains in our business; and most of the axioms are taught in OO programming 101.

Avoidance is a perfectly reasonable strategy for success, whether in programming, politics, game theory or military tactics; and the first quote I read about it was at the top of the very first chapter of the first book I read about Object Orientation:

  When it is not necessary to make a decision, it is necessary NOT to make a decision.
  − Lucius Cary, 1st Viscount Falkland, 1643.

and it's why we are taught early on to prefer interfaces to classes, and design to implementation.

Your "booster" - however good - and optimization in general, requires a commitment to an implementation. Now I understand that in certain, cases, there may be an overriding need for efficiency (speed not necessarily being the only metric); but far from being the "real world", I suspect that such situations are actually very rare indeed - at least as set against the vast majority of "apps" programming - so you'll have to understand my scepticism at some of your claims.

And better you hear it first from people like me, who really do wish you luck, than from the "real world".

Winston

[Alexey Bezrodnov]

Ernest Friedman-Hill wrote:It seems odd to suggest that there is a large population of people who can program in assembly

It wasn't my suggestion. Some people can, other part can learn it. It's not too complex, even much less complex, than standard J2SE API. That's why here is a way to go without text based assembler or any kind of a linker.

And even having the skill of using standard assembly tools (like the linker and other stuff), you still have to do some set of tedious operations manually. So, why we need to do that boring stuff? My variant just strips it down.

Ernest Friedman-Hill wrote:Years ago I wrote a Javadoc doclet that let you put JNI implementations in the doc comments of native method declarations. By using preprocessor guards, you could include implementations for multiple platforms, all in the one Java file. The doclet would generate compilable C++ source, easy to include in your build process. You could have used inline assembly with it if you wanted.

Your variant requires a developer to write C code using plain text editor (no IDE help), next the developer runs some doclet applet, next he gets the same C code, but in a separate file, next the developer is expected to repeat all the steps, that are required from a C developer, who just doesn't use the doclet approach. It seems there is a lot of redundancy.

In contrast, the Machine Level Java allows a Java developer, while stying within a preferred Java environment, to write only Java code, split it into logically separate parts of low and high level calls, use IDE help extensively, never remembering about any linker or anything from outside the Java environment, no redundancy, no manual and tedious operations, just some productive code and nothing else.

It's like writing Java program using plain text editor instead of an IDE. But with C code also involved in your case.

And by the way, C code is not a performance overkill, so the assembly is a must for a really good optimization. Then why a developer should think about C and all the related build process, while in fact he needs just a piece of assembly code? And the Machine Level Java just allows it - write Java program and, if required, write another small piece in Java, but now for the low level. All in the same place and without environment switch.

[Alexey Bezrodnov]

Winston Gutkowski wrote:I'm not quite sure what you're referring to as "defensive"

You are going to protect (defend) everything far before a battle. While my approach is about looking at the enemy movements and reacting accordingly.

Winston Gutkowski wrote:Avoidance is a perfectly reasonable strategy for success, whether in programming, politics, game theory or military tactics; and the first quote I read about it was at the top of the very first chapter of the first book I read about Object Orientation:

  When it is not necessary to make a decision, it is necessary NOT to make a decision. − Lucius Cary, 1st Viscount Falkland, 1643.

Ok, but if you already have met the unavoidable? And you are not prepared. Or you can predict the future and is prepared to every possible change?

Winston Gutkowski wrote:Your "booster" - however good - and optimization in general, requires a commitment to an implementation.

Of course, any battle requires a commitment in form of actual fighting. We can be prepared as never before, but still will lose a battle because we just unable to predict the future. Your position is about preparations only, but my is about the inevitable fight.

Winston Gutkowski wrote:Now I understand that in certain, cases, there may be an overriding need for efficiency (speed not necessarily being the only metric); but far from being the "real world", I suspect that such situations are actually very rare indeed - at least as set against the vast majority of "apps" programming - so you'll have to understand my scepticism at some of your claims.

I have already agreed, that a set of suitable situations is about as small as one to tenths. But even 5% is a great deal. I suppose that standard Java API is used no more than at a level of 10% in most projects, but the 90% of it still exists. Why it was created for? Just to fulfill the need of a DIFFERENT projects. So it is the Machine Level Java, which fulfills the need for high end optimization. May be it's niche is about a few percents, but there it shines as nobody else.

[Winston Gutkowski]

Alexey Bezrodnov wrote:You are going to protect (defend) everything far before a battle. While my approach is about looking at the enemy movements and reacting accordingly.

No. Your approach is to say: "Use MY product, and let it make the decisions for you". And it sounds rather "Gates-ish" to me.

MY approach is to say: don't make that decision - especially if you don't need to.

Ok, but if you already have met the unavoidable? And you are not prepared.

Then you've done your job badly.

Or you can predict the future and is prepared to every possible change?

No. And that's not what avoidance strategy is about.

The rest seems to boil down to an analysis of how many people (or what percentage) this product will be useful to. If I'm working at CERN, for software on the Large Hadron Collider, I can quite understand that speed (or throughput, which I'm not sure your solution actually tackles in total) is going to be paramount. I'm just not convinced that even 1% - let alone "tenths" - of the people who use Java (15% at the last Tiobe count) are going to find much mileage in it.

That said, it may be a very powerful tool in that niche market; but I think that your millions are likely to be made THERE (or - more likely - in consultancy for same).

As my brother (an engineering student) is fond of telling me: power != torque.

Winston

[Henry Wong]

Winston Gutkowski wrote:

Alexey Bezrodnov wrote:You are going to protect (defend) everything far before a battle. While my approach is about looking at the enemy movements and reacting accordingly.

No. Your approach is to say: "Use MY product, and let it make the decisions for you". And it sounds rather "Gates-ish" to me.

MY approach is to say: don't make that decision - especially if you don't need to.

Agreed. Having had many technologist "sell" me technology that is the "next best thing since sliced bread", I actually think of it this way... Why do I need to be proactive about it? If the product is as good as you say, it will catch on, and I will likely be using it myself (once it is no longer bleeding edge). If not, well, then no worries.

In this case, JNI is an option to this. It is not bleeding edge (proven). It is supported. It works fine. And quite frankly, I rarely need it as it is. Don't I have lots of other products / technologies that takes precedence? Products that claim to be solving a pain that I am having?


Anyway, like I said, it is interesting. Let's see if it catches on. Feel free to bump this topic when / if it does !!

Henry

[Alexey Bezrodnov]

Winston Gutkowski wrote:No. Your approach is to say: "Use MY product, and let it make the decisions for you". And it sounds rather "Gates-ish" to me.

My approach is about to show a new tool, that should be in your toolbox and can be used efficiently when the battle begins. It just adds more agility to your army. And while you do not need it, just leave it in a toolbox.

Winston Gutkowski wrote:The rest seems to boil down to an analysis of how many people (or what percentage) this product will be useful to

But don't forget that if personally you do not need the tool, it just doesn't mean the tool should be dismissed. Even just 1% of developers of the world is a very big number.

[Winston Gutkowski]

Alexey Bezrodnov wrote:My approach is about to show a new tool [...] And while you do not need it, just leave it in a toolbox.

And that's perfectly reasonable. My worry is that the decision to use it is not without cost - and therefore should be taken cautiously - and should probably include not only a plan for adoption, but one for removal should the tool ever be improved on (eg, perhaps by a new version of RMI?).

But don't forget that if personally you do not need the tool, it just doesn't mean the tool should be dismissed.

I hope I haven't given that impression. As with any discussion of this kind, what you're getting is my opinion based on my experience; and I think I've already conceded that in the right environment, it could be very useful. I'm just not sure how big that environment is.

Winston

[Alexey Bezrodnov]

Winston Gutkowski wrote:My worry is that the decision to use it is not without cost - and therefore should be taken cautiously - and should probably include not only a plan for adoption, but one for removal should the tool ever be improved on (eg, perhaps by a new version of RMI?).

We have the stable RMI API for more than 15 years, so I suppose new RMI version is not a big deal if we consider the attention Java owners pay to the compatibility issue.

And one more important thing to be noticed - the Machine Level Java has very simple implementation. It means that any efforts, that can be ever needed to improve something in it, hardly can be comparable with typical optimization costs. Just one this point can show you that big compatibility/improvement worries in any way is not a stopper.

But if you mean that every technology should be used with some thinking applied, then of course, they should. But we just can't stop using Java because of some future incompatibility or whatever similar issues. It is important to see the difference between some worries and the real life - in real life we just live and most often do not worry about many possible problems. So, I hope if a developer has a bit of common sense, then there's just no viable problem in sight.

Winston Gutkowski wrote:I'm just not sure how big that environment is.

Yes, and we can discuss it for a very long time

I prefer not to be so cautious about new technology usage. If my evaluation shows me more benefits than a possible value of problems, then I just use a technology. And I suppose most developers can assess their benefits also, so they can decide about the need for the Machine Level Java and they can easily determine the size of "that environment" in the end of an adoption process.

[Carey Brown]

Alexey Bezrodnov wrote:I prefer not to be so cautious about new technology usage. If my evaluation shows me more benefits than a possible value of problems, then I just use a technology. And I suppose most developers can assess their benefits also, so they can decide about the need for the Machine Level Java and they can easily determine the size of "that environment" in the end of an adoption process.

I wouldn't want to be the one that has to maintain your project. Job security for you I suppose.

[Paul Clapham]

I wouldn't necessarily agree with you, Carey. There are different degrees of risk associated with different projects. If I want to try something new in my personal bird taxonomy application, I can just try it. It's okay if I have to spend a few hours fixing it up. However if I want to try something new in my company's online customer care website, I'm going to do a lot more testing in my test environments before I go live with the changes.

[Alexey Bezrodnov]

A bit different view at the proposed technology has came to my mind. It's an easy way a Java programmer can extend his computer science knowledge base. Without the need for learning many low level tools and standards, now it is possible to write and test/use small assembly programs while staying within Java environment.

Are the computer science courses teach students high level things first? Then having Java language concepts understood, it is possible to start learning low level immediately. No more alphabet soup of MASM, FASM, TASM or any other assembly translator, no more linkers, no more annoying syntax differences even for the same processor architecture, no more Linux and it's command line mastering, just so familiar Windows and Java, and nothing more. It seems just as simple and as efficient as touch based interface of tablet and smart-phone devices vs old style 12-15 buttons equipped phones.

[Winston Gutkowski]

Alexey Bezrodnov wrote:It seems just as simple and as efficient as touch based interface of tablet and smart-phone devices vs old style 12-15 buttons equipped phones.

Aw, I liked the old phones. And I have to admit finding myself bewildered in this new world of "smart" technology. Give me my damn number pad back!!

However, I completely agree with your new "definition", and I'd go further - the simpler you can make it, the more likely people are to use it.

Good luck.

Winston

[Alexey Bezrodnov]

Winston Gutkowski wrote:Give me my damn number pad back!!

I suppose you are going to be prepared for the times when museums will pay a lot of money for the "damn number pad"

Winston Gutkowski wrote:However, I completely agree with your new "definition", and I'd go further - the simpler you can make it, the more likely people are to use it.

May be it shouldn't be called a "definition". It's just another possible usage area for the technology. And yes, I hope it's really simple. And may be some time later it will be even simpler.