hex dump?

[John B. Matthews]

<http://c2.com/cgi/wiki?HexDumpInManyProgrammingLanguages>

Interesting, but:

private String bytesText(int perLine) {
String result = "";
for(int i = 0; i < bytes.length; i++) {
String hex = Integer.toHexString(bytes);
result += leftPadded(bytes < 0 ? "FF" : hex, 2) + " ";
}
while (perLine-- > bytes.length) result += " ";
return result;
}

Ouch, lot's of string concatenation. What about using a
StringBuilder? Constructs like this make me doubt the usefulness of
the whole page.

Eeek! I was looking at the last entry, class HexDump, which is admirably
shorter and uses StringBuilder; but your point is well taken.

 

[Andreas Leitgeb]

Ian Smith, 11.05.2009 10:34:
I would expect the compiler to see and optimize that automatically.
Thomas

The Java compiler doesn't optimize (well, not any more since
quite a couple of years).
I casually look at the bytecode for my own classes, and it's
"frustrating" (tongue in cheek) to see, which seemingly trivial
patterns of statically determinable optimisation are not applied
at producing bytecode.

The first principle for those interested in optimisations
is: Faith Namely faith, that Hotspot gets to recognize
all these patterns later in the bytecode, and does a good job
at producing native code (in memory) from this bytecode.

For the more doubting ones, there is a fallback strategy:
Measure performance! (With profilers! So you see, whether any
particular optimization of a certain piece of code is even
worth the trouble)
Then, eventually use available bytecode dis- and -assemblers to
do some hand optimisations (or use some professional bytecode-
optimizers that do more than just rename methods to cryptic
names) and re-measure performance after those.

I for myself am too lazy for the fallback strategy, so I just stick
to first one: Faith. Although, I'm not very firm in that one.

PS: maybe you thought of Hotspot, anyway, when mentioning the
compiler for optimisations.

 

[SpreadTooThin]

      String hexString = Integer.toHexString(bytes);
      System.out.print((hexString.length() < 2 ? "0" : "") + hexString
+ " ");

I didn't look at the rest of the code, but Java supports a printf() call

   System.out.printf( "%02X ", (int)byte[i++] );

might trim three lines into one for you.

Thank you. Very nice. Exactly What I needed.

 

[SpreadTooThin]

I would use:

    for( int i = 0, l = s.length(); i < l; i++ ) {

similar argument to the stringbuilder [sic] one

'l' is a terrible choice for a variable name.  I thought you were comparing
'i' to '1'.

The value of this micro-optimization is dubious, but I admit to using it myself.

I am not familiar with 'stringbuilder'.  Custom class?

Do you know where variable names like i, j, k and l came from?
Fortran! Variables that started with those letters were automatically
treated as integers...

 

[SpreadTooThin]

Pardon this ignorant c/c++ programmer trying to do something in
Java...

char buffer[102];
int i;
for (i=0; i < 102; ++i)
   printf("%02X ", buffer);

cmon.. how hard can it be do something like this in java from a
String?

I don't know why they are giving you a bad time but you pretty much have
the answer.  It looks like you are receiving a UDP datagram.  That will
be in a byte[] buffer and you print it out just like you expect.  You
don't need to do any conversions, just print out the byte data with printf.

Wow!!! What are you psychic? Holly crap! How did you know?

public class test {
     public static void main(String[] args) {
         byte[] buf = { (byte)0xff, 0x15, 0x2a, (byte)0x8f, 0x00 };

         for (int i=0; i<buf.length; i++)
             System.out.printf("%02X ",buf);
     }

}

 

[Mark Space]

Do you know where variable names like i, j, k and l came from?
Fortran! Variables that started with those letters were automatically
treated as integers...

We know.

 

[Lew]

Do you know where variable names like i, j, k and l came from?

As a matter of fact, I do.

Fortran [sic]!  Variables that started with those letters were automatically
treated as integers...

Yes, I began my programming career with FORTRAN and used it for years,
but that has absolutely nothing to do with Java, which does not
automatically type variables, nor with my point. My point was that
the single-letter name 'l' is too easily confused with '1', at least
for the purposes of Usenet posts. It is more courteous and effective
to use names, indentation, etc., that promote understanding.

 

[Arne Vajhøj]

As Joshua wrote: a char can be converted to an int, so try

check the Integer class.

Pardon this ignorant c/c++ programmer trying to do something in
Java...

char buffer[102];
int i;
for (i=0; i < 102; ++i)
printf("%02X ", buffer);

cmon.. how hard can it be do something like this in java from a
String?

Not very hard.

Joshua gave you all the clues.

Arne

 

[Arne Vajhøj]

char buffer[102];
int i;
for (i=0; i < 102; ++i)
printf("%02X ", buffer);

cmon.. how hard can it be do something like this in java from a
String?

String s = ....
for( int i = 0; i < s.length(); i++ ) {
System.out.printf( "%02X ", (int)s.charAt( i ) );
}

But not really the most Java'ish way.

Arne

PS: charAt return 16 bit - something is necessary to
convert from String to byte[] if unicode values > 255
is to be supported.

 

[Arne Vajhøj]

The Java compiler doesn't optimize (well, not any more since
quite a couple of years).
I casually look at the bytecode for my own classes, and it's
"frustrating" (tongue in cheek) to see, which seemingly trivial
patterns of statically determinable optimisation are not applied
at producing bytecode.

