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
    news:3b155f42@news.devx.com...

    > 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

    which
    > 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,

    which
    > 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

    wasn't
    > 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
    making.

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

    address
    > > 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:
    http://www.dictionary.com/cgi-bin/di...ture%20element

    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,
    > byte by byte and definetly not bit by bit. Do you know why that might be

    Kunle
    > ???


    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

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

    what
    > > sysytems they use:
    > >

    http://www.cds.caltech.edu/conferenc...ples/Cases/777
    > > .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

    talking
    > 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

    you
    > 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

    on
    > parallel computing with algorithms designed purely to find local maxima

    and
    > 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

    databases
    > > etc


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

    too..

    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

    called
    > 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.

    Kunle




  2. #212
    Kunle Odutola Guest

    Re: A moderate view.


    "Bill McCarthy" <bill_mcc@iprimus.com.au> wrote in message
    news:3b1566fd@news.devx.com...

    > > 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

    s'pose
    > 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

    Intel,
    > > AMD and others are making is just FUD?


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

    ..NET
    > 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

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

    that
    > .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,

    bounds
    > 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

    can't
    > > argue with that.

    >
    > Then why are you trying to ???


    You think I am arguing against 32-bits as the lowest common denominator?.
    No.
    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

    impacts
    > 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

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

    your
    > > application. Regardless of platform native size.


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

    for
    > 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

    guarantee
    > 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

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

    for
    > > 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

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

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

    sample
    > 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.

    Kunle



  3. #213
    Kunle Odutola Guest

    Re: A moderate view.


    "Bill McCarthy" <bill_mcc@iprimus.com.au> wrote in message
    news:3b155f87@news.devx.com...

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

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

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


    OK. I'm nuts but please comment on this:
    http://www.microsoft.com/msj/0798/hoodside.htm

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

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

    thunking
    > 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

    to
    > 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

    sideshow,
    > 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.

    Kunle



  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
    Guest

    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.

    Jens




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
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

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