Page 4 of 4 FirstFirst ... 234
Results 40 to 47 of 47

Thread: Norm Wattenberger: CVData Version 3 planning

  1. #40
    Norm Wattenberger
    Guest

    Norm Wattenberger: Re: Java (no BJ)

    But, an optimizing compiler (such as used by C++ and VB) could rewrite the code before compilation to put the IF before two FOR's making it faster yet.

  2. #41
    Norm Wattenberger
    Guest

    Norm Wattenberger: I'll take a look at that *NM*


  3. #42
    Magician
    Guest

    Magician: Re: Java (no BJ)

    > But, an optimizing compiler (such as used by
    > C++ and VB) could rewrite the code before
    > compilation to put the IF before two FOR's
    > making it faster yet.

    That's true in this case and I should have provided a better example. But that is a space-tradeoff optimization that might not always be practical, whereas just eliminating the conditional at runtime saves both space and time.

    Anyway, I was just trying to make the point (rather badly) that runtime compilation offers possibilities for performance improvements beyond what a traditional optimizing compiler can acheive.

    Just to bring this back on topic... a good optimizing compiler can give your code an "off-the-top" advantage but a runtime compiler, by looking at the "cards dealt" during the execution of your code, can potentially give it an even greater advantage.

  4. #43
    Norm Wattenberger
    Guest

    Norm Wattenberger: Re: Java (no BJ)

    > That's true in this case and I should have
    > provided a better example. But that is a
    > space-tradeoff optimization that might not
    > always be practical, whereas just
    > eliminating the conditional at runtime saves
    > both space and time.

    20 bytes no longer has a value. If we had this conversation 30 years ago it would be a different matter.

    > ....

    > Just to bring this back on topic... a good
    > optimizing compiler can give your code an
    > "off-the-top" advantage but a
    > runtime compiler, by looking at the
    > "cards dealt" during the execution
    > of your code, can potentially give it an
    > even greater advantage.

    No way. CVData sims over 2 million rounds a second. Run-time compilation would damage that significantly. OTOH, there is a superior method. Turning the simulator itself into a compiler. Compiling a program to sim a specific situation. I've done this in the past when computers were far slower.

  5. #44
    Magician
    Guest

    Magician: Re: Java (no BJ)

    > 20 bytes no longer has a value. If we had
    > this conversation 30 years ago it would be a
    > different matter.

    But if there are n conditionals inside the loop you need 2^n separate loops. Then if you have nested loops... it can get very big. The compiler also has to consider the size of the CPU's instruction cache.

    > No way. CVData sims over 2 million rounds a
    > second. Run-time compilation would damage
    > that significantly.

    ...for the first few seconds whereupon the rest of the sim would run faster.

    > OTOH, there is a
    > superior method. Turning the simulator
    > itself into a compiler. Compiling a program
    > to sim a specific situation. I've done this
    > in the past when computers were far slower.

    I think that's more or less what I'm getting at, only the VM would automate this.

    Happy to keep talking or let this drop whenever you like. I don't want to delay CVData 3! BTW, if it's not a trade secret, what language is the CV product line written in?

  6. #45
    Norm Wattenberger
    Guest

    Norm Wattenberger: Re: Java (no BJ)

    > But if there are n conditionals inside the
    > loop you need 2^n separate loops. Then if
    > you have nested loops... it can get very
    > big. The compiler also has to consider the
    > size of the CPU's instruction cache.

    Now the example becomes very contrived indeed.

    > ...for the first few seconds whereupon the
    > rest of the sim would run faster.

    No compiler is clever enough to determine from a set of variables that a loop will require enough CPU time to be worth on the spot optimization. Only a tiny number of loops require seconds of times. Those that do, do not use the time in executing conditionals. Also, you might be surprised at how little time conditionals in a loop take. The CPU itself will note that a conditional branch always fails or succeeds, keep the executed instructions in cache and execute the branch in zero time. Modern CPUs can often execute the code that comes out of an optimizing compiler faster than hand coded assembly. BTW, I once measured the time taken by VB and Java in a compaction routine. Java required three orders of magnitude more time.

    > Happy to keep talking or let this drop
    > whenever you like. I don't want to delay
    > CVData 3! BTW, if it's not a trade secret,
    > what language is the CV product line written
    > in?

    VB6. CVData/CVCX contains four simulator engines (standard, multi-tracking, parellel & CVIndex)(more are planned.) Each simulator is a separately compiled DLL compiled from a common set of code using conditional compilation. The main module communicates with the sim engines via COM object interfaces. Up to 60,000 variables are passed via object interface each sim cycle - about every half second. This sounds very inefficient, but executes remarkably quickly. The overhead is well worth the maintainability. This architecture enormously speeds implementation of new features while still executing at a few times the speed of other simulators. (Actually, 50 to 100 times the speed of BJ678.) Even executes far faster than UBE, which was developed in assembly language. CVSim was also developed in assembly.

  7. #46
    Magician
    Guest

    Magician: Re: Java (no BJ)

    I'm going to stop arguing specifics, because I'm losing. :-)

    I believe that there is alot of untapped information available at runtime that can be used to optimize code on the fly in ways that aren't possible at compile time. I believe that this will eventually allow code executing in virtual machines (Java, .NET) to operate as fast or faster than traditional, statically-compiled executables. We can come back to this in 5-10 years and see if I'm right.

    > BTW, I once measured the
    > time taken by VB and Java in a compaction
    > routine. Java required three orders of
    > magnitude more time.

    What version of Java was this? Care to run the same benchmark with the latest release?

    > VB6. CVData/CVCX contains four simulator
    > engines (standard, multi-tracking, parellel
    > & CVIndex)(more are planned.) Each
    > simulator is a separately compiled DLL
    > compiled from a common set of code using
    > conditional compilation. The main module
    > communicates with the sim engines via COM
    > object interfaces. Up to 60,000 variables
    > are passed via object interface each sim
    > cycle - about every half second. This sounds
    > very inefficient, but executes remarkably
    > quickly. The overhead is well worth the
    > maintainability. This architecture
    > enormously speeds implementation of new
    > features while still executing at a few
    > times the speed of other simulators.

    Interesting. You should put a technical description like that up on your website.

  8. #47
    Norm Wattenberger
    Guest

    Norm Wattenberger: Re: Java (no BJ)

    I'm going to stop arguing specifics, because I'm losing. :-)

    S?Okay, I make this stuff up as I go along. I?ve lectured on software architecture, performance and messaging in two dozen countries ? and never did know what I was talking about.

    I believe that there is alot of untapped information available at runtime that can be used to optimize code on the fly in ways that aren't possible at compile time. I believe that this will eventually allow code executing in virtual machines (Java, .NET) to operate as fast or faster than traditional, statically-compiled executables. We can come back to this in 5-10 years and see if I'm right.

    And yes you are right about the untapped info. But, it will likely be tapped by the CPU, not by interpreters (VM?s.) (BTW, I wrote my first VM in 1967.) Remember Moore's Law. In 5-10 years, think of the number of transistors that will sit on a chip. They can operate in parellel, and they will have to use them for something. In theory, the VM could be placed thereon. But, this is a paradigm that I can?t see in the near future due to debugging difficulties and the lines drawn between hardware and software development. Testing procedures would be nightmarish. Perhaps when they develop fast chip technology that can accept downloads. I haven?t heard anyone working on this for the next 5 years.

    BTW, CPUs capable of altering execution paths, parallel execution and pipelining are hardly new. The IBM 360/91 did all this back in 1969. Of course it was only built to avoid a suit by Control Data and no one understood how the floating point unit worked but the genius that designed it ? and he was locked up in a state hospital.

    > BTW, I once measured the
    > time taken by VB and Java in a compaction
    > routine. Java required three orders of
    > magnitude more time.

    What version of Java was this? Care to run the same benchmark with the latest release?


    Not the faintest idea. Nope. I?ve used interpretive languages on and off for 35 years and haven?t heard of any huge breakthroughs.

    > VB6. CVData/CVCX contains four simulator
    > engines (standard, multi-tracking, parellel
    > & CVIndex)(more are planned.) Each
    > simulator is a separately compiled DLL
    > compiled from a common set of code using
    > conditional compilation. The main module
    > communicates with the sim engines via COM
    > object interfaces. Up to 60,000 variables
    > are passed via object interface each sim
    > cycle - about every half second. This sounds
    > very inefficient, but executes remarkably
    > quickly. The overhead is well worth the
    > maintainability. This architecture
    > enormously speeds implementation of new
    > features while still executing at a few
    > times the speed of other simulators.

    Interesting. You should put a technical description like that up on your website.


    Well, this is how OOP should be used in my not so humble opinion. It is the only correct way to build a ?commercial? simulator. Not needed of course for a personal sim. OOP is a thick rope with a heavy anchor tied around the neck of poor young developers whose bosses demand they follow the latest techniques without any guidance on when and where. It doesn?t have to be. Well used it fulfills its promise.

    Lets go on to modern OOP languages. C++ has a few major problems, not the least of which it is based on C:

    [BEGIN OPINIONATED STATEMENTS]

      [*]Inheritance is a waste of time. There are a few places where it can be useful. They are more than overridden by the time wasted by people overusing the concept.[*]Strong variable typing. What is the point of this torture? Particularly segregation betwixt integer and floating point. Aren?t computers supposed to ease your workload ? not increase your frustration?[*]Case sensitivity. Pure insanity. Designed clearly to create frustration and bugs.[*]Lack of Globals within a logical grouping of modules. May as well say the lack of grounding in an electrical circuit.[*]Unreadability. C was designed for lazy people. I am a lazy person. But, even I understand that I will need to revisit code in the future and would like to know what I was thinking. Believe it or not, I have been a proponent of COBOL. A language that most ?computer scientists? (the word-pairing for which ?oxymoron? was coined) consider archaic.[/list]

      [END OPINIONATED STATEMENTS]

      OOP was designed for very large projects. And it works very well in that manner. It worked great for me in the macro-design of CVData & CVCX (incidentally the same program.) But, it?s silly when applied to every tiny function and sub-module.

      OK, I?ve ignored JAVA. But, what is JAVA but an interpretive subset of C++? (No, I haven?t looked at the latest version.) That is, a slow version of a language I dislike

      Incidentally, the one advantage of JAVA should be that the VM already exists on client machines. Fact is, my last company paid a rather large amount for development of a very complex JAVA project. There was still an embarrassingly long download time to get the code and data down to the client VM. I rewrote it as an ASP project (VB6 on the back-end) and the download problem was completely solved. (Contrary to the expensive advise from an Ernst & Young CS PHD that stated this couldn't be done) Thus, JAVA failed at its primary objective. (e-mail me and I?ll show you the result.)

      As I said, I make this stuff up as I go along. All real experts wake up with a tiny feeling that today they will be 'found out.' If you wake up without that feeling, you're a Proselytizer - not an expert

      Regards and thanks for a great conversation,
      norm

Page 4 of 4 FirstFirst ... 234

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

About Blackjack: The Forum

BJTF is an advantage player site based on the principles of comity. That is, civil and considerate behavior for the mutual benefit of all involved. The goal of advantage play is the legal extraction of funds from gaming establishments by gaining a mathematic advantage and developing the skills required to use that advantage. To maximize our success, it is important to understand that we are all on the same side. Personal conflicts simply get in the way of our goals.