Trading Catechism

Next I tried to compile the OpenCL kernel part of hello_world. This is what actually runs on the FPGA. Listed the boards supported, then used that as a paremeter to the compiler. Got an error. Stuck again (looks like a license issue):

Code: 
C:\Users\Administrator\Documents\Visual Studio 2015\Projects\OpenCL\Altera\exm_opencl_hello_world_x64_windows_16.0\hello_world>aoc --list-boards
Board list:
  c5soc
  c5soc_sharedonly


C:\Users\Administrator\Documents\Visual Studio 2015\Projects\OpenCL\Altera\exm_opencl_hello_world_x64_windows_16.0\hello_world>aoc device\hello_world.cl -o bin\hello_world.aocx --board c5soc


Could not acquire a valid license for the Altera SDK for OpenCL.

Code: 
Stack dump:
0.      Program arguments: C:/altera_lite/16.0/hld/windows64/bin/aocl-clang -cc1 -O3 -emit-llvm-bc -DALTERA_CL -Wuninitialized -triple fpga64 -mllvm -board -mllvm c:/altera_lite/16.0/hld/board/c5soc/c5soc/board_spec.xml -DACL_BOARD_c5soc=1 -DAOCL_BOARD_c5soc=1 c:/Users/Administrator/Documents/Visual Studio 2015/Projects/OpenCL/Altera/exm_opencl_hello_world_x64_windows_16.0/hello_world/device/hello_world.cl -o c:/Users/Administrator/Documents/Visual Studio 2015/Projects/OpenCL/Altera/exm_opencl_hello_world_x64_windows_16.0/hello_world/bin/hello_world/hello_world.pre.bc
1.      <built-in>:97:1: current parser token 'typedef'
Error: OpenCL parser FAILED.
Refer to hello_world/hello_world.log for details.


C:\Users\Administrator\Documents\Visual Studio 2015\Projects\OpenCL\Altera\exm_opencl_hello_world_x64_windows_16.0\hello_world>
 
Last edited:
nitro said:
Ultimate goal is to price 100k options on a binomial tree with 700 steps every ~second.
More...
nitro, for what do you need that?
Why don't you simply take Black-Scholes? It's gazillions times faster...
You can of course do it also using multithreading on a normal computer.
 
Last edited:
marsman said:
nitro, for what do you need that?
Why don't you simply take Black-Scholes? It's gazillions times faster...
You can of course do it also using multithreading on a normal computer.
More...
The answer as to why not use BS has been stated in the literature umpteen million times. It is pointless to repeat it here. But if you are using a model not just for simplicity but because you think it is pricing the skew and its evolution correctly, it is even more demanding.

Multi-threading when you have to price 2 years out times say an average of 100 strikes per month? Try what you are suggesting sometime on a non-trivial underlying that moves relatively fast and is not pit traded, with a model that has no closed form solution, and the option trades on six options exchanges. A standard CPU can't even handle the OPRA case.

That said, the BS model can be very useful, but it is rarely if ever used by itself in todays's trading world.
 
Last edited:
nitro said:
The answer as to why not use BS has been stated in the literature umpteen million times. It is pointless to repeat it here. But if you are using a model not just for simplicity but because you think it is pricing the skew and its evolution correctly, it is even more demanding.

Multi-threading when you have to price 2 years out times say an average of 100 strikes per month? Try what you are suggesting sometime on a non-trivial underlying that moves relatively fast and is not pit traded, with a model that has no closed form solution, and the option trades on six options exchanges. A standard CPU can't even handle the OPRA case.

That said, the BS model can be very useful, but it is rarely if ever used by itself in todays's trading world.
More...
Come on, the difference is maybe 1% to 2% or so, it's neglectible and practically IMO irrelevant for real trading... Since even the ticksize is greater than that difference...
Never mind, it's of course your project and decision.

And: creating your own prices doesn't buy you much in the real market; a better approach is to analyse the real prices to find imbalances... It's more rewarding...:D Just my opinion..
 
Last edited:
marsman said:
Come on, the difference is maybe 1% to 2% or so, it's neglectible and practically IMO irrelevant for real trading... Since even the ticksize is greater than that difference...
More...
It depends on what you are trying to do. If all you do is pick a couple of options and then put one spread on, of course it makes zero difference. It you are trying to make markets or arbitrage, it makes all the difference in the world.

Never mind, it's of course your project and decision.

And: creating your own prices doesn't buy you much in the real market; a better approach is to analyse the real prices to find imbalances... It's more rewarding...:D Just my opinion..
More...
That is absolutely incorrect. Like I said, you are thinking like a retail trader. When you have a couple of options in your portfolio, you don't have to worry about anything but putting on the position and if you did it correctly, there is very little risk - it is mostly wait and either take profits or exit position when it is clear it is a bad position. When you are making markets, how you manage the parameters to the model that in turn affect the portfolio of options you have and are likely to acquire in the future, is critical. You are no longer just deciding what the markets view is, but the relation of what the market is saying and what your position is, and the current liquidity coming in.

In arbitrage this doesn't really matter as much, but even here it can be tricky depending on what kind of arb one is doing.
 
Last edited:
Managing a portfolio of options is not unlike this, except this is easy. In the options case, there is a wind with no particular direction trying to knock the portfolio down.

 
newwurldmn said:
Nitro, have you seen Hanweck Associates: http://www.hanweckassoc.com/compute.shtml

They sell a GPU based options pricing solution.
More...
Yes I actually met with Hanwick in Chicago long ago, around 2008. My partners and I we were going to make markets at the CBOE and at the time I didn't have the experience to do this myself and couldn't come up to speed under such low lead times. Today, I don't really need a turnkey solution as I have come up to speed on most of this stuff.

Besides, I don't want GPU based solutions, I want FPGA or ASIC based solutions. There is a big difference in latency [as opposed to throughput], at least as of today.
 
Could not acquire a valid license for the Altera SDK for OpenCL.

Found out the licensing costs for OpenCL sdk. $995. Not insane, but expensive when you consider that in the CPU world compilers are free.

:mad:
:wtf:
:(
 
nitro said:
Could not acquire a valid license for the Altera SDK for OpenCL.

Found out the licensing costs for OpenCL sdk. $995. Not insane, but expensive when you consider that in the CPU world compilers are free.

:mad:
:wtf:
:(
More...

gcc/g++ supports OpenCL as well, free of any costs.
But I have no experience yet with OpenCL.
Here's a full example:
https://www.fixstars.com/en/opencl/book/OpenCLProgrammingBook/first-opencl-program/
and here's MovingAverage computation in OpenCL:
https://www.fixstars.com/en/opencl/book/OpenCLProgrammingBook/opencl-programming-practice/
 
Last edited:
You must log in or register to reply here.
Back
Top