Re: [myhdl-list] Performance Solution #3, Getting Silicon Valley behind it, Class, LGPL, Video

[Christopher F. <chr...@gm...>]

On 4/4/2011 11:11 AM, Christopher Lozinski wrote:
> *Performance Solution #3*
>
> For my entire life people have criticized object-oriented software as
> too slow. They want to prematurely optimize all the function calls,
> rather than work at the level of optimizing the application.
>
> My standard answer is give me the fastest development environment
> possible to bring up my application. Once that is done, I can find out
> what is really slow, and what can be done about it. Then I can optimize
> that small part that is slow. In 30 years of practice I have never
> needed to actually do that!
>
> In my design, the slowest part will be my hugely complicated
> communication channels. In python, I can simplify that with a simplified
> model that anything can talk to anything. I can have two versions of the
> communication channels. One that simulates the details, and another one
> that does the exact same thing at a higher level of abstraction but runs
> much faster. In this case, I may need to do this.
>
> And since this is python, it will take me very little time to build both
> models. If I am really lucky the two models will be perfectly
> interchangeable, and provide an additional test harness, but even if
> they are not, I will be fine.

In addition to a OO it is also a scripting language.  The largest 
performance penalty is no native compilation.  This has all kinds of 
benefits but purely speaking performance it is a hindrance.

>
> *Getting Silicon Valley Behind it. *
>
> Jan made an excellent comment about the need to get Silicon Valley
> behind this. I had been expecting to have very interesting conversations
> with the hardware and tool vendors. If anybody has an insight into how
> those conversations would go, I would be very interested in hearing it.
> Here is my naive suggestion.
>
> Let us have a bunch of people behind the scenes with different
> responsibilities. Create a sense of structure. One person in charge of
> interfacing with 3rd party tools. One person in charge of class
> libraries, specifically libraries to support custom hardware features.
> For example someone mentioned that some FPGA's now have FIFO hardware
> modules. So we need FIFO software modules. Maybe another person
> responsible for open source ip cores. And maybe a third person in charge
> of conferences. And a fourth person in charge of offering a class.
> Ideally, those individuals would ideally be available by cell phone
> during the conference. That would totally destroy the one-man image. It
> is what is missing from managed by mailing list.
>
> Any volunteers?

Unfortunately I will not be available, Wednesday is a bad day for me.

>
> *Class*
>
> Which brings us to the Class.
>
> Thank you very much for the class docs Christopher Felton. Forgive me if
> I take a different path. Jan Coombs and I are putting together a simple
> blink the lights class. Anyone else who wants to work with us, we would
> be delighted to have you participate. More on this later.

No problemo

>
> *LGPL*
>
> It would be great if you could add the common sense description to the
> front of the LGPG.
>
> "Our intent is that you can you own the designs, and test harnesses, but
> changes you make to the core MyHDL world get shared. "
>
> Of course LGPL does not allow for edits. Which is a pity, because the
> license should refer to the application domain in order to be clearer.
>
> Anyhow I am pleased that this mailing list has come to life. I have had
> a great time this last week, and learned a lot.
>
> --
> Regards
> Christopher Lozinski