目标是磁碟真实块数量吗?
你需要先知道档案系统是用多少容量当一个块的.
当然用常用的 4K 也是可以.但这只是常用.不是定数或是真实用量.
例如存放大型档案的系统.有用 64K 当一块的.

只有临时处理 /计算才用 excel 这种的.
office2003 用很顺手但有纪录 65xxx 笔限制,而且 2003 开 xlsx 如果超过此长度又不小心存档就'被消失'了.

Libre(open)Office 我有用过 1G 左右的档案,说不上很慢,是有变慢点.
但通常到一定体积又是网格处理的纪录我就弄去 access2003 或是 sqlite 了,速度杠杠的.

编译器中与浮点精度有关的参数,你的程式码用 gcc 编译时试着加入看看?
-mfpmath=sse
-msseregparm
-m128bit-long-double
-mlong-double-128
-mpc80
-mrecip=?
-ffloat-store
-fexcess-precision=?
-ffast-math=?
-fno-math-errno
-fsingle-precision-constant

https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/Floating-point-implementation.html#Floating-point-implementation

https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options

另外提示你,C(++)浮点计算是有明确规范舍入误差的,就像 php/js 一样.
但有很多库或是变换方法可计算指定位数舍入 /方式,或是科学库近乎无损的.
你可以找无损计算科学库.然后注意这些库的编译参数条件(就上面那些还有更多)的指定要求.

低烈度来说,Libre(open)Office 也很好用阿.
当然用一堆函数或 VBA 来操作,Libre(open)Office 开这种档案是残缺了点.

