Prev: multicore programming
Next: Can extra processing threads help in this case?
From: Hector Santos on 20 Mar 2010 15:15
[Starting a new topic because the thread is really deep]

Peter Olcott wrote:

> I am really only using the term OCR in a figurative sense.
> My technology is entirely different than OCR in that it is
> completely deterministic rather than stochastic. It is based
> on a deterministic finite automaton. The DFA is the
> recognizer, and comprises most of my memory requirements.
> necessarily this architecture would be memory bandwidth
> intensive. Transitioning from one DFA state to another
> mostly involves reading memory, this is inherent in the way
> that DFAs work. All of the intelligence of a DFA is encoded
> in a huge lookup table, thus looking things up in the table
> is most of what a DFA does.

I know that! But so what about the specific!?! Do you think you are
the only one that desires pure RAM optimization benefits?

You still can used MEMORY MAPPED FILES (MMF)! That is what its there
for! And you still can make it sharable with multiple requesting
threads and it works like RAM - just virtualized! But today - it is
fast before your MACHINE HARDWARE from chips, rams, cpu, hard drive,
to drivers to OS is smarter, better and faster! It is NOT like the
old days where PURE RAM was more desirable.

How many times I have to tell you this to look at MMF? Why do you
continue to ignore the technical advice given? Because its foreign to
you? Because you have not seen it such technology in action with your
own eyes, therefore its doesn't exist? Not otherwise possible?

Please peter. LISTEN! Honestly, this is getting tiresome now.

If you want, show the piece of code you have that load your font glyph
files into your GLOBAL std::vector you have.

PS: If you don't want to use MMF, then create a 4GB RAM DRIVE and
access your FILES this way!

--
HLS
From: Peter Olcott on 20 Mar 2010 15:29

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:eN7L4GGyKHA.2436(a)TK2MSFTNGP04.phx.gbl...
> [Starting a new topic because the thread is really deep]
>
> Peter Olcott wrote:
>
> > I am really only using the term OCR in a figurative
> > sense.
> > My technology is entirely different than OCR in that it
> > is
> > completely deterministic rather than stochastic. It is
> > based
> > on a deterministic finite automaton. The DFA is the
> > recognizer, and comprises most of my memory
> > requirements.
> > necessarily this architecture would be memory bandwidth
> > intensive. Transitioning from one DFA state to another
> > mostly involves reading memory, this is inherent in the
> > way
> > that DFAs work. All of the intelligence of a DFA is
> > encoded
> > in a huge lookup table, thus looking things up in the
> > table
> > is most of what a DFA does.
>
> I know that! But so what about the specific!?! Do you
> think you are the only one that desires pure RAM
> optimization benefits?
>
> You still can used MEMORY MAPPED FILES (MMF)! That is what
> its there for! And you still can make it sharable with
> multiple requesting threads and it works like RAM - just
> virtualized! But today - it is fast before your MACHINE
> HARDWARE from chips, rams, cpu, hard drive, to drivers to
> OS is smarter, better and faster! It is NOT like the old
> days where PURE RAM was more desirable.
>
> How many times I have to tell you this to look at MMF?
> Why do you continue to ignore the technical advice given?
> Because its foreign to you? Because you have not seen it
> such technology in action with your own eyes, therefore
> its doesn't exist? Not otherwise possible?
>
> Please peter. LISTEN! Honestly, this is getting tiresome
> now.
>
> If you want, show the piece of code you have that load
> your font glyph files into your GLOBAL std::vector you
> have.
>
> PS: If you don't want to use MMF, then create a 4GB RAM
> DRIVE and access your FILES this way!
>
> --
> HLS

If it aint broke don't fix it. It works perfectly now. I
can not conceive how any possible combination of disk and
RAM could ever be even the slightest trace faster than pure
RAM. In many instances it may be nearly as fast and use
limited memory much more efficiently. I don't need this I
only need it to be as fast as possible.


From: Hector Santos on 20 Mar 2010 16:01
Peter Olcott wrote:

> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
>>
>> You still can used MEMORY MAPPED FILES (MMF)! That is what
>> its there for! And you still can make it sharable with
>> multiple requesting threads and it works like RAM - just
>> virtualized! But today - it is fast before your MACHINE
>> HARDWARE from chips, rams, cpu, hard drive, to drivers to
>> OS is smarter, better and faster! It is NOT like the old
>> days where PURE RAM was more desirable.
>>
>> How many times I have to tell you this to look at MMF?
>> Why do you continue to ignore the technical advice given?
>> Because its foreign to you? Because you have not seen it
>> such technology in action with your own eyes, therefore
>> its doesn't exist? Not otherwise possible?
>


> If it aint broke don't fix it. It works perfectly now.


You in so in denial Pete :) It doesn't work perfectly, that is why
you don't have a product in the market yet.

> I can not conceive how any possible combination of disk and
> RAM could ever be even the slightest trace faster than pure
> RAM.


Well, then you are stuck.

> In many instances it may be nearly as fast and use
> limited memory much more efficiently. I don't need this I
> only need it to be as fast as possible.


You are so in denial that you don't even realize what are your design
requirements or how to address integration issues or to optimize it
for a rented machine at GoDaddy. You will never get this off the
ground. In fact, it just dawn on me, I might not even have an OCR.EXE
program at all. I think you have OTHER PEOPLE binaries and command
line OCR reading tools in a BATCH file! It was probably written for
*nix OSes and you just ported it - hence the single process ONLY
mentality. It makes perfect sense. To change it to a Multi-thread
concept is beyond your current scope of WINTEL multi-thread
programming understanding.

--
HLS
 | 
Pages: 1
Prev: multicore programming
Next: Can extra processing threads help in this case?