Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8595

Re: DataInputStream

Show all headers | View raw

Robert Klemme wrote:
> Lew wrote:
>> Robert Klemme wrote:
>>> bob wrote:
>>>> The issue is that it's too slow.
>>
>> How slow is that, and how fast should it be?
>>
>> How much faster could it be, and what makes you think that's possible?
>>
>>> Ah, now we're getting closer to the point.  I'd first test whether the
>>> slowness is caused by the underlying stream or the reading procedure.
>>> If it's the stream (e.g. because you read unbuffered from a socket)
>>> then you might want to add buffering or you need a faster NIC.  If
>>> it's in the reading then look at Mark's suggestion.
>>
>> The OS could also be a factor.  So could other loads on the system, particularly the I/O subsystem.  Given that we don't know what speed is "too slow" and what speed is acceptable, nor the system configuration, nor the load profile, nor anything else, there's nothing we can say to affect the "too slow" evaluation.
> 
> Absolutely.  I just wanted to partition the problem space in "float
> reading and parsing" and "general IO" because that information is
> needed to decide whether the approach to reading floats is wrong
> because it's too slow.  OS then falls into "general IO".

If "general IO" takes 100 ms and the specifics of the float conversion take 100 μs (to pick numbers out of my, er, hat), then time spent on the latter should wait until the former is properly handled.  You might shave a whopping 50 μs out of your 100100 μs total overhad if you double the speed of the wrong side.  You'll still have roughly 99.95% of your overhead.

It's not enough to solve the problem; you have to solve the right problem.

That said, the partition is useful.  It helps you organize your search for the high-value targets.

>>>> What I'm hoping for is something like this:
>>
>>>>                         byte[] b = new byte[numfloats*4];
>>
>> Did you indent enough there?
>>
>>>>                         dis.read(b, 0, numfloats*4);
>>>>                         float[] f = (float[]) b;
>>>>                         return f;
>>
>>>> I don't know why, but it won't let me do the cast.  Any ideas?
>>
>>> See Patricia's reply.  Java works fundamentally different from C or C+
>>> +.  For example, there are no pointers into memory.  I seriously
>>
>> Well, there are, actually.
> 
> I can see why you say that (because eventually every reference of any
> kind points to a place in memory).  But for the sake of this
> discussion and the general concept of Java I'd rather stick with "no
> pointers into memory in Java" because that makes it crystal clear that
> there is not that free access to memory cells as in C/C++.  Actually

I'd rather stick with the truth to make it crystal clear what's true.

Imprecise analysis leads to incorrect solutions.

The truth is that Java has pointers.  The nuance is that these pointers do not behave like those in C, but then C didn't invent pointers to begin with.

> objects can even move in memory so an unchanged reference can point to
> different locations throughout its lifetime, while an unchanged C
> pointer always references the same memory addresses.

So say that, rather than the imprecise and incorrect canard that "Java doesn't have pointers".

>>  In the case of the OP's code, they're 'b' and 'f'.  However, the pointers in Java are rigidly typed, unlike those in C, so you cannot cast a pointer to 'byte[]' into a pointer to 'float[]'.
> 
> That's why I prefer the term "object reference" which is also what the
> JLS uses (even though there are some occurrences of "pointer" and we
> have "NullPointerException").

The JLS flat out defines the terms "pointer" and "reference" as equivalent.

The word "object" in "object reference" is redundant, and not correct in the case when the reference points (!) to 'null'.

But do feel free to use the term "reference", which in Java's nomenclature is exactly equivalent to "pointer".

The key feature of a pointer is that it points to something.  The ability to alias pointer types (e.g., 'byte' array to 'float' array), perform pointer arithmetic or to point to invalid memory are not essential to the definition of "pointer".

Let's not lie to people in an attempt to dumb the information down.  Let's instead tell the truth and require programmers to be smart.  There's far too much dumb programming in the wild already.

-- 
Lew

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

DataInputStream bob <bob@coolgroups.com> - 2011-10-04 22:34 -0700
  Re: DataInputStream Robert Klemme <shortcutter@googlemail.com> - 2011-10-05 08:02 +0200
    Re: DataInputStream bob <bob@coolgroups.com> - 2011-10-04 23:17 -0700
      Re: DataInputStream Robert Klemme <shortcutter@googlemail.com> - 2011-10-05 00:07 -0700
        Re: DataInputStream bob <bob@coolgroups.com> - 2011-10-05 07:17 -0700
          Re: DataInputStream markspace <-@.> - 2011-10-05 08:27 -0700
          Re: DataInputStream Patricia Shanahan <pats@acm.org> - 2011-10-05 08:38 -0700
          Re: DataInputStream Robert Klemme <shortcutter@googlemail.com> - 2011-10-05 08:58 -0700
            Re: DataInputStream Lew <lewbloch@gmail.com> - 2011-10-05 14:52 -0700
              Re: DataInputStream Patricia Shanahan <pats@acm.org> - 2011-10-05 15:15 -0700
              Re: DataInputStream Robert Klemme <shortcutter@googlemail.com> - 2011-10-06 00:11 -0700
                Re: DataInputStream Lew <lewbloch@gmail.com> - 2011-10-06 07:08 -0700
                Re: DataInputStream Patricia Shanahan <pats@acm.org> - 2011-10-06 07:49 -0700
          Re: DataInputStream Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-05 21:16 -0400
      Re: DataInputStream Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-10-05 08:12 +0000
        Re: DataInputStream bob <bob@coolgroups.com> - 2011-10-05 07:12 -0700
  Re: DataInputStream Roedy Green <see_website@mindprod.com.invalid> - 2011-10-06 02:48 -0700

csiph-web