你使用的是拼音输入法还是别的?
我自己用企鹅输入法是很好用啦,但我是注音.
考虑过按照教学订制自己的 LIVE 吗?还可以放出来分享喔喔喔喔喔(翻滚

另外,做你自己,我支持你.

@aivier
我现在自己单干,也是前后分离,
然后我有需求从别人的网站或 http API 叫回别人的资料.
我这边拉回的资料都喜欢带有前端排版代码.
怎么办呢?拉回来的内容(html/xml/json/txt)写一个 JS 做遍例过滤.
总之,只留下键与值,其他的排版代码或是断行都清除.交给前端填充代码工作.
完工惹.爽.

我最怒的是有些"画出"画面后,某些区块是给后端人员做的 PM.然后前端就说那里不关我的事.
后端其实等于要阅读全部的前端代码,因为怕有 CSS 影响或是其他前端操作会异常.
但这本来就不是后端的事,
如果你不能要求 PM 后端只给键值,身为前端用 JS 过滤后端的来源变成纯键值是必要技能.

前后分离,完工.
会发生这种鸟事就是因为前端居然要求后端送出已包含排版讯息的回应.
很多次经验了,前端设计者设计主页框架后要求后端将动态或是互动的区块弄好.
所以发生这问题有一半是前端先惹的.

linux:换上 zfs/btrfs 并开启透明压缩,

mac:"HFS+"档案系统有支持透明压缩,关键字 'hfs+' 'compress'

已知可用软体
http://www.maczapp.com/morespace-folder-compression

一些文章你看看
http://arstechnica.com/apple/2009/08/mac-os-x-10-6/3/
http://arstechnica.com/civis/viewtopic.php?f=19&t=1165538

故事
http://www.zhihu.com/question/32170490

mac 硬上 zfs
https://openzfsonosx.org/wiki/Zpool

档案系统表
http://www.wikiwand.com/zh-mo/%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E7%9A%84%E5%AF%B9%E6%AF%94

还有一招,你知到档案系统中有个指令叫做软 /硬连结吗?
http://www.techbang.com/posts/12538-hard-links-soft-links-archives-does-not-fashu
hfs+有支持,用命令就可以做,
目标是相同的档案和资料夹只留一个,
其他的都是软连结做出来的.
假设 /aaa/eee 跟 /aaa/fff 档案是相同的,然后 eee 通常不会更动也不删除:
删除 fff
mklink /aaa/fff /aaa/eee
如果是资料夹
mklink -d /aaa/fff /aaa/eee
以上是 NTFS 做软连结的不标准语法,只是意思一下,mac 你要查

http://blog.udn.com/q928856957/26014600
重点看 XFS 跟 4K 优化部分.

http://saplingidea.iteye.com/blog/636770
重点看 inode size

一堆优化建议
http://xjsunjie.blog.51cto.com/999372/1390754

http://blog.csdn.net/helloanthea/article/details/50464800
优化评比

http://www.cnblogs.com/yuzhaoxin/p/4083623.html
一些参数说明

http://imysql.com/2015/07/14/xfs-vs-ext4-fileio-and-tpmc-under-pciessd.shtml
已经提示 XFS 默认的参数是哪些.可以不用人工添加

SSD 的 LINUX 说明和故障排除
https://wiki.archlinux.org/index.php/Solid_State_Drives_%28%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87%29#.E6.9C.80.E5.A4.A7.E5.8C.96.E5.88.A9.E7.94.A8SSD.E7.9A.84.E6.8A.80.E5.B7.A7

XFS 的删除效率不好的解决参数
http://blog.udn.com/q928856957/26014600

XFS 跟某资料库的优化
https://yq.aliyun.com/articles/2372
又一篇
https://www.ruilog.com/notebook/view/dbbf8a178c54.html


补充一下上面几篇有说到 ASYNC(非同步)相关参数加速读写.

ASYNC/SYNC 的模式大致分为
无日志系统例如 FAT/EXT2.写入中的档案遇到断电会不可修复.
有日志但两段式写入.遇到断电会有问题但可修复.
有日志但一次性写入.断电不需修复但是写速度想死.而且会过于多次写入影响寿命.
EXT3~4/XFS/BTRFS/ZFS 都有日志.可用参数选择一次或是两段写入.甚至还有延迟多久批次写入.

像 BTRFS 的预设延迟就是 30 秒.我调整成 1 秒.因为我没电池.
BTRFS 对于 SWAP/LOOP 档案不友善.有此需求请勿使用.

我想说的是.
任何非同步(延迟)写入的加速都是建立在欺骗自己资料已经"安全写入硬碟".
因为实际上还在记忆体或是快取层中.只要这时候断电一定出问题.
所以任何使用 ASYNC 的参数的前提.就是硬碟不会故障+有电池.不然这加速...呵呵.
任何有风险的环境都不应该使用 ASYNC 加速.

boot 分区可能直接 ext2.要用更好的就看起动器的支持.我是 ext2.
其他的我是用 BTRFS.但我会推荐 XFS.做什么都很稳.
BTRFS 有支持很多这特性但出问题后的修复很麻烦.所以不敢推荐给别人.
ZFS 也是可以用了但建立 ZFS 也是麻烦.

google "Samsung 840 EVO" 很多质疑.
TLC 颗粒呵呵.
换个至少是 MLC 的吧.

档案系统是?
档案系统也会影响.

SSD 有时候会写入出问题.如果是硬体级的故障那就神仙难救.
如果是比较小的性能突发下降.
可以靠档案系统的设计挽回.
例如 BTRFS 有对 SSD 最佳化.
或是 XFS 这种支持 Snapshot 的档案系统会更稳定.

Snapshot 不是指 VMWare 的那个.
而是档案系统本身就有 Snapshot 指令.

有 Snapshot 的档案系统通常是支持 cow 的技术.对 SSD 的寿命有帮助.
SSD 重复读写某区块会死很快.

我是叛徒...
手工写 C#/JAVA/其他小众语言...
PY/C/C++我比较少用...
PY 的版本地狱有点烦.干脆不想用.
虽然别人问我写程式入门要哪种我都说 PY.

@knightdf 头像 XD

一个提前概念.
1.大部分的程式语言本质都不是一定需要桌面才能动的.
然后为了让这些持式语言能写桌面程式.就有了 QT 这一类的"桌面应用开发工具包".
2.每个人的推荐有不同角度与考量.我推荐的是最快入门跟生产力.
做得出来能用才是重点.其他都其次.因为时间和金钱不会等你.
3.除了传统的 GUI 执行绪+背景执行绪.还有种东西叫做 Actor/akka.
很多语言都有 Actor/akka 的实现(他是一种概念).高性能.高并行.可跨机连机.
但概念比较不线性.弄懂并熟悉后.你就会把执行绪这东西丢掉.

只有 win 的需求:
VS2015 果断完整安装,支持 C#/vb.net/F#/c/c++/JS/HTML/CSS/XML/...等语言.
并可用外挂套件管理器.新增其他语言的支持
VS 开专案的时候.选桌面应用程式专案.然后选语言.C#或 VB.NET 都很好入手.我个人推荐 C#.
之后就看 C#/VB.net 的视窗程式设计的网站或书籍.
C#/VB.net 有很多很潮的语法支持.使用后会上瘾.
例如动态结构资料处理的 linq.自动并行计算的"Parallel For(each)"语法(linq 本身也有自动并行语法).
在观念不清的情况下.C#跟 VB.net 的视窗应用程式专案.有一个作弊的语法.可让背景执行绪直接操作 GUI.

win/linux/mac 桌面需求:
果断学 QT......备选 JAVA(FX/awt/swing).但个人不看好 FX.
QT 其实应该说是桌面应用工具包.所以 QT 可以搭配很多种语言.
所以你应该搜寻 QT+"某程式语言" 看看是否有支持.有就可以开始了.
某语言你就选你最熟的.
不然就 python.因为入门快.只是 py 本身是单核心的.所以大量计算的需要用多点方法解决这个问题.
py 可以搭配 C/C++...等速度较快的.也支持多核心的语言.
所以你知道某问题需要 py 大量计算,记得你还有 C/C++...等程式语言可以混搭.
不要太纠结 y 的单核心问题.搜寻 "py 多核心" 一堆快速解,最佳解.

JAVA(awt/swing/FX)是 JAVA 为了桌面平台做的东西.不难用但这 3 个东西有重复.又常混在一起用.
想厘清 awt/swing/FX.就去搜寻这三个字.会有史诗级的故事.
嫌 C#/VB.net/JAVA 慢?py 都能接受那这些都不算慢了.所以高计算还是让 C/C++来吧.
scala 是建立在 JAVA 的一种变种.核心偏向是 Actor/akka.可以 java/scala 互相引用.

3 桌面又跨手机...果断要会网页.
前端 html/css/js.后端 php/nodejs..等.后端只要能建立 http server 的语言都可以.不要限制自己的思想.
FB 有出一东西叫 React.本身是一种网页前端框架.
然后可以开发近原生的手机 APP.叫做 ReactNative.
React(Native)的速度就是 JS 的速度.应该跟 py 算同一个等级.
有人用 JS 做出高计算的框架.如果有 React(Native)的高计算需求.去 JS 社群问 JS 的高计算框架推荐.

当你身边有巨人.就不要自己拿爬梯.
除非你跟巨人不能沟通.

infobright 我不用的原因.商业版强大.免费社群版....呵呵.请详看
http://www.bitstech.net/2015/03/

忘了转码

有很完整的特性比较表
http://395469372.blog.51cto.com/1150982/1726147

infobright 介绍.我个人是没用过.我用过 TokuDB.我建议你用 TokuDB 就顺便装上 infobright 跑性能测试.
http://ju.outofmemory.cn/entry/147507

有很完整的特性比較表
http://395469372.blog.51cto.com/1150982/1726147

infobright 介紹.我個人是沒用過.我用過 TokuDB.我建議你用 TokuDB 就順便裝上 infobright 跑性能測試.
http://ju.outofmemory.cn/entry/147507

如果档案最大的是 ibdata1 档案,如下解
http://blog.fens.me/mysql-ibdata1/

如果不是.资料表快速瘦身 sql:
OPTIMIZE table xxxx

此篇说明资料库引擎有哪些可以选.还有该引擎支援的存档格式.
http://blog.jobbole.com/94385/
其中 compact 格式适合有读有写入.
ARCHIVE/Compressed 格式是高压缩格式.适合只写入一次之后只读.也就是写入后不再更动的.
Compressed 如果要更动.这格式会很很很很慢.
ARCHIVE 写入后只能读.不能改.可以整个表删除.不可单行删除.

TokuDB 是外挂引擎.需要较多的初始设定和安装.但使用上非常简单.
而且压缩率很高.读写速度都非常接近 myisam/innodb.
真心要优化.建议以上几个都弄.反正会增加你的经验.