A moderate view. - Page 15

DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 15 of 15 FirstFirst ... 5131415
Results 211 to 215 of 215

Thread: A moderate view.

  1. #211
    Kunle Odutola Guest

    Re: A moderate view.

    "Bill McCarthy" <bill_mcc@iprimus.com.au> wrote in message

    > You still have to do *extra* comparisons, and have *extra* error handling

    > performance cost !!! It may be just a few key parameters that you use, in

    > case your arguement about 80% of the time is clearly false. If you meant
    > constants, well derrr, but you still have to do lots of tests !!

    Most programs need this sort of limits-checking in any case. If I asked you,
    I bet you could tell me the limits on the numbers of fields, tables,
    filesize, indexes etc that Access and SQL Server impose. This isn't *extra*
    overhead really.

    > Exception handling has a real cost !! It is worse if there are exceptions,

    > would really kill your app on a 32 bit system. But even if an exception

    is not
    > generated there is still a cost in having exception handling. If there

    > then overflow checking for integers would have no cost so there would be

    no perf
    > difference between Int32 and Int64.

    The real cost is incurred when you hit the exceptions is the point I am

    > > Well if it is a true 3D image then presumably every pixel is now an

    > > in some 3D space? ;-)

    > Don't you even know what a pixel is ??? Hint:
    > http://www.dictionary.com/cgi-bin/dict.pl?term=pixel

    Bill, do try to stay away from insults. We've been there before.

    Anyways, look at what I found:

    I have to say that perhaps the emergence of true 3D displays will bring a
    new term as well but 3D pixel (as in picture element) works for me.

    > ROFLMAO !!! You really do have no idea do you ???
    > Here's a clue for you Kunle, if you are searching/iterating over 2 billion
    > items, and you are trying to optimise for 64 bit, you don't searh each

    > byte by byte and definetly not bit by bit. Do you know why that might be

    > ???

    I didn't say you did. How you do it, is up to you.
    Having worked on signature file and bitmap indexing engines in the past, I
    think I just might ;-)

    > I'll let you think about it some. But you do realise that that is so
    > inefficient it is laughable.

    Sometimes, such inefficiencies are tolerable given appropriate hardware for
    the problem in hand. It's always a trade-off...

    > > When I said CAD you may have equated that to off-the-shelf packages that

    > > can pick up. Not yet but you can try looking at these and figuring out

    > > sysytems they use:
    > >

    > > .htm

    > Get a clue Kunle.

    You really should learn how not to insult the people you communicate with
    Bill. Reminding you not to insult is getting repetitive.

    > Do you really think .NET is designed for that kind of
    > applications. They would laugh at you and show you the door. You are

    > about raw computing power there and very complex fluid systems modelling,
    > similar to weather forcasting machines.

    Yes. Claims made for JIT-ted code on such platforms are within whiskers (and
    sometimes ahead) of native code performance for raw computation.
    [ And I would like to hear from *anyone* in MSFT who disagrees. ]

    > I don't know what university you studied engineering modelling at, but if

    > did,

    Ouch!. Need reminding about insults again?

    > you would or should know that for complexsystems such as that you don't
    > iterate through each item when searching. Geezz... i know we spent ages

    > parallel computing with algorithms designed purely to find local maxima

    > minima etc, and the difference between a good and a bad algorithm could be
    > substantial, and iteration was just laughable.

    Even a simple binary search will help. Of course, there are much more
    complex structures that can cut down the times.

    > or to quote you from that page you referenced:
    > "Although this grows only quadratically with the number of parts (not the
    > exponential growth we are so concerned with elsewhere) just the sheer

    number of
    > parts makes brute force enumeration unattractive."

    Glad you read it.

    > > BTW, clearing banks, settlement systems etc deal with such numbers
    > > routinely. I am aware of other examples in doc indexing and retrieval,
    > > computational modelling, settlements & clearing, electronics parts

    > > etc

    > sure Kunle, I bet that all iterate through each cent of each transaction


    It would be silly not to. Every cent counts, as the saying goes...

    I noticed a subtle change from
    "Yeah right!, show me an example"
    to this new
    "OK, but iteration, come on get a clue man"

    > Come back when you want to talk about the real world Kunle, and the so

    > 80% of cases you originally claimed. Utter nonsense.

    The real world now is it?. Previously it wasn't possible. But now it's not
    the real world.


  2. #212
    Kunle Odutola Guest

    Re: A moderate view.

    "Bill McCarthy" <bill_mcc@iprimus.com.au> wrote in message

    > > Dunno. You said it. What does it mean?

    > Well Kunle ,all you had to do was search/read the docs.

    There you go on that slippery slope again. You have no way of knowing if I
    read the docs.
    Incidentally MS's definition translates to "lowest common denominator"
    integer size to me.

    > An integer when used
    > purely as a valuetype, which was what I was talking about and waht we are

    > to be discussing (just in case you forgot) is only truely platform

    portable as
    > Int32 in .NET. Simple as that.
    > The intrinsic type is 32 bit. A constant for example coming fro ma natural
    > integer woudl have to cast to Int32 to be platform portable.

    Like I said, a lowest common denominator.

    > > Hmm. So the hooplah about 32-bit optimizations for 64-bit cpus that

    > > AMD and others are making is just FUD?

    > No it's not. It jsut isn't applicable to 64 bit applications which is what

    > will be on a 64 bit platform. The only thing that is FUD is you making

    such a
    > hooplah about what is irrelevant.

    How can it be given the platform portability requirements to use 32-bits.
    This is hardcoded in many ways into .NET at present - array/vector indices
    for instance.

    > The CLR does support 64-bits natively where it is important for it to do

    > The main thing is not to unnecessarily delay .NET shipping and to ensure

    > .NET has good performance on *both* 32 bit systems and 64 bit systems.

    There is a difference between supporting 64-bits datatype and supporting
    full 64-bit processing and addressing. We differ on the "where it is
    important for it to do so" bit.
    I agree about shipping deadlines hence my view that it might be changed
    if/when 64-bits enters the mainstream (and MS has had a bit more expereince
    with 64-bits).

    > specifically Kunle, because of the excessive error handling, casting,

    > checking needed. That's why Kunle.

    Why would you need to cast, bounds check etc a 32-bit value (native int) on
    a 32-bit system ?
    What excessive error handling?

    > > You _really_ mean 32-bits is the "lowest common denominator" size. I

    > > argue with that.

    > Then why are you trying to ???

    You think I am arguing against 32-bits as the lowest common denominator?.
    I am arguing in favour of being able to ignore lowest common denominators
    (whatever they are) and exploit the underlying system better.

    > wrong. Waht is *optimal* depends on a lot of issues. Storage size also

    > on performance.

    We were discussing performance. And the optimal size is different for
    different architectures/systems.

    > > No it can't. You can end up with weird errors/exceptions otherwise. You

    > > however make the choice to tunrn off overflow checking it that suits

    > > application. Regardless of platform native size.

    > nonsense. It can. If you assign the range as Int32's then there is no need

    > the compiler to do any overflow checking in that case.

    What happens if my loop needs to iterate 2,147,483,647 + 10 times?

    > What ? You missed the whole point. The point is the compiler cannot

    > that the range is valid. So the same optimisation cannot be performed at
    > compile time.

    Yes it *can*. The JIT compiler I mean. That's partly why IL keeps all that
    info around - the beauty of metadata ;-)

    > > As for Integer and APIs, you wouldn't use a variable datatype in such

    > > declarations. You will use intXX. Like I said there are different uses

    > > variable-size datatypes and fixed type datatypes and half the problem is
    > > knowing when to use either.
    > >

    > Right. Th point is though Kunle, there really isn't a need to use SysInt

    > Vb.NET. Yo umay need to use IntPtr occassionally, but not SysInt, and

    > not 80% of the time liek you claimed. Yo ustill have yet to provide any

    > of code where SysInt would provide more efficient code. Not one !!!!

    Bill the real point is that you and I have different opinions on the utility
    of a native int dataype. I have put forward my views and so have you.


  3. #213
    Kunle Odutola Guest

    Re: A moderate view.

    "Bill McCarthy" <bill_mcc@iprimus.com.au> wrote in message

    > Nonsense. The issue with 16 bit systems on 32 bit systems was address

    > The same will apply to 32 bit systems running on 64 bit systems, although

    > thunking is more sophisticated, as there is more space for it to be <g>.

    OK. I'm nuts but please comment on this:

    > But with .NET, this is not an issue. A .NET app, whether you use Int32 or

    > will still be a 64 bit application on Windows64. Simple as that. No

    > involved.

    I didn't say it wasn't a 64-bit app so this statement is irrelevant. But
    Win64 in truth is a 32-bit OS, modified to use a 64-bit address space,
    running natively as 64-bit code on 64-bit hardware. This isn't a put down
    since the same if true for most of it's competition currently. That is
    exactly what it needs to be today. There is a huge existing investment in
    32-bit apps and systems that many people would need/love to bring forward to
    the 64-bit party. Win64 will evolve and as it does, hopefully so will .NET.

    > This kind of fear you are trying to spread, the uncertainty you are trying

    > propogate, and the doubts you are trying to nurture in peoples minds is

    *FUD* by
    > definition !!! It is irrelevant to the issue, and it is nothign but a

    > rather than looking at the real issues. The facts are Kunle, VB.NET will

    be 64
    > bit application on Windows64 regardless.

    I could write an application in C that ran natively on Itanium and used
    16-bit operations throughout. The choice of whether it is a true 64-bit
    applications would be subjective.
    This isn't a discussion about whether or not .NET apps can run on 64-bit
    systems natively (they can - though I have yet to test any). It is about
    whether the availability of a native int type has any benefits in such an
    environment. I suggest that it does.

    And you disagree.


  4. #214
    Joe \Nuke Me Xemu\ Foster Guest

    Re: A moderate view.

    "Phil Weber" <pweber@devx.com> wrote in message <news:3b142a5f@news.devx.com>...

    > > The only places that Int32 is not big enough...

    > Kathleen: What about values returned from GetDiskFreeSpaceEx? ;-)

    Easy: on 64-bit machines, file lengths and disk space will be returned
    as 128-bits!

    Joe Foster <mailto:jfoster@ricochet.net> "Regged" again? <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!

  5. #215

    Re: A moderate view.

    > ( | ) <- Kiss it, eh, Kunle?

    To Bill and Karl,

    I won't even insult you, you are not even grown up enough to have eraned the right to be insulted.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
HTML5 Development Center
Latest Articles
Questions? Contact us.
Web Development
Latest Tips
Open Source

   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center