Some tips for working with files :

Here are some tips for when you are working with files :

1. There is different in the way line break is stored between Windows and Unix-based [Linux,FreeBSD,etc] as a result, you must be careful when reading text files or getting input from the shell/prompt, because it might crash or worse, give incorrect information on other platforms. When the data entered has a line-break and you want to read a line, do not use scanf(“….\n“), either use filestream/cin.getline and process the line using something like sscanf(), or use multiple calls to cin (but before doing that, read tip #3 )
2. When giving the path for a file, instead of using ‘\’ , use ‘/’, so Unix-based operating systems can work with the code properly.
3. The number of accesses to the file [if it's stored on the disk] can have a critical effect on the performance of your files. Try to maintain a balance between the size of the blocks you are reading and the number of calls you are going to do in a file to get the best performance. But if the file for example has 10 integers in a single line, make sure to get the line using cin.getline (The line can be long, careful to allocate enough space for the line) and then process that string from the memory, this can bring huge speedups to your program, because the seek-time for a hard-drive is far slower than in the memory.
4. Binary formats are far faster than the text formats, when you want to keep a close eye on the data [like the early stages of the project] it is a very good idea to use Text mode, but when it is time to finalize the project and when you want to do performance improvements, add support for the binary formats [it's off-topic, but you better keep the text format capability maintained, it will be pretty useful for debugging]
5. Don’t reinvent the wheel every time you program. To store configurations and also structured text data files, it is an excellent idea to use formats like XML. From Delphi to C++ to Java, all of them have good support [using external libraries if the compiler is not shipped with XML support] for the XML and there are a good number of XML processing/editing software available too.
6. Don’t let the constantly growing files like logs become huge. Because there is a high chance that they will be heavily fragmented when stored on the hard-drive. Try splitting them up, for example if the program is constantly running, use a different log file for each day and store them appropriately [like organizing by date and using meaningful names for the log file] so consulting them would be easy.
7. Make sure to close the files after you are done with them. Also if you’re program is saving a log, make sure to flush the buffer everytime you write to the file to find out what happened before your last crash.

Well, I think that’s it for now…

iLAG

Well, guess what ? I tried to ping google and this is what I got :

Pinging google.com [72.14.207.99] with 32 bytes of data:

Reply from 72.14.207.99: bytes=32 time=2113ms TTL=242
Reply from 72.14.207.99: bytes=32 time=1867ms TTL=242
Reply from 72.14.207.99: bytes=32 time=975ms TTL=242
Reply from 72.14.207.99: bytes=32 time=1286ms TTL=242

Ping statistics for 72.14.207.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 975ms, Maximum = 2113ms, Average = 1560ms

Interested ? Here’s more info about my internets :

Tracing route to google.com [72.14.207.99]
over a maximum of 30 hops:

1     1 ms    <1 ms    <1 ms  . [192.168.2.1]
2  1618 ms  1881 ms  1863 ms  172.26.5.1
3  1648 ms  1523 ms  1863 ms  10.21.128.1
4  1506 ms  1494 ms  1729 ms  10.77.78.125
5  2064 ms  1625 ms  1793 ms  ns.kaman.azadnet.net [80.253.137.5]
6  1436 ms  1218 ms  1647 ms  int0.client.access.azadnet.net [80.253.137.14]
7  1485 ms  1359 ms  1200 ms  int0.client.access.azadnet.net [80.253.128.20]
8  1811 ms  1465 ms  1598 ms  DATA-LCT.dci.ir [80.253.145.18]
9  1930 ms  1740 ms  2074 ms  pos4-9.ar03.ldn01.pccwbtn.net [63.218.13.89]
10     *     1942 ms  1863 ms  TenGE13-3.br02.ldn01.pccwbtn.net [63.218.12.246]

11  1809 ms  2146 ms  1748 ms  195.66.224.125
12  1666 ms  2269 ms  2393 ms  209.85.252.42
13  1273 ms  1399 ms  1355 ms  64.233.175.213
14  2081 ms  1784 ms  1757 ms  72.14.233.113
15  1710 ms  1576 ms  2013 ms  66.249.94.92
16  1966 ms  2287 ms  2013 ms  72.14.236.134
17  1944 ms  1823 ms  1620 ms  google.com [72.14.207.99]

Trace complete.
Well, I don’t think you are left in any wonders for why I am having so much lag ^_^

AMD and Phenom

Well, the B3 revision that fixes the well publicized TLB erratum has finally shipped to the consumer reviewers. Techreport’s review was the first that I saw and I just saw Anand’s review. Well, to put it bluntly, in most applications the current 2.5GHz 9850 Phenom is slower than 2.4GHz while in some of the reviews it fares better. Apparently the Techreport managed to get to a stable or at least semi-stable overclock [they didn't do serious stress tests that go for hours], but the benchmarks show some hope. With some tweaking in the voltage, the Phenom hit 3.0GHz which could somehow compete with the QX6800 [2.93GHz 65nm Intel processor]. I am not going to go into a discussion about it’s overclocking power and how it stacks against Q6600 [because Q6600 can go all the way up to 3.2GHz stable at least and not many go for overclocking]. But this at least shows that Phenom can somehow compete with the Core 2 Quad is a good sign.

However, there are some problems that AMD is facing for example :

1. Intel enjoys a much higher performance in certain programs. For example, at POV Ray and Photoshop, Intel processors and specially Core 2 Duo have always been exceptionally better [sometimes 2X the performance between similar Intel and AMD offerings]. AMD should try to get the vendor of these programs to optimize the code for them. How difficult will this prove to remains to be seen, but right now, the customers that are to work seriously with these programs, will always prefer Intel processors performance-wise.
2. AMD should review some of it’s strategies for the microprocessor, or it will end up in even more problems. For example, AMD didn’t pay much attention to the fabrication technology, resulting in being more than six months behind in the 45nm node and with Intel’s current technology being superior [If we assume that they will bring out Shanghai in 08H2] and if both Intel and AMD-IBM meet the estimates, it will be behind for about 3 months for the 32nm node. AMD probably have been much better off if they hadn’t jumped on the “native quad-core” bandwagon. IMHO, they would have done much better if they had gone to optimize their 65nm K8 design in the short run [how come the maximum clock for 65nm processors is 2.8GHz while it is 3.2GHz for 90nm, this shows they could have put much more effort into the 65nm die shrink] and improve the weak parts of the architecture.

I must add that I, in no way am an Intel fanboy, I’m just trying to be fair here. The Graphics division, ATI, is back on the track nicely and with the 3870/3850 where they hit the sweet-spot for the mainstream performance/price/delivery time and availability. Also AMD seems to be on the track for releasing the 45nm Shanghai processors. Though it might face a very strong opponent which is the Nehalem [I am not sure about how accurate the slides or the ZDNet article is - though both seem to be correct - but if they are indeed correct, Shanghai will be in trouble unless it debuts with high clocks], but even if we take these predictions to be accurate, AMD’s has been performing much better lately than it was earlier [and they did admit that the native quad-core approach was wrong],  hopefully they will keep trying to eliminate the bottlenecks in the current design to recover from the current mess they are in, because it is scary to think what will happen if Intel is left without any competition…

Drumroll : There comes HavoK

HavoK is by many, considered as the best game Physics engine. Though Havok FX is probably either dead or will be neglected because of the fact that Intel has barely any solutions that can make proper use of Havok FX’s shader code [Larrabee is an array of X86 cores, so it will most likely have a different implementation to get the best performance] , but nonetheless, the news that Intel will release HavoK for non-commercial projects for free is great news for many of those free projects out there.  Though this move is most likely a marketing move for Intel to eventually drag the Open-source developers to use Larrabee or at least an Intel CPU optimized engine, it is still a very good thing for both the Open-source and freeware game developers. On the other hand, AGEIA has been bought by nVidia, that means that we will see a CUDA accelerated PhysX soon, these two events will probably leave AMD in even more trouble than it already is in unless they either find a good physics engine, or get one of the two [nVidia more likely] to support hardware acceleration through AMD GPU hardware.

OpenGL 3.0 : Hello ?

Well, as many seem to remember, at Siggraph 2007 [and at August] Khoronos announced that the specs should be finalized and they should be publicly released at September, which excited many people. After a long wait and no comments, there was a posting at OpenGL.org from Khronos, about the state of the OpenGL specs, according to them, it seems that they have been having problems with finalizing the specs and the released will be pushed back to 2008, and it seems that we have yet to run an OpenGL 3.0 program on our computers. Though a late and solid release is far better than a hasty and buggy one [as the announcement about the delay says the specification has had some improvements from the Siggraph presented version], but we wait is becoming a bit frustrating for many. Specially some that delayed some projects in hope of getting their hands on OpenGL 3.0 to prevent re-coding (*cough* *cough*).

Batman begins.

Well, everything has a start and same goes for this blog, ironically, the start of this blog is about 11 hours away from the end of the current Iranian calender year of 1386 and the start of the year 1387. Well, looking back at this year, lots of things happened but well… [This means that I am not covering them here =P]

About the title of this blog, well as many computer geeks would have guessed, this is an effect of prolonged exposure to the Pascal programming langauge, my first programming language after parting with the good ol’ Commodore 64 and it’s BASIC V2 programming langauge. Oh the good days… [Refer to the comment at the last of the latter paragraph]

Well, this weblog will cover lots subjects hopefully, ranging from Computer Graphics and Programming even to Social and Religious subjects [though politics might not get a lot of place here but well, I'm a bit too much scatter-brained to say this boldly]