Tesla Personal Supercomputer by Nividia

[jprad]

Quote from byteme:

Analagous to pixel rendering for each x, y co-ordinate on the screen where the screen is 101 by 1000 pixels in dimensions i.e. perfectly suited to parallelism.

Exactly. Each pixel is independent.

Which, when it comes to programming, due to instantiation, is an entirely different concept than what a dependent variable is in math.

 

[jimbojim]

Quote from jprad:

I did, but since you insist...

main()
{
  x = 0
  y = array[100]

  for i = 0 to 100
    x = x+1
    fork_thread(i, proc_x(y, i, x))
  end

  wait_thread(100)
  print(x, y[100])
}

proc_x(array y, int i, int x)
{
  for j = 1 to 1000
    y[i] = x+2j
  next

  return
}

How is the execution time any different with your code [sic] as compared to running in a single thread?

I suspect you do not understand the fact that running programs using multiple threads does not necessarily mean running in parallel mode.

Learn the difference before you spew crap.

 

[byteme]

Quote from jimbojim:

How is the execution time any different with your code [sic] as compared to running in a single thread?

I suspect you do not understand the fact that running programs using multiple threads does not necessarily mean running in parallel mode.

Learn the difference before you spew crap.

The point is that the algorithm can be parallelized and easily too.

Your contention was that it couldn't.

Clearly, the execution of the inner loop is so trivial that it doesn't merit being parallelized but that is not the issue being debated.

Any real-world implementation would use some kind of threshold comparison to decide whether the algorithm should be executed in serial or in parallel.

 

[jprad]

Quote from jimbojim:

How is the execution time any different with your code [sic] as compared to running in a single thread?

I suspect you do not understand the fact that running programs using multiple threads does not necessarily mean running in parallel mode.

Learn the difference before you spew crap.

It certainly will run faster on an SMP machine, which was the entire point of this side conversation to begin with.

 

[John Paterson]

Geek programmers can show you how to wash your teeth while at the same time you are drinking your coffee.

Gross...

 

[chaostheory]

Quote from dcraig:

Multi threaded or not, NO current software can make use of this stuff. So don't hold your breath - it's going to be quite a while before there is much in the way of commodity software that supports it.

What's funniest is that the bottleneck in historical testing for most all these platforms is the software--not the CPU.

Most of these platforms (all the well known ones) are obviously built by GUI developers--not real time systems developers which is who should be writing historical testing systems.

There's only one system out there that has removed the software bottleneck properly.

It has some other serious limitations like zero discretionary trading support and only one broker for automated trading.

But it can process billions and billions of ticks in just several minutes on a single CPU. Plus it does mult-threading if you do an optimization on a quad core.

But the users and writer of it are getting reclusive and secretive.

 

[chaostheory]

Quote from Masterchanger:

Can you tell what the name of the software is?

I hesitate because even though it's fast, it only supports one symbol and only one broker for now. Although much of it is open source so if you can code you might be able to do some stuff yourself.

The one I mentioned is tickzoom.

Have you ever looked at TradeLink?

It seems to have improved some in speed plus it's open source, free, and supports several brokers.