The first principle for those interested in optimisations
is: Faith Namely faith, that Hotspot gets to recognize
all these patterns later in the bytecode, and does a good job
at producing native code (in memory) from this bytecode.

For the more doubting ones, there is a fallback strategy:
Measure performance! (With profilers! So you see, whether any
particular optimization of a certain piece of code is even
worth the trouble)
Then, eventually use available bytecode dis- and -assemblers to
do some hand optimisations (or use some professional bytecode-
optimizers that do more than just rename methods to cryptic
names) and re-measure performance after those.

I for myself am too lazy for the fallback strategy, so I just stick
to first one: Faith. Although, I'm not very firm in that one.

It is not that much different with modern C compilers.

AOT or JIT - it is still best to write clear code and let
the compiler do what it is suppose to do.

Arne

 

[Arne Vajhøj]

I would use:
for( int i = 0, l = s.length(); i < l; i++ ) {
similar argument to the stringbuilder [sic] one

'l' is a terrible choice for a variable name. I thought you were comparing
'i' to '1'.

The value of this micro-optimization is dubious, but I admit to using it myself.

I am not familiar with 'stringbuilder'. Custom class?

Do you know where variable names like i, j, k and l came from?
Fortran! Variables that started with those letters were automatically
treated as integers...

We are some that know that.

But old Fortran is usually is all uppercase and L is not a problem
like l.

Arne

 

[Andreas Leitgeb]

It is not that much different with modern C compilers.
AOT or JIT - it is still best to write clear code and let
the compiler do what it is suppose to do.

That's what I'd like to believe. Still one should use explicit
StringBuilder when building up a String piecewise throughout
a loop, rather than just do s+=...;

I nitpicked on the original claim that the compiler would
optimize away some tidbit. In Java the compiler is usually
"javac" (leaving aside jikes, gcj and others) and javac
doesn't do any optimization at all. All the optimization
in Java happens during runtime and the results are not
preserved across separate runs of the JVM (and its JIT).
(In some situations this may even be an advantage, in all
others it's not)

 

[Andreas Leitgeb]

As far as I can see, no information is lost in the process,...

It may be true, but that isn't evident to me.

-- new JVM versions may enhance performance, even for compiled
applications for which the source code is not available;

I anticipated this particular argument.
If it were the only one, (which it most fortunately was *not*) it
would be quite a bad tradeoff: redo the same optimizations on each
class on each jvm run, just so in case I want to run the same compiled
code in N years the optimizer may have improved essentially till
then...

The other arguments were better, though.

 

[Nigel Wade]

SpreadTooThin wrote:

We are some that know that.

But old Fortran is usually is all uppercase and L is not a problem
like l.

I and 1 could be a problem, especially on teletypes with worn out ribbons, and
card-punches (which IME never printed the text very clearly).

 

[Mark Space]

But not really the most Java'ish way.

He asked for a string, I gave him a string. The OP has a habit of not
identifying the type objects he posts. I make as few assumptions as
possible about the return type of "receivePacket.getData()" -- none at all.

I think he was mainly interested in the existence of a printf() call in
Java anyway.

PS: charAt return 16 bit - something is necessary to
convert from String to byte[] if unicode values > 255
is to be supported.

I probably should have and'd the return type with 0xFFFF instead of
casting to int. But I was going fast. Oh well, I learn stuff here too.

 

[Andreas Leitgeb]

Bad trade-off ? It depends. CPU time is cheap -- much cheaper than
developer time, especially when both the developer and the person paying
for it are me. The trade-off here is accepting to devote a bit more
CPU cycles to application warm-up, to avoid allocating developer cycles
to the recompiling and redeployement of code when the target architecture
changes.
The trade-off would be worse if I were to start many times the same Java
application, in quick succession, e.g. as part of a shell script. But
Java (as implemented by Sun) is not well-suited for that anyway (and JIT
compilation is _not_ the biggest cost in Java application startup).

It's all moot, anyway. Java apps just do have that relatively high
startup cost, so spending those additional cycles for ever-the-same
calculations really isn't all that sticking out. Probably, handling
pre-optimizations wouldn't be for free, either.

eot.

 

[Lew]

It's all moot, anyway.   Java apps just do have that relatively high
startup cost, so spending those additional cycles for ever-the-same
calculations really isn't all that sticking out. Probably, handling
pre-optimizations wouldn't be for free, either.

Plus HotSpot optimizations are dynamic. They get undone and redone as
the engine deems fit, i.e., as runtime considerations mutate.

Supposedly this allows HotSpot to do optimizations not even possible
with static (compile-time) optimization, such as guaranteeing that an
alias pointer is not used at a given time during some performance-
critical operation, thus allowing it to substitute a register access
instead of an interpreted lookup, or inlining a get method and
avoiding an instance creation because HotSpot can tell that the value
is not changed during this particular execution, or that some
operation's lock doesn't escape a critical section so that it can be
elided.

I say "supposedly" only because I've seen anecdotal evidence that this
magic doesn't occur as often or as aggressively as one might wish.
Also, JVMs vary with respect to their optimization capabilities.

 

[Arne Vajhøj]

He asked for a string, I gave him a string. The OP has a habit of not
identifying the type objects he posts. I make as few assumptions as
possible about the return type of "receivePacket.getData()" -- none at all.

I think he was mainly interested in the existence of a printf() call in
Java anyway.

Yes. But I still consider prinbtf a C'ism that has sneaked into Java
late in the game.

PS: charAt return 16 bit - something is necessary to
convert from String to byte[] if unicode values > 255
is to be supported.

I probably should have and'd the return type with 0xFFFF instead of
casting to int. But I was going fast. Oh well, I learn stuff here too.

I believe char's are unsigned so that is not necessary. But %02X
is a bit tight !

Arne

 

[Arne Vajhøj]

That's what I'd like to believe. Still one should use explicit
StringBuilder when building up a String piecewise throughout
a loop, rather than just do s+=...;
Yep.

I nitpicked on the original claim that the compiler would
optimize away some tidbit. In Java the compiler is usually
"javac" (leaving aside jikes, gcj and others) and javac
doesn't do any optimization at all. All the optimization
in Java happens during runtime and the results are not
preserved across separate runs of the JVM (and its JIT).

Yep.

Arne

 

[Arne Vajhøj]

I and 1 could be a problem, especially on teletypes with worn out ribbons, and
card-punches (which IME never printed the text very clearly).

I and 1 are not quite as close as l and 1, but it could happen as well.

Arne